Design Process, Design Operations, Research
Understand, Explore, Bridge, Build, Refine: A Design Process for Scaling Teams
The five-phase product design process I wrote for Adaptive as we scaled to six independent pieces of software: one shared way to move from a problem to a delivered product, for design and research alike.
Adaptive Biotechnologies
- 01 Problem
New platforms, new teams, new tooling and many stakeholders, spread across six independent products. Without a shared process, coverage across design and research would depend on who happened to be in the room.
- 02 Approach
I wrote a five-phase process, Understand, Explore, Bridge, Build and Refine, with clear activities and questions for each phase and built-in loops to go back when the work needs it. We called it a draft on purpose, so it could change as we learned.
- 03 Outcome
One process, shared by design and research across six products, that tells every team what each phase is for, what to ask before moving on, and when it is right to loop back.
Product design process
01Understand
The work begins. A problem or goal is identified, and space and time are created to do the work. Thorough research, data collection and conversations build understanding, and familiarity with the subject begins. Hypotheses might be formed and theses written. The cycle may loop back on itself if results miss business goals or agile improvements are needed, and the problem may be redefined as understanding grows.
Questions we ask
- What is the problem?
- Why is this important?
- Who is it impacting?
- What are the business goals?
- What does success look like?
02Explore
Early design happens here, in low fidelity. Low-fidelity prototypes and wireframes are built, and freeform changes should happen. Feedback from product owners and business stakeholders is encouraged, and many iterations can be made. Boundaries keep the work focused, but ideas can be stretched.
Questions we ask
- What came out of our research?
- What did we learn?
- Can we prove or disprove our hypothesis?
- How can we delight the customer or user?
03Bridge
Explorations are demoed and challenged, critiques happen, stakeholders change their minds and the solution evolves. This is the bridge that must be crossed before work is finalized. The work may return to Explore or Understand before moving forward, to evolve it and be thoughtful.
Questions we ask
- Are we thinking outside the box enough?
- Did we interpret the problem correctly?
- What does the business think?
- What rethinking needs to happen?
04Build
Focused design happens here, in high fidelity. Collaboration with engineering or production happens, but stays organic as changes occur along the way. Nothing is final until we deliver. Business and product see the work in Figma, where comments and changes are discussed, and Figma becomes the delivery mechanism to the development team.
Questions we ask
- Did our prototypes solve the problem?
- Do we need to adapt more?
- If we test or demo, what critique came back?
- Can we make developers' lives easier with our delivery?
- What did users think?
05Refine
The work is about to wrap up, but not before the scope is trimmed and the work is measured. A project may never be delivered, in which case it is simply finished.
Questions we ask
- What did we learn?
- How can we make improvements?
- Did we create any technical debt?
- What can we evangelize as a team?
- How did this process open new questions?
Why I wrote it
Great solutions start with a process. A design process. We all have one, and this is mine.
To establish a high degree of coverage across new platforms, teams, tooling and their many stakeholders, I wrote and developed a new design process for Adaptive as we scaled to six independent pieces of software. It brings design and research into one flow. We called it a draft on purpose, to encourage it to change organically as we learned and grew together.
How it works
The process moves through five phases. Each one has its own work, its own activities and its own questions, and no phase is finished until its questions have answers.
- Understand. The work begins with a problem or a goal, and with making space and time to do it. Research, conversations and empathy for the user build understanding.
- Explore. Early design in low fidelity. Rapid prototypes and wireframes, many iterations, and feedback from product owners and the business.
- Bridge. Explorations are demoed, challenged and negotiated. This is the bridge that must be crossed before work is finalized.
- Build. Focused design in high fidelity, built with engineering. Nothing is final until we deliver.
- Refine. Scope is trimmed, the work is measured, and the team learns, reviews and evangelizes what worked.
Built to loop
The process is not a straight line. From Bridge, the work can return to Understand or Explore when the critique says the problem was misread. From Refine, it can return to Build for agile improvements. Those loops are a feature: they make it normal to go back and get it right, instead of pushing a weak solution forward.
The interactive version above is coded from my original diagram, which is shown below it and available as a PDF. Pick a phase to read its activities and the questions it must answer, or play the whole process, loop included.
"Usability is about people and how they understand and use things, not about technology." Steve Krug
Skills: Design Process, Design Operations, Design Thinking, UX Research, Team Leadership.