What changed
- How a design change gets judged
- A spec and a redline, judged by reading themRunning code on real data, judged in the same session
- What engineering received
- Figma specs and redlines to interpretWorking prototype code, reused directly in the build
- Platform decisions
- Web-first assumptions were corrected on the Android prototype, before production work started
A web-first assumption got caught and corrected on the Android prototype before a line of production code was written. The cultural change was harder than the technical one: it took trust for an outside agency, with no reporting line into Bibel TV, to treat prototype code as a real design artifact rather than a suggestion to reinterpret. Once the first prototype became production code, that trust came on its own.
What I took from it
Working code is the clearest design spec because it removes ambiguity. When engineering reviews a running prototype, they see exactly what works and exactly what does not. This way of working asks for a design leader who is comfortable in code, not writing production systems, but building prototypes that carry intent. It is worth the stretch. When the prototype is working code, the design-to-ship gap mostly disappears.
Read the full case study
The handoff problem
The standard process runs in sequence. A designer works in Figma, writes specs, redlines measurements and states. Engineering builds from the document. Design reviews the build, finds the gaps, and the two sides go back and forth for weeks. Every handoff in that chain loses information. A spec can say a card should feel premium; it cannot say what that means in padding, contrast, and motion. And the code engineering writes from a spec has no connection to the thinking that produced the design.
What I do instead
At Bibel TV I design the concept in Figma, layout, flow, hierarchy, and then prototype it in real code, using AI-assisted coding tools to move quickly. The prototype runs on the actual Bibel TV APIs, with real videos and real metadata. Engineering does not receive a spec. They receive a working prototype, and they build on its component structures, API calls, and navigation patterns. They refine; they do not re-implement. That engineering team sits at an external agency, not down the hall, so the prototype has to carry the decision across a company boundary rather than just across a desk. When a technical constraint shows up, I change the prototype in code, in the same medium as the product. There is no handoff step to lose anything in.
How it works in practice
Concept in Figma
I still start in Figma for layout, flow, and visual hierarchy. That defines the intent, the what.
Prototype in real code
I build the prototype in code with AI-assisted tools, against the real Bibel TV APIs. Design decisions get made in the working medium: layouts, interactions, edge cases.
Real data, not placeholders
The prototype runs on actual content: real videos, real metadata. That surfaces problems placeholder data never shows.
Engineering builds on it
Engineering reviews the prototype code and reuses its structure directly. Refinement, not re-implementation.
A real example: the gradient worry that turned out not to be about Android
I built the web prototype first, with gradients that looked good in the browser. Then I rebuilt it on Android, because Android is the largest part of our userbase, and because a stakeholder had named a specific risk: old Android screens in that userbase render gradients badly, with visible banding.
The old way: file a ticket, explain the concern to engineering, wait for an assessment, maybe redesign. Instead I iterated on the Android prototype in code and tested alternatives against real rendering. The banding was real. Android was not the reason for it. It tracks old displays, and the same displays band on any platform.
That changed the fix. Instead of an Android workaround, we build multi-step gradients, including for monochrome ones, where nobody had asked for it, because that is what addresses banding on an old display. Engineering got a working reference and a correct diagnosis, not a problem report.
Curious how a working prototype becomes an outside agency's own reference code instead of a spec they have to reinterpret, or how a gradient bug that looked like an Android problem turned out to be about old screens instead? Get in touch.