Principles for building a design engineering practice

I’m building out the design engineering practice at DuckDuckGo. It’s a small team right now, and we’re hiring our second person to help shape the practice and lead it with me.

It’s early, but that’s part of why I wanted to write these down now. The decisions we make as a small team will become the habits other people join, and I’d like us to be deliberate about which ones we keep.

I wanted to put down how we’ll approach some of the problems we’re trying to solve: handovers between design and engineering, a lack of shared knowledge across that boundary, AI-generated solutions that aren’t properly understood, and speed winning out over craft too often.

This is where I’ve landed.

Understand before we make

We start by understanding the problem, what we want to change and the constraints around it. That gives us something to judge a proposed solution against.

• Question assumptions and validate direction early.
• Understand the code and product context before changing them.
• Use AI to accelerate exploration and execution, never to replace judgement.
• If we cannot explain how something works and why it is right, we do not own it yet.

Stay with the experience

We share responsibility from problem framing through production and iteration.

• Work across product, design, and engineering boundaries.
• Prototype in the medium that answers the question best.
• Treat code, interaction, content, documentation, and support as parts of one experience.
• Stay involved until the shipped result meets its intent.

Make trust effortless

Privacy, clarity, accessibility, and reliability belong in the experience from the beginning.

• Hide unnecessary complexity from people, not important consequences.
• Make safe choices understandable and easy.
• Design for different abilities, skill levels, devices, and circumstances.
• Never trade user trust for engagement or short-term convenience.

Move fast by making less, better

When time is constrained, reduce scope before reducing quality.

• Ship the smallest complete and coherent experience.
• Separate what must be excellent now from what can genuinely wait.
• Prefer focused progress over a larger collection of unfinished ideas.
• Treat the quality floor as fixed; negotiate scope above it.

Finish the work

Once the main flow works, there are still the other states and circumstances to work through.

• Care about every state, edge case, word, transition, and response time.
• Treat accessibility, performance, and polish as product quality, not optional refinement.
• Make time for the final pass when planning the work.
• Push back when competing priorities would leave the experience visibly unfinished.

Make quality repeatable

We need ways to carry the care from one piece of work into the next, and make it easier for other people to do the same.

• Turn repeated decisions into shared components, defaults, tools, and checks.
• Build design fluency in engineers and code fluency in designers.
• Share work early and explain the reasoning, not just the result.
• Leave the team better equipped to produce excellent work without us.

These are deliberately practical. I want us to use them when planning projects, reviewing work, hiring people and deciding what to cut when priorities compete.

The principle I expect us to test most often is moving fast by making less, better. We need to move quickly to compete with companies that have far more people and resources. But if every deadline lowers the quality bar, we’ll never build the practice or product we want.

We’ll find out which parts need adjusting as the team grows. For now, this gives us something to refer to when we’re deciding how to approach the work, and something to hold each other to.