Most of what I care about in an interface is exactly what tends to go missing between the design and the code.
I've worked as a design engineer at places like Inbound and Emergente Labs, where I designed things and then built them myself. People usually assume the benefit is speed. It does help with speed, but what I noticed most was how much stopped disappearing.
Where it goes
Nobody is doing anything wrong in a normal handoff. Everyone's competent and everyone cares. The details get lost a little at each step anyway, simply because each step only carries part of the picture.
- The idea how it should feel
- The mockup one state, perfect content
- The ticket what to build
- The code what actually ships
- Why it's this size
- Hover
- Loading
- Empty
- Failure
- Timing
- The awkward case
An engineer who wasn't in the room sees a 13px gap and can't tell whether it's intentional or a slip. So they round it. Quite reasonably! And when they reach a state the file doesn't cover, they invent one, because the deadline is today and the designer is in a meeting.
The loop
When the same person holds both ends, the shape changes from a line to a loop.
- Design it
- Build it
- Notice it's awkward
- Fix it in the system
That third step is the one I'd pay for. Some things are only obvious once they're running: the animation is too slow, the hover state jitters because the font weight changes, or the layout breaks at a width nobody drew.
If I'm the one who notices, I fix the design, and if the fix is general I fix it in the system. It doesn't get patched in one file and forgotten. At Inbound, this is why hover and loading states actually got built. Nobody had to remember to ask, because I'd already been annoyed by their absence.
Same system, opposite jobs
It also lets you hold two very different things together. At Inbound I worked on both the dashboard and the marketing pages, and those pull in opposite directions.
Working on both, with one shared system underneath, kept the product feeling like one thing. I doubt I'd have seen where the shared layer should stop if I'd only worked on one side.
What it costs
I don't think this is free, and I don't fully trust anyone who says it is.
You lose the second pair of eyes. A designer who isn't also the builder will push back on things I've talked myself into because they were easy to build. When I hold both ends, a shortcut can feel like a design decision. I have to watch myself for that.
You stop being able to go deep in everything. A dedicated designer has spent more hours on type than I have, and a dedicated engineer knows more about the data layer. Range has a price.
It doesn't scale past a point. One person can't hold a whole big product. The realistic version on a large team is a few people like this working on the parts where feel matters most.
You can do this without changing your job
You don't need a new title to close some of this gap.
- If you're a designer, open the real thing in a browser before calling it done. Resize it, and use the keyboard.
- If you're an engineer, ask what a detail is for before you round it.
- Either way, list the states before starting. The empty and failed ones are the ones that get invented at the last minute.
- Sit together for the last 10%. That's where most of the feel is.
Handoffs aren't really the enemy. The problem is treating one as the moment your part ended.