End to end, enablement, and polish

When I think about the work I ship as a Design Engineer, it tends to fall into three kinds of project: end to end, enablement, and polish.

That’s also how I’d explain the work to someone who wants to become one. The things we share online can give a fairly narrow impression of the role, because a beautifully finished interaction is much easier to show than the work that helped a whole design team build better things.

End to end

This is the part of the role I think makes Design Engineering distinct. We have the skillset to take a project through its entire lifecycle, from understanding the problem and deciding what to make to designing, building, shipping, and improving it.

Being able to carry the design into production means we can keep adjusting it as we learn. Something might be awkward to build, or work perfectly well in code and still feel wrong to use. We can look at the design and the implementation together to work out what to do next.

Sometimes we’ll need support from research, backend engineering, data science, or another specialist. Sometimes the scope is small enough, or our experience broad enough, that we can ship the whole thing ourselves. Knowing which situation we’re in is part of doing the job well.

For someone aspiring to the role, a small, complete project is a useful way to practise this. Choose a problem you understand and take it far enough that somebody can use the result. You’ll have to make decisions that a prototype can leave open, then live with what you shipped long enough to learn from it.

Enablement

Some of the most useful things we can build are for the people we work with. Internal tools, skills, and processes can help the wider design team, or the whole company, do work they previously found difficult or couldn’t do at all.

That might be a tool that removes a repetitive part of a designer’s day, a starting point that helps them prototype with real components, or a shared way to review an implementation. It can also mean teaching a skill and giving people enough support to use it in their own work.

Because we understand both design and engineering, we’re well placed to notice where people are getting stuck between them. We can make the tool and think through the experience of using it, including what someone needs to learn and what should simply work for them.

I want to see whether people can actually use what we’ve made without needing us beside them. That means they need to be able to find it, understand it and get enough experience with it to trust it in their own work.

This work can be harder to show in a portfolio because the interesting outcome happens in somebody else’s work. Explain what was difficult before, what you made possible, and how people used it. That’s a much better account of the contribution than a screenshot of the tool on its own.

If you’re looking for somewhere to start, pay attention to the thing your team repeatedly asks for help with. There may be a small tool or a teachable process that lets them handle it themselves next time.

Polish

Then there’s the final 10%: the details that get forgotten, squeezed out of the plan, or cut when a deadline gets close.

It might be a transition that loses the person’s place, a layout that falls apart with real content, or a control that feels awkward every time you use it. Design Engineers can investigate why those things happen and make the changes needed to finish the experience properly.

This work is critical because small problems repeated throughout a product can make the whole thing feel difficult or unreliable, even when each feature technically works. Caring enough to find and fix them is a substantial part of the job.

Calling it the final 10% doesn’t mean it should only be considered at the end. We should plan time for it and work on it as the product takes shape. The phrase describes the care that so often gets left out, rather than a tidy estimate of how much effort it takes.

Polish is also the easiest part of Design Engineering to share online. A before-and-after clip makes the improvement visible immediately, but its visibility can leave people with the impression that finishing other people’s projects is all we’re able to do.

That has consequences for the work we’re offered. If a team only thinks to involve a Design Engineer just before release, we’ve already missed the chance to help shape the project or build something that would make the whole team more effective.

In practice these overlap quite a lot. I might own a feature, build something that helps the team maintain it, and spend time refining how it feels. The three kinds of work are useful for explaining the role and deciding where to spend time; I don’t need every task to fit neatly into one of them.

If you’re working towards a Design Engineering role, give yourself opportunities to do all three. When you show the work, explain the projects you owned and the people you helped as carefully as you present the polished interactions. That’s the experience I’d want a hiring team to understand.