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.

That might sound early for a set of principles, but I think it’s exactly the right time. The decisions we make now will become the habits, expectations and quality bar for everyone who joins later.

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 with the actual problem, desired outcome, and real constraints, not a preferred solution.

• 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.

Own the experience, not the handoff

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

A working happy path is not the finish line.

• 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

Craft should compound instead of depending on heroics.

• 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.

The principles will evolve as the team grows. For now, they describe how I want us to approach the work and the standard I want us to hold each other to.