Why We Don't Separate Design From Development

Every agency site says some version of "we bridge design and development." It's become such a standard line that it's stopped meaning anything. So it's worth being specific about what we actually mean when we say we don't separate the two.

On a typical project, a design team makes decisions in a tool like Figma, then hands a file to a development team who has to reconstruct those decisions in code. Somewhere in that reconstruction, small things get lost — an animation timing that felt right in a prototype but never gets specified precisely enough to survive the handoff, a spacing decision that made sense at one screen width but wasn't tested at the others, a hover state that existed in the designer's head but never made it into the file at all.

None of this is anyone's fault, exactly. It's just what happens when the person making a decision and the person implementing it aren't the same person, and don't share full context on why a choice was made.

We avoid it by keeping design and development inside the same small group of people, on every project. The person who decides how a section should animate on scroll is close enough to the code to know what's actually achievable at 60 frames a second on a mid-range phone — so the decision gets made correctly the first time, instead of getting simplified later when it turns out to be difficult to build.

This isn't a claim that handoffs never work. Plenty of good work gets made that way. It's just a slower, leakier process than doing both under one roof, and we've found the difference shows up specifically in the small details — the ones that are hardest to specify in a file and easiest to lose in translation.

It's also why our own site took the shape it did. The running-head navigation on our homepage wasn't designed first and then built; it was designed by figuring out what an IntersectionObserver could reliably track, then shaping the visual idea around that constraint from the start.