What changed
- User validation
- A concept survey confirmed it: users wanted light over the app's dark-only default by a clear margin (83% chose light or a mixed palette) — the insight that reshaped the whole redesign's direction
- Brand alignment
- App lagged the 2025 broadcast rebrandA shared visual language across app and broadcast
- Readiness
- Design direction finalised and validated; moving into development with working prototype code
What I took from it
Owning the design of this app end to end meant owning what sat under it. A light-mode redesign that looks premium is not a Figma decision, it depends on the colour engine and the token system that keep it consistent and correct. Designing the surface and leaving the infrastructure to chance would have produced a demo, not a product.
And the platform lesson stuck: web-first prototyping is fast, but target-platform-first is honest.
Read the full case study
The gap
Bibel TV is a broadcaster in the middle of a linear-to-streaming transformation, with apps across iOS, Android, web, and connected TV, and a broadcast archive going back generations. The app did not show it. The patterns were dated, it had not followed the 2025 broadcast rebrand, content was hard to discover, and nothing in it was built for retention.
The redesign had to close that gap: turn German-market knowledge, cultural fit, and the archive into something a user could feel in the first thirty seconds, instead of an app that looked older than the brand actually was.
The light-mode bet
The redesign gave the app a new visual language, aligned with the 2025 broadcast rebrand: lighter, warmer, and properly premium. Streaming-native patterns for discovery, search, and watch-next. Three core areas, the Mediathek, Bible reading, and reading plans.
The real bet was light mode as the primary direction, against the streaming-industry default of dark. That default exists for a considered reason: a dark frame recedes into the background — the same principle a theater uses when it dims the room — so artwork and video carry the screen instead of competing with the chrome around them. Our research said something different was true here — users associate Bibel TV with hope, and expected that to show up in the interface itself, not only in the content. That is a real, specific research insight, and it argued directly against an industry convention that is not arbitrary, so it had to be taken seriously rather than simply preferred.
Taking it seriously created the actual design problem: the new branding runs on image-based, dynamically extracted colour themes, built the way the rest of the industry builds them — for dark backgrounds first. Making that same system hold a premium, on-brand feel in light mode was genuinely unsolved going in. It could not stay a surface decision; it needed real colour and contrast work underneath, and a design system that could keep four platforms in step. Those became their own projects (see the related case studies): the colour engine, tuned for light mode first — the reverse of the usual order — and a token system delivered as an API, which is also a step toward Bibel TV's own stated direction of server-driven UI and less dependency on the agency that builds the app. Prototyping the redesign directly in code, rather than static specs, is what let all three move in parallel instead of waiting on each other.
Research, and a lesson about platforms
The work ran about nine months in three phases: competitive analysis against the global streaming apps, prototyping, then validation with staff and with users.
One lesson is worth keeping. I built the first prototype for web because web is fast, then rebuilt it on Android, because Android is the largest part of our userbase. A stakeholder had raised a specific worry on the way in: old Android screens in our userbase render gradients badly. Testing it showed the worry was real and the diagnosis was not. The banding tracks old displays, not Android. So the fix generalised past the original concern, and we now build multi-step gradients even for monochrome ones, which is what actually addresses banding. Prototype where your users are, and be willing to find that the thing everyone named was not the variable.
Curious how "old Android phones render gradients badly" turned out to be about the displays and not the platform, and how that fix ended up running in every gradient the app ships now, even the plain-looking ones? Get in touch.