An eight-step process for digital product teams that turns a vague request into a tested, built and measured feature, without heavy ceremony.
In short
A good product design process moves each feature through two phases: first understand and frame the problem, then explore, test and deliver a solution. In practice that means eight steps, from a written problem statement and a quick look at users, through a tested prototype, to a designed-for-build hand-over and measurement after release.
Many teams do have a design process, but it lives in one designer's head, or it starts at the mockup stage. This guide from Devies, a Gothenburg-based product and engineering consultancy, is for product owners, designers and engineering leads who want a shared, repeatable way to go from problem to shipped feature. It defines product design, outlines the underlying model and gives an eight-step process that fits a small team.
What is product design?
Product design, in digital product teams, is the work of deciding what a product should do for its users and how it should do it, combining research, interaction design and interface design into features that can be built and measured. A product designer is the person who carries that work across the whole cycle.
The term is ambiguous, especially in Sweden. Produktdesign often means industrial design of physical objects. This table separates the meanings:
Term
What it is
Focus
Digital product design
What it is
Designing the behaviour and interface of software products
Focus
User problems, flows, interface, outcomes
Industrial product design (produktdesign)
What it is
Designing physical products for manufacture
Focus
Form, materials, ergonomics, production
UX design
What it is
Shaping the full experience of a product and service
Focus
Research, structure, usability
Product development process
What it is
The wider journey from idea to release, including engineering and launch
Focus
Planning, building, releasing
This article covers the first meaning. For the wider engineering and release journey, see our guide to the product development process for digital products.
What does a good product design process look like?
A good product design process alternates between opening up and narrowing down: first around the problem, then around the solution. The UK Design Council's Double Diamond names these four stages Discover, Define, Develop and Deliver, and it has been a common reference since the Design Council formalised it in the 2000s.
- Discover: understand the problem by spending time with the people affected, rather than assuming.
- Define: use what you learned to frame the challenge clearly.
- Develop: generate and co-design several possible answers.
- Deliver: test at small scale, drop what does not work and refine what does.
The model is useful because it makes one common failure visible: jumping straight from a request to a single solution. The GOV.UK Service Manual's description of the discovery phase makes the same point bluntly for public services: you should not start building in discovery, and it is not a failure to stop if research shows the service is not needed.
How do you take a feature from problem to shipped?
Take each feature through the same eight steps, scaling the effort of each to the size and risk of the feature. A small change may pass through all eight in a few days; a new product area may take weeks.
- Write a problem statement. One or two sentences: who has the problem, what they are trying to do, what stops them, and how you will know it is solved. If nobody can write it, the request is not ready.
- Check what you already know. Look at support tickets, analytics, sales notes and earlier research before planning new research. A customer journey map often shows where the problem sits in the wider journey.
- Talk to a few users. Short interviews or observation with five or so people in the target group usually reveal whether the problem is real and how they work around it today.
- Agree scope and a success measure. Decide what is in and out, and pick one measure, such as task completion, time saved or fewer support contacts.
- Explore more than one solution. Sketch at least two or three different approaches with a developer in the room. The first idea is rarely the best one, and technical constraints surface early.
- Prototype and test the riskiest part. Build the cheapest prototype that can answer the biggest open question and test it with users. Change direction here, where it is cheap.
- Design for build. Specify every state, error and edge case, use the design system's components, and check accessibility before hand-over. Pair with developers rather than handing over a file.
- Ship, measure and learn. Release, compare the success measure against the baseline, and feed what you learned into the next problem statement.
Steps 1 to 4 belong to the first diamond; steps 5 to 8 to the second. Teams that skip the first half often build the wrong thing well.
How do you keep the process light for a small team?
Keep it light by matching the depth of each step to the risk, by working in small cross-functional groups and by letting tools take over repetitive work. The steps stay the same; their size changes.
- Scale research to risk. A label change needs a quick check; a new pricing flow needs real user sessions.
- Make decisions visible, not documents long. A one-page brief per feature, with the problem, measure, chosen option and test results, is enough for most teams.
- Design inside the team. Designers who attend planning and review catch problems that a separate design phase would miss.
- Invest in a design system. Reusable, documented components remove most of the repetitive design and implementation work.
Devies saw what a lean, tool-supported process can achieve when building SEVR Insights, an AI-driven platform for accounting consultants. According to the SEVR Insights case, a team of three developers and one designer took the platform from concept to production-ready in four months, using an AI-first development process and a design system of atomic components connected to Figma, so developers worked from consistent, documented components.
What goes wrong most often in the product design process?
The most common failures are starting from a solution instead of a problem, testing too late, and treating hand-over as the end of design. Each has a simple counter-measure.
- Solution-first requests. "Add a dashboard" is a solution. Ask what decision the user needs to make, and write that as the problem.
- No success measure. Without one, every release looks like a success. Agree the measure before designing.
- Testing only finished designs. Polished screens invite comments on colour, not on whether the flow works. Test rough prototypes first.
- Missing states. Empty, loading, error and permission states left undesigned are invented under deadline pressure in code.
- No follow-up after release. Without measurement, the team cannot tell good decisions from lucky ones.
Keep reading
From our work
Client Case: Lea BankLea Bank rebuilt its digital platform with Strapi, React, GrowthBook, GA4, and BigQuery to improve SEO, A/B testing, and marketing autonomy.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is the difference between product design and UX design?
In digital teams the two overlap heavily. UX design focuses on the user's experience: research, structure and usability. Product design adds explicit responsibility for business outcomes and for following a feature from problem to release and measurement. A product designer typically does UX and UI work, and also works closely with the product owner on priorities and success measures.
How long does a product design process take?
It depends on the size and risk of the feature. A small improvement can go through all steps in a few days, with a quick user check and a short design review. A new product area may need several weeks of discovery and testing before development starts. The aim is not a fixed duration but enough evidence to make the next decision with confidence.
Do we need a designer to follow a product design process?
A designer makes the process faster and the results better, but the steps themselves do not require one. Product owners and developers can write problem statements, talk to users and test simple prototypes. A designer adds skill in exploring options, prototyping, interaction and visual design, and in making the product consistent through a design system.
Is the Double Diamond still relevant?
Yes, as a mental model. The Double Diamond describes the rhythm of exploring and narrowing that good design follows, first for the problem and then for the solution. Treat it as a reminder not to skip problem framing, not as a rigid sequence: in practice teams loop back, run several diamonds in parallel and repeat the second diamond many times after launch.
