Designing and Building the Same Feature

From 2013 to 2015 I was an Interaction Designer/Developer at Pandora. From 2016 to now I've been a Design Engineer at eBay. Different companies, different titles, the same basic idea: the person who decides how something should feel is also the person who writes the code that makes it feel that way.

People sometimes treat that as a compromise. A designer who codes a bit, or a developer with taste. I don't think it's either. It's a role with its own value, and it's worth explaining what that value is.

Where things get lost#

In a typical product team, an interaction goes through a chain:

1. A designer imagines it.
2. They describe it in mockups, specs and maybe a prototype.
3. An engineer reads that description and builds their understanding of it.
4. The thing that ships is the engineer's understanding, not the designer's idea.

Every step is a translation, and translations lose detail. The most fragile details are the ones that are hardest to describe in a static mockup:

• Timing. How long a transition takes, and how it eases in and out.
• State. What happens while something is loading, when it fails, when it's empty, when there's too much of it.
• Feel. How a control responds to a fast tap versus a slow drag.
• Edge cases. The long name, the missing image, the slow connection.

Those details are exactly what makes an interface feel good or feel off. And they're the ones most likely to be lost between design and code.

What changes when one person does both#

When the same person carries an idea from sketch to code, a few things happen.

The translation step disappears. There's no spec to misread, because the person writing the code had the idea. The details that would have been lost are just there, because nobody had to describe them.

Design decisions get made with real constraints. You know what the platform can do, what's expensive and what's easy. You stop designing things that will be cut in implementation, and you start noticing things that are cheap to build and delightful to use.

You can design in the medium. A lot of interaction design is easier to judge in a running build than in a mockup. Timing especially. You can try three versions of a transition in the time it takes to describe one.

Iteration gets tight. Change, reload, look, change again. The loop between "that doesn't feel right" and "now it does" is minutes, not a ticket and a sprint.

Listening is a good place to learn this#

Music is a demanding place to design interactions. People use it while doing other things: walking, driving, working, cooking. The interface has to be glanceable and forgiving. A control that's a little too small or a little too slow gets noticed.

It's also emotional. The way a station starts, the way a song changes, the way you react to something you love or don't. Those moments are mostly made of timing and feedback, which is exactly the part that gets lost in handoff.

Music makes the lesson hard to miss: the feel of an interaction is a first-class part of the work, not polish to add later.

Prototyping with the C-suite#

Context. Between 2015 and 2016, commerce moved into social feeds and onto phones. Facebook tested shop sections with buy buttons on Pages and Local Market, a buy-and-sell space built on Groups, and in April 2016 opened Messenger to bots. eBay retired its standalone Fashion app and rebuilt browsing around structured data, guiding shoppers who don't start from a keyword.

The problem. Finding fashion inside a social feed was hard. Shopping lived in separate apps and separate searches, away from where people spent their time.

What I built. A marketplace app for Facebook that brought eBay's fashion inventory into search, making it easier for people to find what they wanted, ahead of Facebook Marketplace. I built it while leading rapid prototyping in partnership with eBay's C-suite, as React Native emerged. It was not publicly launched.

Design system. In parallel, I helped develop the design system eBay still builds on.

Where the industry went.

• Oct 2016. Facebook launches Marketplace. eBay debuts ShopBot on Messenger.
• Mar 2017. Facebook introduces Collection, a mobile ad format that opens into a catalog of up to 50 products.
• Aug 2017. Facebook tests eBay Daily Deals inside Marketplace.
• Oct 2017. eBay launches Image Search and Find It On eBay, visual search that starts from a photo or an image shared from a platform like Facebook, following Pinterest's visual search in 2015.

Making design survive at scale#

At a large company, the problem shifts. It's no longer one person carrying one feature. It's many teams building many surfaces, and the challenge is keeping the design intact across all of them.

That's where a design engineer is most useful. The job isn't just building screens. It's building the shared pieces that let other people get the design right without thinking about it:

• Components that encode the design. If the spacing, states and behaviour are built into the component, every team that uses it gets them for free.
• Clear APIs for those components. Easy to use correctly, hard to use wrong.
• Documentation with live examples. Showing a component in every state is worth more than a page of rules.
• A voice in both rooms. Being able to explain to designers why something is hard to build, and to engineers why a detail matters.

A design system is really this idea at scale. It's the design engineer's knowledge, written down as code, so it doesn't depend on one person being in every review.

How to tell the role is working#

It's fair to ask how you'd know any of this is paying off. A few signals are worth watching:

• Fewer "that's not what I meant" moments in design review, because the build matches the idea the first time.
• Fewer design bugs filed after launch, the small visual and interaction issues that pile up when details get lost.
• Faster reuse. When teams reach for shared components instead of building their own, the system is doing its job.
• Consistency nobody had to police. Screens built by different teams feel like the same product without a reviewer catching every difference.

None of these is a perfect metric. Together, they tell you whether design is surviving the trip into code.

The trade-offs#

It isn't all upside. Being both has real costs:

• Depth. It's hard to be as deep as a full-time specialist on either side. There will always be designers who are better at visual craft and engineers who are better at systems.
• Context switching. Moving between thinking about feel and thinking about data flow is tiring.
• Being misread. Some teams don't know where to put the role. It can end up as "the person who does the CSS".

The way through is to be clear about where the value is. It isn't in being a decent designer and a decent engineer. It's in the space between them, where ideas get lost, and being the person who makes sure they don't.

Advice for people in the middle#

If you're somewhere between design and engineering and wondering whether to pick a side, here's what I'd say:

• Don't apologise for the hybrid. It's a real role. Describe it by the problems it solves.
• Get properly good at the front end. Accessibility, performance, animation and state. That's where design lives in code.
• Learn to prototype fast. The ability to make an idea real in an afternoon is the most persuasive tool you have.
• Build things other people use. Components and systems multiply your impact far more than individual screens.
• Stay close to users. The point of all of it is how the product feels to the person using it.

The takeaway#

When one person designs and builds the same feature, the details that usually get lost in handoff survive: timing, state, feel and edge cases. At a small scale, that means better features. At a large scale, it means components and systems that carry the design for everyone. The role sits between two disciplines, and that's exactly where it's useful.