How designers work with developers

The core misunderstanding

Designers think in pictures, developers in states and data. A mockup shows one moment; the program has to work in all of them.

Hence the classic conflict: the designer delivers a handsome screen, the developer asks "what if the name is long, what if there are no items, what if the image fails to load" — and it turns out nobody thought about it.

A good designer answers those questions before they're asked.

What to hand over with a mockup

States. Not one screen but five:

• the normal one;
• loading;
• empty, when there's no data;
• error;
• extremes: very long text, many items, a missing image.

Those states consume most of the development time, and they're exactly what designers most often don't draw.

Behaviour. What happens on tap, where it leads, what changes. Arrows on a diagram or a short description.

Adaptation rules. How it looks on a phone. Not "scale it down" — on a narrow screen the layout usually changes fundamentally.

A system, not a set of screens. One button with its states described, rather than twenty buttons differing slightly. The developer builds from components, and if the components don't match they'll ask about every difference.

What to avoid

Magic spacing. 13, 17, 22 pixels signals that things were nudged by eye. Use a scale: 4, 8, 12, 16.

Twenty shades of grey. Assemble a palette and stick to it.

Fonts that don't exist. Check availability and what it costs in load time.

Effects that are expensive to build. Complex animation or an unusual layout can cost a day. Ask in advance whether it's worth it.

Negotiating

When a developer says "that can't be done", it's rarely stubbornness. Usually behind it: it's slow, it breaks on phones, it's inaccessible from a keyboard, it requires reshaping the data.

A productive conversation runs: find out the constraint, state what matters to you, find an option. "What matters to me is that the primary action stands out. If that's hard to build, let's distinguish it by colour rather than size."

Unproductive: "the mockup says so, build it."

What to understand about implementation

Not how to program, but the orders of magnitude:

• Changing a margin takes minutes. Changing a screen's structure takes days. So small corrections are easy, while a layout rework must be discussed in advance.
• Data may be absent. Anything coming from a server sometimes doesn't.
• Text changes. Especially in translation: what fitted stops fitting.

What improves the work most

The designer being present in discussions rather than handing mockups over a wall. Fifteen minutes at the start saves three rounds of revisions.

And working on a project together from the beginning. A designer who has been in a team and watched their decisions get built grows faster — they stop drawing the impossible and start proposing what delivers a result in reasonable time.