Product design

Introduction#

Good design ensures that a product does what users need, in a form they can understand and use. How the product looks matters, but if it doesn’t meet a real need then it is a failure, however good it looks.

Where design works well:

The Product Manager, a designer, and the Tech Lead shape solutions together, to ensure the solution is valuable, usable, feasible, and viable. This is the solution to the common anti-pattern where fixed “requirements” are passed verbatim from the customer to the Product Manager, on to the designer to beautify, and finally to the team to build as specified.
The conceptual model is agreed before screens are designed, because it is the most expensive part to change.
Design runs alongside delivery, only a little ahead of it, so decisions are made when the richest information is available, rather than in a separate up-front phase.
Design is grounded in regular contact with real users, so decisions are based on evidence rather than opinion.

This page explains why each of these matters, what Tech Leads and engineers contribute, and how wireframes, design systems, and iterative design keep work flowing.

This reflects a consensus among product development practitioners.

Marty Cagan, in Inspired and Empowered, argues that teams should be given problems to solve rather than features to build, with the Product Manager, designer, and Tech Lead working out solutions together. Teresa Torres, in Continuous Discovery Habits, describes how that trio stays in weekly contact with customers. Jeff Gothelf and Josh Seiden, in Lean UX, show how design fits into agile delivery through shared understanding rather than detailed hand-offs.

Build the right thing#

Design reduces the likelihood of building the wrong thing. Every feature exists to serve some user need, and both the choice of which features to build and how each is designed are guesses about what will meet that need. The cheapest time to find out that the guess is wrong is before anything is built. The second cheapest is just after a thin slice is live and in front of real users. The later we learn, the more work there is to undo.

Four risks

Marty Cagan’s book Inspired describes four risks that every product idea carries:

Value: will anyone want it?
Usability: can they work out how to use it?
Feasibility: can we build it?
Business viability: does it work for the business?

The Product Manager owns value and viability, deciding which problems are worth solving and for whom. The designer leads on usability and brings evidence about what users value. The Tech Lead leads on feasibility. The risks are interdependent, which is why the three need to work on them together.

It helps to frame ideas of what could be built as hypotheses about what might meet a user need, which invites testing, rather than as requirements, which implies they are fixed.

Example hypothesis

We believe that letting customers save alternative delivery addresses
will reduce abandoned checkouts among repeat customers.
We will know this is true when abandonment at the address step falls for repeat customers compared with before the release.

Framing it this way makes clear that the feature is a bet, identifies what to measure, and makes it natural to test the idea as cheaply as possible before committing to build all of it.

Validating proposed solutions before implementation brings clear benefits:

Less rework. Problems found in a sketch cost minutes to fix. The same problems found after release cost a round of implementation, testing, and deployment, plus whatever inconvenience users experienced in the meantime.
Smoother flow. Items that arrive in implementation with the experience worked out move across the board without stalling on questions nobody in the room can answer.
More value from each slice. Every feature slice is a chance to learn. Good design makes sure each one tests something worth knowing.

The product trio#

The product trio consists of the Product Manager, a designer, and a senior engineer, usually the Tech Lead. Decisions the trio makes together during discovery don’t need to be explained and defended through hand-offs later. This avoids the common pattern of a relay where product decides what to build, design decides how it looks, and engineering builds it. Each hand-off loses context, and engineers only get to comment on feasibility once decisions have become costly to change.

When the Product Manager and the designer disagree about what users want, it is usually because they are working from different evidence, or in the absence of evidence. The best resolution is to go and find out, often cheaply, rather than to defer to whoever is more senior.

The Tech Lead contributes:

Feasibility and cost. Saying early which options are cheap, which are expensive, and why. Existing data, rules, and components can make one option much cheaper than another, or make a better solution possible. Constraints of third-party systems or cost and performance limits can rule options out entirely.
Decisions that are hard to reverse. How a solution is modelled gets built into the database, the APIs, and integrations with other systems. Deciding after release that an address belongs to an order rather than to a customer means reworking all of them. The Tech Lead can spot which choices carry this kind of cost, so those choices get the most scrutiny.
Consistency with what exists. Making sure the solution, and especially its conceptual model, doesn’t unknowingly disagree with how existing features are implemented.
Trade-offs while they are cheap. Choosing between a slightly better experience and a much cheaper build is a valuable conversation to have during discovery, so the team spends its time on the work that delivers the most value.
Continuity into delivery. Carrying the intent behind the design into refinement and implementation, so the team can make good decisions on details the design doesn’t cover.

Agree the conceptual model first#

Before committing to screen designs, the team should agree the conceptual model. Following Jeff Johnson and Austin Henderson ↗, the conceptual model has three parts:

Objects. The things users work with, what they are called, and how they relate to each other.
Actions. What users can do with each object, and the rules that apply.
Flows. The main tasks users will carry out, as sequences of steps using those objects and actions. These are often captured as a future-state journey map.

In an email client, the objects include messages, contacts, and labels. Whether a message sits in one folder or can carry several labels is a conceptual model decision. It shapes the screens, the data, and how users think about their email, and it is very expensive to change later.

Rough sketches can help explore the model, but it should be agreed before detailed wireframing starts. Otherwise, decisions about the model get made implicitly while screens are being drawn.

A current-state journey map ↗, built from research, is an input to help form the conceptual model. It captures how users experience the problem today and how they think about it: their mental model. The conceptual model is the team’s design for the solution, and it works best when it matches that mental model.

None of this needs to be elaborate. A row of sticky notes for the main flow, and a list of the objects and the actions on each, can be enough. Most of the value is in the conversation that produces it.

The names agreed here should carry through to the UI, the code, and conversations with the business — what domain-driven design calls a ubiquitous language. If the screens say “address book,” the code calls it “Location,” and the business says “delivery points,” every conversation needs translating, and misunderstandings slip through in the translation.

This is where the Tech Lead’s contribution to the product trio matters most, because changes to the conceptual model snowball through detailed designs and implementation.

Worked example: alternative delivery addresses

Take the item used throughout Definition of Done and Acceptance criteria: an existing customer adding an alternative delivery address. Before any screens are drawn, the team needs to answer questions such as:

Is an address a property of the customer (an address book), or of an order (entered at checkout and remembered)?
Is the billing address one of the saved addresses, or something separate?
If a saved address is edited, what happens to orders that have already been sent to it?
Do users think in terms of addresses at all, or of people and places, such as “home,” “work,” and “Mum”?

Some of these are answered in seconds once an engineer is in the conversation. The engineer knows that orders already keep a copy of the delivery address at dispatch, so editing a saved address can’t affect orders already sent. They also know that billing addresses are held by the payment provider, so treating them as saved addresses would mean a new integration. Neither fact is visible from the screens.

Research answers the last question. If customers think of saved addresses as named places, that suggests a nickname field and a different selection list. Each answer produces different screens, data structures, and acceptance criteria, and all of them are far cheaper to change on a whiteboard than after the address book has shipped.

Don’t rush to the pixels#

A common design mistake is jumping to full designs before the conceptual model and wireframes are agreed. It feels like progress, but it defers the important decisions until they are harder to change.

A wireframe shows the structure of a screen without the visual design: boxes, labels, and realistic content, usually in greyscale. Linked together as a clickable prototype, wireframes are enough to run a usability test. Because they are cheap, they are also the right place to explore alternatives: sketching three approaches and testing them is a morning’s work, while doing the same with finished designs takes a week.

Visual design comes last, once the conceptual model and structure are settled.

Low fidelity on purpose

Wireframes should look unfinished. People give honest feedback on something that looks rough, while polish invites comments on the polish.

Straight to high fidelity	Conceptual model and wireframes first
Feedback focuses on colours, fonts, and spacing, because that is what is in front of people.	Feedback focuses on whether the flow and structure make sense, which is where the important decisions are.
Effort invested in polish creates reluctance to throw it away, so weak concepts survive.	Artefacts are cheap, so weak ideas are easy to discard and alternatives are easy to explore.
Engineers receive the designs as a fixed specification to reproduce.	Engineers and testers join the conversation while it is still possible to change direction.
The conceptual model is implied by the screens and has to be reverse-engineered by whoever builds them.	The conceptual model is explicit and matches the domain model in the code.

Designing iteratively#

The walking skeleton approach applies to design as much as to code. Design the whole thin journey first, at low fidelity, with the simplest version of each step. Build that, put it in front of users, and then elaborate the steps that matter most. Jeff Patton’s Mona Lisa illustration ↗ shows the difference between incremental and iterative design: incremental design finishes one screen before starting the next, while iterative design produces a rough version of everything, then improves it, which is usually a faster path to learning.

Some designers are uncomfortable shipping something they consider unfinished, and that is worth discussing openly. The aim of early slices is learning, and feature flags let a rough version go to a small group of users first, so the wider user base only sees it when it is ready.

Design should run alongside delivery#

Some product and design teams fall into the trap of designing too much up front, with a “discovery phase” lasting months, producing a body of research and a full set of designs, followed by a “delivery phase” that builds them. This big-batch approach has all the downsides of waterfall: by the time the team starts building, some of what was learned is out of date, and the first feedback from working software arrives months after the key decisions were made. A short discovery focused on understanding the problem, like the discovery phase ↗ in the GOV.UK Service Manual, is a different thing and can be an effective approach.

Design works better as a continuous activity. Enough design is done up front to have confidence in a direction, and it then continues once building starts, informed by what the team learns from each slice. Teresa Torres calls this continuous discovery: at least weekly contact with customers through small research activities, rather than occasional large research projects.

Shape ahead, detail just in time#

The shape of the solution runs ahead. For a new feature, the research, conceptual model, and rough wireframes for the main flows need to run a few weeks ahead of development. The aim is enough confidence in the direction to slice the work and write sensible backlog items, not a complete design.

The detail comes just in time. For each backlog item, detailed wireframes, visual designs where needed, and the full set of states are worked out during elaboration, just before implementation. Detail produced just in time uses the most up-to-date information and is least likely to be wasted. With a design system in place, this detail is often light.

Ahead, not separate#

Where designers are not fully embedded in the delivery team, they usually work a small number of sprints ahead of development. This arrangement is often called dual-track agile, but the two tracks are two kinds of work within one team, not two teams. It is reasonable when the designer is shared between teams or part-time, since a small buffer of designed items avoids stalls. It becomes a problem when “ahead” turns into “separate.”

Designers should be members of the delivery team, not a service it consumes. That means attending the daily meeting, refinement, and retrospectives; reviewing built slices during implementation; and having design work visible on the board along with everything else.

Signs design has become a separate phase

Designs are described as signed off before engineers have seen them.
The designer doesn’t attend the daily meeting or refinement.
Questions during implementation wait days for an answer, because the designer isn’t available to answer them.
All the screens for a feature are designed before the first slice is built.
Changes to the design during implementation are treated as scope creep rather than learning.
Nobody from design looks at what was built.

Designers need access to users#

User research validates or falsifies assumptions about users. The most valuable research comes directly from current and prospective users, through interviews and usability tests. Second-hand sources such as sales notes, support tickets, and analytics are useful and cheap, but only give part of the picture. Support tickets tell us what went wrong for people who bothered to complain, but not what confused the people who quietly gave up.

Research doesn’t need to be large to be useful. Jakob Nielsen has argued ↗ that usability testing with around five users from each distinct user group uncovers most of the problems in a design, and that several small rounds are worth more than one large one.

Direct access to users is the biggest single factor in whether a designer can do the whole job. Lack of access is almost always an organisational constraint rather than a failing of the designer, and it is one a Tech Lead can help remove. Common obstacles, and ways round them:

Sales or account managers guarding the relationship. This is understandable, since they carry the risk if a relationship is damaged. Involve them: invite them to sessions and share what is learned.
“We already know what customers want.” This usually means senior people hold strong opinions and others defer to them, sometimes called the HiPPO effect (“Highest Paid Person’s Opinion”). Aim to have those opinions treated as hypotheses worth testing. An expensive failure built on untested assumptions, such as the Amazon Fire Phone ↗, can help make the case.
No budget or process for recruiting participants. A small incentive and a standing list of willing customers go a long way.
Regulated or enterprise customers. Access is harder but rarely impossible. Seek agreement at a senior level once, rather than negotiating session by session.

A simple test

Ask how many users the team has spoken to in the last month. If the answer is none, the team is building based on unvalidated assumptions, however confident it feels. Teresa Torres sets a higher bar: contact with customers every week.

Engineers need contact with users too#

Engineers who have seen people try to use their product make better calls on the many small decisions no design covers. They take error states and edge cases more seriously, and understand the devices, workarounds, and interruptions that would otherwise not be obvious. Watching a real person struggle with something the team built also connects the work to its purpose in a way no research report can.

Practical options include observing research sessions, listening in on support calls, visiting users where they work, and joining customer demos of built slices. Contact doesn’t need to be frequent, but it should be regular. The Product Manager or designer usually coordinates it, so that users aren’t overwhelmed and the relationships described above are protected.

Design systems#

A design system is a shared set of reusable components, patterns, and guidance for building interfaces consistently.

A design system exists in both design and code: a component library in the designer’s tool, such as Figma, and a matching coded library, often documented with a tool such as Storybook. The two must stay in step. A system that exists only in the design tool is a style guide that engineers reinterpret, and one that exists only in code leaves designers drawing components that can be at odds with the components as implemented.

A design system gives:

Consistency. The same thing looks and behaves the same way everywhere, so users learn it once.
Speed. Most screens are assembled from existing parts, so effort goes on what is genuinely new.
Quality built in once. Accessibility, responsive behaviour, and interaction states are solved in the component rather than on every screen.
Better flow. With a mature design system, an annotated wireframe that names the components is enough to build from for most items. High-fidelity designs are reserved for new patterns and screens where visual design is central, so design stops being a gate every UI item has to pass through.

Don’t reinvent the wheel

Most organisations should start from an existing design system, such as Material Design ↗ or IBM’s Carbon ↗, and adapt it. Building a design system from scratch is a large, ongoing investment that only makes sense at scale. The GOV.UK Design System ↗ is worth studying for its research-backed patterns, although only services on GOV.UK should use its visual style.

A design system needs named owners, usually a designer and an engineer working together, and a simple way for teams to propose new components. Without that, the two libraries drift apart and teams build local variants.

Common concerns#

Here are some objections you may encounter and how to respond to each:

“Having engineers in design sessions wastes their time.” An hour agreeing the objects, actions, and flows can save weeks of rework. Engineers don’t need to attend everything: the Tech Lead in the trio, plus a few research sessions and design reviews for the wider team, is usually enough.
“Our designer is shared, so they have to work ahead.” Working a little ahead is fine. What matters is that engineers help shape the conceptual model, the designer stays in touch with the work in progress, and detailed designs are produced just in time rather than in bulk.
“It’s quicker to go straight to finished screens.” It is quicker to produce something that looks finished. It is slower to reach something that works, because the decisions that matter are deferred until they are expensive to change.

Key points#

Design is mostly about shaping a solution that gives users what they need and can use, and only partly about how it looks.
The Product Manager, designer, and Tech Lead should shape solutions together, each owning a different part of the risk.
Agree the conceptual model (objects, actions, and flows) with engineering, and ideally validate it with customers, before designing screens.
Use low-fidelity wireframes to explore structure.
Design runs alongside delivery. Shape the solution weeks ahead, but work out item-level detail just in time.
Design iteratively, and treat each shipped slice as a test of a hypothesis.
Designers need direct access to users, and engineers benefit from regular contact with them too.
A design system in both design and code removes the need for high-fidelity designs of most routine screens.

Mistakes to avoid

Treating design as visual polish. Feature requests get built as asked, and how things work is decided by whoever implements them.
A long discovery phase followed by a delivery phase. Learning stops just as the team starts producing the thing it could learn most from.
Designers with no access to users. Design based only on opinion and second-hand information is guesswork with better presentation.
Designing screens before the conceptual model is agreed. The most expensive decisions are made implicitly and discovered during implementation.
Leaving engineers out until the designs are finished. Cost, constraints, and opportunities are found too late to shape the design.