Blog

Design that survives the build

Most design dies in the handoff. Ours does not, because there is no handoff — the engineers sit in the same studio.

A thick optical glass slab on white paper, teal channels resolving into one plane. No people.

Most product design does not fail in the file. It fails after export. A design agency closes the deck. An engineering shop opens it. Spacing drifts. Empty states vanish. Edge cases get invented at a keyboard. That gap is the handoff, and it is where most design dies.

Design that survives the build is work that still looks and behaves as intended once it is live. Fluids Design is the design practice of Fluids Digital. The people who build the product sit with the people who drew it. There is no package thrown over a wall.

You can still take the files elsewhere. They are specced for that. The point is not to trap you. The point is that the design was made to be built.

Why does most design die in the handoff?

The handoff is a translation problem. Designers decide spacing, states, and motion in a file. Engineers decide what ships, under a deadline, in a codebase they did not choose. When those two groups do not share a room, the file becomes a suggestion. Production then fills the gaps with whatever is fastest.

A finished file is not a finished product. It is a set of decisions. If those decisions are not written so an engineer can follow them, they get remade. Remade decisions are rarely the original ones.

What usually gets lost

  • Empty, loading, and error states
  • Spacing and type on a real grid
  • Motion that was designed as behaviour
  • The reason a component looks the way it does
  • Bilingual and RTL behaviour, if the product needs it

What does design that survives the build actually include?

It includes every screen, every state, and the rules an engineer would otherwise invent. Tokens for colour, type, and space. Named components. Empty, loading, error, and edge cases. Real copy, not placeholder text. Motion described as behaviour, not as a mood. A file that answers questions before they are asked.

If a designer has to sit on a call to explain the file, the file is unfinished. The conversation should confirm, not decode.

We also ship a system, not a pile of frames. Tokens and components are not an extra. They are how the next screen stays consistent when we are not in the room. That is what a design system is for: a shared language, not a sticker sheet.

Do we have to use your engineers?

No. Fluids Design will build with you, or you can take the files to another team. The files are specced so a competent engineer does not have to guess. Same tokens, same states, same assets. The studio is one building. The contract is not a lock.

If you stay, the person who drew the empty state can walk to the person implementing it. If you leave, you should still receive something an outside team can build from. A spec that only works when we are in the room is not a spec.

How does a project run when design and engineering share a studio?

It runs as four named steps: Frame, Explore, Design, and Ship. Scope and success are locked first. Then two or three real directions, not mood boards. Then every screen and state, reviewed as it is made. Then the work goes to engineering in the same studio — or out as a spec, if that is your call.

You see work every week. The four steps are written out in how a design project runs. That is a description of how we run, not a promise that every product is four weeks.

What should a design lead put in a spec if the builders are not in the room?

Put decisions, not decoration. Name the tokens. Show each component in its real states. Write the empty and error copy. Mark spacing on a grid the engineers already use. Describe motion as duration, easing, and trigger — or omit it. A screenshot is not a spec.

  • Tokens named for code, not for a slide
  • Components with the states production will hit
  • Flows that include failure, not only the happy path
  • Assets at the sizes the build will request
  • A written line on what may change without a designer

When is a separate design agency the wrong choice?

When the product has to ship, not just get approved. A separate design agency is fine for a brand exploration or a pitch. It is the wrong structure for a live app, a dashboard, or a marketing site that has to rank and convert. Those products need design that can survive contact with engineering.

On this site, the proof is the pages themselves. Sites we designed are shown as they shipped. If you want to talk about a product, book a call.

Book a call