Download All Four Product Design Checklists
I’ve made all four frameworks available as downloadable PDFs for designers, product managers, design teams, and anyone involved in building digital products.
01 — Product Design From Zero
For new products and true zero-to-one initiatives.
02 — Improving an Existing Product
For diagnosing and improving measurable outcomes in an already-launched product.
03 — New Feature / Capability
For validating and integrating meaningful new capabilities into an existing product.
04 — Major Redesign / Product Transformation
For fundamentally rethinking a legacy product or major experience architecture.
One of the most common mistakes in product design is applying the same process to every project.
A new product, an existing product with performance problems, a new feature, and a major product transformation may all involve research, design, validation, and delivery — but they should not start from the same place.
The context is different.
The evidence available is different.
The level of uncertainty is different.
And most importantly, the decisions we need to make are different.
Over time, I have found it useful to think about product design work through four distinct approaches:
- Product Design From Zero
- Improving an Existing Product
- Adding a New Feature or Capability
- Major Redesign / Product Transformation
I created an end-to-end checklist for each approach to help designers and product teams choose the right activities, ask the right questions, and maintain a clear connection between evidence, decisions, and measurable outcomes.
These checklists are not intended to be rigid waterfall processes. Depending on the product, team, evidence, and level of uncertainty, activities may overlap, repeat, or sometimes be unnecessary.
The goal is not to follow every step mechanically.
The goal is to make product decisions deliberately.
1. Product Design From Zero
When to use this approach
Use this approach when you are designing:
- A completely new product
- A major new product line
- A true zero-to-one initiative
- A product where very little validated knowledge already exists
The biggest challenge in zero-to-one product design is uncertainty.
At the beginning, teams often have ideas, stakeholder assumptions, feature requests, market beliefs, or technical possibilities — but these should not automatically be treated as validated user needs.
The process therefore starts by separating what we know from what we assume.
The journey typically moves through:
Strategic Context → Discovery → Research → Synthesis → Problem Framing → Product Definition → Ideation → Architecture & Flows → Interaction Design → Validation → Delivery → Launch → Measurement
A critical mindset for this type of work is:
Do not confuse a signal with a problem, a problem with a cause, an assumption with evidence, or a proposed feature with a validated solution.
That principle is particularly important in early-stage product development, where teams can easily move from an idea directly into interface design.
Instead, the goal is to create a strong chain between:
Evidence → Problem → Opportunity → Product Decision → User Outcome → Business Outcome
Download the checklist
Product Design From Zero — End-to-End Product Design Checklist
The checklist covers the full process from strategic context and discovery through user research, synthesis, problem framing, product definition, IA, flows, prototyping, accessibility, engineering collaboration, launch, measurement, and case-study documentation.
2. Improving an Existing Product
When to use this approach
Use this approach when you join or work on a product that already has:
- Existing users
- Real behavioral data
- Customer feedback
- Existing workflows
- Business metrics
- Technical constraints
- Previous product decisions
This environment requires a very different approach from zero-to-one design.
One of the biggest mistakes is restarting discovery as though nothing is known.
The opposite mistake is equally dangerous: opening Figma and immediately redesigning the current experience.
Instead, the first step should be understanding the product as it exists today.
That includes:
- The current experience
- Existing user behavior
- Product metrics
- Customer feedback
- Previous research
- Business priorities
- Technical and operational constraints
You need a baseline before attempting to improve anything.
From there, signals such as funnel drop-offs, support complaints, usability problems, retention issues, low adoption, or operational inefficiencies can be investigated.
The process becomes:
Baseline → Signal → Diagnosis → Opportunity → Hypothesis → Intervention → Validation → Release → Measurement → Learning
The distinction between signal and root cause is especially important here.
A drop in conversion is a signal.
Customer complaints are signals.
Low feature adoption is a signal.
None of them automatically tells us what the actual problem is.
The designer’s job is to combine behavioral data, qualitative evidence, business context, and user research to understand why the problem is happening before choosing an intervention.
Download the checklist
Improving an Existing Product — End-to-End Product Design Checklist
The checklist deliberately begins with product orientation, current-state assessment, baseline metrics, and existing evidence before moving into diagnosis, opportunity mapping, hypotheses, solution exploration, validation, rollout, and post-launch measurement.
3. Adding a New Feature or Capability to an Existing Product
When to use this approach
Use this approach when a product already exists but the team is considering adding a meaningful new capability.
Feature projects often begin with statements such as:
“Customers are asking for this feature.”
“Our competitors already have it.”
“Sales needs this capability.”
“Leadership wants this on the roadmap.”
All of these signals may be important.
But a feature request is not automatically a validated problem.
Before designing the feature, we should understand:
What underlying user or business problem is this capability expected to solve?
Sometimes the requested feature is the right solution.
Sometimes an existing capability can solve the problem.
Sometimes the answer is a workflow, policy, content, automation, integration, or operational change instead.
Once the need has been validated, another major challenge appears:
Integration.
A feature cannot be designed in isolation from the rest of the product.
We need to consider:
- Existing information architecture
- User mental models
- Roles and permissions
- Existing workflows
- Data relationships
- Design-system patterns
- Discoverability
- Product complexity
- Effects on adjacent features
The process therefore becomes:
Context → Need Validation → Opportunity → Hypothesis → Integration → Validation → Controlled Release → Adoption & Outcome Learning
Successful feature design is not simply about whether users use the feature.
The more important question is:
Does the capability create measurable value without damaging the existing product experience?
Download the checklist
New Feature / Capability in an Existing Product — End-to-End Product Design Checklist
This framework starts by challenging the feature request itself and then evaluates strategic fit, measurable outcomes, integration into existing workflows, validation, controlled rollout, adoption, and whether the feature should ultimately be expanded, repositioned, simplified, or removed.
4. Major Redesign / Product Transformation
When to use this approach
Sometimes incremental improvements are no longer enough.
A product may have:
- A legacy architecture
- Fragmented workflows
- Major technical debt
- Significant changes in user needs
- A new target market
- A new business model
- Platform consolidation
- Regulatory changes
- A major strategic shift
This is where a product transformation approach becomes necessary.
However, a major redesign should not automatically become a blank-sheet exercise.
Existing products contain valuable knowledge.
Users have already developed habits.
Some workflows already work.
There may be years of analytics, customer research, product decisions, integrations, and operational knowledge embedded in the current system.
The challenge is therefore to determine:
What should be preserved?
What should be redesigned?
What has fundamentally changed?
What legacy constraints no longer make sense?
And:
What new product architecture is required for the future state?
The transformation process can be summarized as:
Preserve Evidence → Diagnose Structural Limits → Rediscover Changed Needs → Define Future State → Re-architect → Validate → Migrate → Measure
Migration is particularly important.
Moving users from the old product to a new one is not simply an engineering or operational task.
Migration is part of the user experience.
Data, settings, workflows, habits, onboarding, support, communication, and learnability all need to be considered.
Download the checklist
Major Redesign / Product Transformation — End-to-End Product Design Checklist
The framework explicitly covers the transformation trigger, ecosystem audit, legacy evidence, discovery, future-state strategy, architecture, migration, concept validation, rollout, post-transformation measurement, and eventually retiring the legacy experience only when migration and outcome criteria are strong enough.
How Do You Choose the Right Approach?
A simple way to think about it is:
| Product situation | Recommended approach | Start by asking |
|---|---|---|
| There is no existing product | Product Design From Zero | What problem is worth solving, for whom, and why? |
| The product exists and needs better outcomes | Improving an Existing Product | What is happening today, and what does the evidence tell us? |
| The product exists and needs a new capability | New Feature / Capability | What underlying problem does this feature actually need to solve? |
| The current product structure is no longer sufficient | Major Redesign / Transformation | What should we preserve, and what fundamentally needs to change? |
The difference matters.
If you treat an existing product like a zero-to-one project, you may ignore years of valuable evidence.
If you treat a major structural problem as a small optimization project, you may spend months improving symptoms.
If you treat every feature request as a requirement, the product can gradually become more complex without becoming more valuable.
And if you treat a transformation as a visual redesign, you may change the interface without solving the structural problems underneath it.
The Checklists Are Decision Tools, Not Process Rules
These frameworks are intentionally comprehensive.
That does not mean every team should perform every activity on every project.
Senior product design is not about following a process mechanically.
It is about understanding:
- What we already know
- What remains uncertain
- Which assumptions create the greatest risk
- What evidence is required
- Which decisions need to be made
- How success will eventually be measured
Different stages may happen in parallel.
Some may repeat.
Others may be skipped when strong evidence already exists.
What matters is preserving the reasoning chain behind the product.
Final Thought
There is no universal product design process.
The right process depends on the state of the product, the evidence available, the uncertainty we are trying to reduce, and the decisions that need to be made.
Instead of asking:
“What is the product design process?”
A better question may be:
“What kind of product design problem are we solving?”
That question changes everything.
About the Author
Mohammad Samari
Senior Product Designer
I work across product strategy, user research, UX/UI design, and complex digital product experiences, with a growing focus on AI-powered and human-AI products.