Leading a UX and frontend team across many parallel projects

“That’s how it was in the design”

On the surface, the sentence sounds perfectly reasonable. The design showed one thing, the build did that thing, so where is the problem? The problem is what the sentence quietly assumes: that a design is a complete specification, signed and sealed, and that everything it didn’t mention is somebody else’s concern.

No design covers everything. Empty states, long names, slow connections, missing data, a second language, a role nobody thought of. A design is a statement of intent, and intent needs interpreting. When that interpretation is replaced by a literal copy, the gaps don’t disappear. They simply reach the user unexamined.

Why I don’t like that stance

I see it, above all, as a question of maturity rather than skill. A mature developer reads a design the way a good editor reads a manuscript: carefully, and with questions. If something looks odd, contradicts an earlier screen or ignores a case the data obviously allows, they pick up the phone. The sentence “that’s how it was in the design” is what remains when that conversation never happened.

It also splits responsibility in a way the product cannot afford. The user doesn’t care whose layer the mistake came from. They only see that it is there.

Why design ends up holding the blame

There is an uncomfortable side to this that rarely gets said aloud. Designers are very often asked to deliver before they have what they need. The requirements arrive late, the documentation arrives later, and the deadline doesn’t move. So they work from instinct and memory, filling the gaps as sensibly as they can in order to make the date.

When a mistake later surfaces, the trail leads back to the design, because the design is the most visible artefact. What the trail rarely shows is the missing input that forced a guess in the first place. Designers learn to carry that weight quietly, and over time it wears them down.

The organisation’s share

Much of this isn’t personal at all. It is organisational. Projects are pushed through quickly because they need to be delivered and invoiced, and that pressure is itself a consequence of the environment and the uncertainty in which so many of us live and work. When cash flow depends on speed, the first thing to go is the time set aside for understanding, and the conversations between disciplines are usually the first casualty.

No individual can fully fix that. But a team lead can name it, and can protect at least a little of that time, because the cost of skipping it always comes back later, and with interest.

Education on both sides

Part of the answer is education, and it runs in both directions. Developers need enough design literacy to recognise when something deserves a question, and the confidence to ask it rather than build blindly. A five-minute call with the designer almost always costs less than a day of rework. The same holds for backend developers, whose data structures shape what an interface can honestly promise, and who are often the first to see that a screen has been designed around data that doesn’t exist.

Designers, in turn, need to document the states and the reasoning, not only the happy path, to explain why a decision was made, and to be reachable once the build begins. A design handed over and then defended from a distance invites exactly the literal reading it later complains about.

Across many parallel projects

All of this becomes harder when one team works on many projects at once. There are fewer conversations, more assumptions and less memory of why anything was decided. People move between contexts several times a day, and the space for a quick, informal question shrinks with every switch.

What helps, in my experience, is fairly modest. Designers stay reachable during the build, not only before it. Every handover carries a short note on intent and on the cases the design doesn’t cover. Early builds are reviewed together while changes are still cheap. And a shared component library gives both sides the same vocabulary, so that a question can be asked in a sentence rather than a meeting.

None of it is about deciding who was right. It is about making sure that next time, the question gets asked before the sentence gets said.