Product & Design
Why design and development don't run one after the other here
Finished design first, then the build – it sounds tidy, but it only pushes the expensive questions further down the line. Here's what we do instead, and what it costs.
The classic model is a handover: design draws it, development builds it. On paper, a clean division of labour. In practice, the bill arrives later – with the detail that took two minutes to design and two days to build. Or with the state nobody drew because it never appears in the design: the empty list, the loading state, the expired session.
What a finished design doesn't answer
A static screen shows a single moment: just the right amount of data, just the right text lengths, everything working. The real work lies in all the other moments.
- What's on screen before the data has loaded – and if none arrives?
- What does the heading look like when the real product name is twice as long as the placeholder text?
- What happens after the click if the server takes three seconds?
- And what does the animation that makes the design look so good actually cost?
These questions don't come up in the design review. They come up during the build – after sign-off, when changes are most expensive.
How we work instead
We design roughly and build early. In design, we settle structure, hierarchy and flow; everything else we decide in the real frontend with real data. Two things make this possible:
Design tokens instead of pixel-matching. Colours, type scales and spacing are defined once and are identical in design and code. There's no "that's 4px too much" round, because nobody picks arbitrary values – it's also how our own website is built.
The design moves into the browser early. Instead of polishing a screen in the design tool, we turn it into something usable within a few days. From then on, everyone clicks through the same thing rather than discussing a picture.
What it costs
To be honest: there's no single meeting where "the design is done" and gets signed off. Decisions are made later and spread out more, and you have to live with a version looking a bit rough for a week. If you need a pixel-level sign-off record, the classic model will serve you better.
In return, there are no surprises during the build – and you get an interface that works in the unglamorous states too, not just in the screenshot.
trefox Redaktion
Team trefox
Articles from the trefox team – experience gathered across many projects in custom software development, product design and working with our clients.
