HD·F2·03 Basic → Advanced
Design Process
A clear methodology for moving from problem to solution.
Design Process is the umbrella discipline of moving deliberately from an ambiguous brief to a validated solution. Design Thinking is one process model within it. This course covers linear and iterative models, the Double Diamond in depth as a dedicated module, and how to choose or adapt a process to fit the constraints of a real project.
In Development
This course's full module content is being written. The outline below is final, subscribe for updates when it publishes.
LEARNING OUTCOMES
- 01 Distinguish Design Process from Design Thinking and explain how they relate
- 02 Compare linear (waterfall) and iterative process models
- 03 Apply the Double Diamond as a structured problem-to-solution framework
- 04 Break a brief down into research, concept, development, and delivery phases
- 05 Select an appropriate process model for a given project's constraints
- 06 Document and hand off process work clearly to stakeholders
- Process makes quality repeatable, not accidental
- Every discipline has its own process vocabulary for the same underlying moves
- A process is a scaffold, not a straitjacket
- Linear models suit well-understood problems
- Iterative models suit ambiguous, user-facing problems
- Most real projects blend both
- Discover and Define diverge and converge on the right problem
- Develop and Deliver diverge and converge on the right solution
- Skipping the first diamond is the most common process failure
- Briefs are starting points, not specifications
- Unstated assumptions cause the most rework
- Constraints should be verified, not assumed
- Data is not insight until synthesised
- Affinity mapping surfaces patterns across research
- Insights should be falsifiable, not vague
- Generate breadth before depth
- Concepts should map back to specific insights
- Weak concepts are cheap; commit to none too early
- Criteria should be set before options are seen
- Desirability, feasibility, viability all matter
- A close second concept is often worth prototyping too
- Each loop should answer a specific question
- Novel problems need more loops than familiar ones
- Stopping too early leaves risk unresolved
- Match fidelity to the question being asked
- Low fidelity is often more honest feedback
- High fidelity too early anchors reviewers on surface details
- Validation should be planned before development starts
- Small-sample testing catches most usability issues
- A design is not finished until it is tested
- Document decisions, not just outputs
- Rationale prevents drift during implementation
- Handoff is a design deliverable, not an afterthought
- No single process fits every project
- Team maturity affects which process will actually be followed
- Adapting a process is itself a design decision