End-to-end product design process

Product design has gained a foothold in business in the past decade, although is still an emerging field — and many (enterprise) companies struggle with how to best integrate designers into the product life-cycle.

This article explains how I incorporate design into product teams. As team is unique, this is by no means a single source of truth that works regardlessly, but rather a structure as a guiding start point.

June 20, 2024

·

10

 min read

Product design provides value across the entire life-cycle illustrated above. It can be broken down into 3 phases:

  • Product definition (strategic phase)
  • Discovery track (dual-track agile)
  • Delivery track (dual-track agile)

Product definition (strategic phase)

Idea gathering and market sensing

Product management receives a constant feed of enhancement requests from customers. Among other sources, product management also generates or fields ideas from market research, development road maps, senior leadership, customer support, and metrics being generated from the product post-release.

Product design involvement
A well-integrated product designer is actively engaged with customers (participating in user research, visiting customers, etc); and therefore able to contribute in early-stage ideas for consideration.

Product discovery and Validation Research

Product management receives a constant feed of enhancement requests from customers. Among other sources, product management also generates or fields ideas from market research, development road maps, senior leadership, customer support, and metrics being generated from the product post-release.

Product design involvement
A well-integrated product designer is actively engaged with customers (participating in user research, visiting customers, etc); and therefore able to contribute in early-stage ideas for consideration.

The Product Roadmap

The most valuable ideas end up in the product roadmap. For bigger ideas, after validation research (concept and strategic one-pagers sign-off), for smaller ideas. It is a reflection of the company’s vision. Balancing costs and technical hurdles against strategic objectives (such as improved user experience). The roadmap serves as the north star. Smaller ideas/iterations on existing features can end up directly in the design discovery backlog. (See discovery track).

The ideas coming out of the product roadmap are problems to be solved, and we want to make sure we’re shipping the right solution.

Product design involvement
It’s helpful to have a product designer involved in roadmap plannings when implementing changes that impact users' behavioral patterns. A product designer commonly has a good sense of how changes should be rolled out to minimize pain and maximize adoption.
The product designer is available to help create well-articulated problem statements that describe the problem to be solved from the persona's point of view. A use scenario with market evidence and real-world context help design frame the solution.
From a design planning perspective: features to be delivered within the next few releases are generally considered to be iterative enhancements with minimal UX/design changes, while long-term strategic objectives require more time to explore and validate with customers.

The delivery track (dual-track Agile)

The discovery sprint will result in most of the high-level strategic UX work being done and documented in sprints well ahead of delivery picking up a story. However, continual improvement means we’ll never truly be done. Throughout the process, we listen, learn, and course-correct — even post-release.

Agile development teams need to be empowered to do collaborative UX design and implementation to improve product usability with each iteration. For an organization to make this a reality we need a few things in place: A centrally controlled design system, UX implementation specialists, and product analytics.

The discovery track (dual-track Agile)

The first track is about research. The discovery team (minimum a Product Designer and PM) works well ahead of delivery to uncover customer problems, define requirements, explore solutions and validate the designs. Each sprint includes multiple stages: Understand, Explore, Build and Test.

One important element to address here to make a dual-track agile work: Agile development avoids Big Design Up-front (BDUF). Believing instead that the right designs will emerge from self-organizing teams extending the design as needed to deliver the next increment of functionality.

However, emergent design does not address the complexity of large-scale business and design challenges. Individual scrum teams working within tight deadlines cannot be expected to have a complete understanding of their companies' larger business and UX design strategies; which makes it likely that teams will deliver conflicting patterns and redundant designs.

At some point, the product designer needs to be given the time to provide a well-documented direction that empowers delivery teams to implement new features with a consistent user experience. For a design team, this means defining an overarching UX strategy and the artifacts to enable delivery: a design system complete with the personas, UX principles, and the design patterns.

Every product designer shares a product discovery Kanban board together with the PM of the respective product line for prioritization, transparency and managing ideas from the discovery backlog.

Bigger design work
For bigger design work, the design track generally follows the “Double Diamond” diagram presented by the British Design Council. The phases first widen out to explore and then narrow in on a solvable problem/solution.

Discovery sprints occur well ahead of delivery sprints and as with agile development sprints, a design sprint focuses on a single story. However, depending on the complexity of the problem they may require longer timelines to allow for exploration (4–6 weeks for example). Google Ventures has popularized a method of compressing this process into a 5-day sprint. It involves having key stakeholders (including the decision-maker) in a room for five days. Unplugging key team members from their day-to-day schedules for a week is no simple task — so the 5-day sprint is best reserved for particularly troublesome issues or for kicking off those key strategic initiatives with high visibility.

Smaller design/iteration work
For smaller design iterations, and well-scoped design work, the process can be shortened. In this case, our hypothesis-driven design canvas can be used.

Understanding the problem: Discover and define

A design sprint begins with an understanding of the problem to be solved. In order to arrive at the right solution we need to fully understand all the issues. Discovery is a research phase wherein the team meets with key stakeholders, domain experts and customers to fully understand the entirety of the issues being addressed. With a renewed empathy for the end-user’s unmet needs and a clear understanding of the related technical constraints and business requirements the team can now define the desired outcome for the user — the problem to be solved.

Designing a Solution: Explore and Build

The design team will again widen their focus to explore a wide range of potential solutions to the defined problem. This is the creative paper and whiteboard stage: brainstorm, sketch, debate, sleep on it, try again. Ultimately the team will want to converge back into a testable solution and build a prototype. However, they may not reach a consensus on a single design so rather than continue debating they’ll move forward with multiple prototypes.

Prototype Testing: Permission to Fail

Designers build prototypes to validate ideas (potential solutions) with end-users. Research participants are asked to complete tasks using the prototype; which at this stage should look and feel like working software. A user's response will tell us if we’re headed in the right direction: Is it useful, usable, and desirable? Yes: move it on to development. No: back to the drawing board.

“No isn’t a bad outcome. In fact, it may have just saved the company from directing massive budgets into a feature destined for failure. In some ways, the design process and a product designer's job are to fail and recover while it’s still cheap to do so. The final stage of the product life- cycle is delivery and the design process weeds out the weak ideas, making sure the company is delivering the right solutions.

The discovery track (dual-track Agile)

The first track is about research. The discovery team (minimum a Product Designer and PM) works well ahead of delivery to uncover customer problems, define requirements, explore solutions and validate the designs. Each sprint includes multiple stages: Understand, Explore, Build and Test.

One important element to address here to make a dual-track agile work: Agile development avoids Big Design Up-front (BDUF). Believing instead that the right designs will emerge from self-organizing teams extending the design as needed to deliver the next increment of functionality.

However, emergent design does not address the complexity of large-scale business and design challenges. Individual scrum teams working within tight deadlines cannot be expected to have a complete understanding of their companies' larger business and UX design strategies; which makes it likely that teams will deliver conflicting patterns and redundant designs.

At some point, the product designer needs to be given the time to provide a well-documented direction that empowers delivery teams to implement new features with a consistent user experience. For a design team, this means defining an overarching UX strategy and the artifacts to enable delivery: a design system complete with the personas, UX principles, and the design patterns.

Every product designer shares a product discovery Kanban board together with the PM of the respective product line for prioritization, transparency and managing ideas from the discovery backlog.

Bigger design work
For bigger design work, the design track generally follows the “Double Diamond” diagram presented by the British Design Council. The phases first widen out to explore and then narrow in on a solvable problem/solution.

Discovery sprints occur well ahead of delivery sprints and as with agile development sprints, a design sprint focuses on a single story. However, depending on the complexity of the problem they may require longer timelines to allow for exploration (4–6 weeks for example). Google Ventures has popularized a method of compressing this process into a 5-day sprint. It involves having key stakeholders (including the decision-maker) in a room for five days. Unplugging key team members from their day-to-day schedules for a week is no simple task — so the 5-day sprint is best reserved for particularly troublesome issues or for kicking off those key strategic initiatives with high visibility.

Smaller design/iteration work
For smaller design iterations, and well-scoped design work, the process can be shortened. In this case, our hypothesis-driven design canvas can be used.

Understanding the problem: Discover and define

A design sprint begins with an understanding of the problem to be solved. In order to arrive at the right solution we need to fully understand all the issues. Discovery is a research phase wherein the team meets with key stakeholders, domain experts and customers to fully understand the entirety of the issues being addressed. With a renewed empathy for the end-user’s unmet needs and a clear understanding of the related technical constraints and business requirements the team can now define the desired outcome for the user — the problem to be solved.

Designing a Solution: Explore and Build

The design team will again widen their focus to explore a wide range of potential solutions to the defined problem. This is the creative paper and whiteboard stage: brainstorm, sketch, debate, sleep on it, try again. Ultimately the team will want to converge back into a testable solution and build a prototype. However, they may not reach a consensus on a single design so rather than continue debating they’ll move forward with multiple prototypes.

Prototype Testing: Permission to Fail

Designers build prototypes to validate ideas (potential solutions) with end-users. Research participants are asked to complete tasks using the prototype; which at this stage should look and feel like working software. A user's response will tell us if we’re headed in the right direction: Is it useful, usable, and desirable? Yes: move it on to development. No: back to the drawing board.

“No isn’t a bad outcome. In fact, it may have just saved the company from directing massive budgets into a feature destined for failure. In some ways, the design process and a product designer's job are to fail and recover while it’s still cheap to do so. The final stage of the product life- cycle is delivery and the design process weeds out the weak ideas, making sure the company is delivering the right solutions.