By 6days · v1.0 · Updated 7/20/2026
Understand the person, frame the real problem, build something rough, and learn from their reaction.
Fill this in for your own situation — a private worksheet only you can see.
When to use
Use it on ill-defined problems where the need is genuinely unclear, where the people affected are not you, and where the cost of building the wrong thing is high. It is strongest early, when the framing is still open and cheap to change.
When not to use
Avoid it when the problem is well-specified and the answer is known — it is expensive ceremony for work that needs execution. It struggles with problems whose constraints are technical or regulatory rather than human. And it is the most ritualised framework in common use: workshops, sticky notes and a five-stage poster routinely produce the appearance of the method with none of the substance, because nobody left the building to observe anyone.
Organisations solve the problem they were handed. A brief arrives already containing its solution — 'build a dashboard' — and a team spends six months building it well, only to find nobody uses it, because the actual difficulty was never a lack of a dashboard. The expensive error was committed before any work began, in accepting a framing nobody tested against a real person.
Design thinking is a loop for problems where the requirement is not yet known: understand the people affected, define the problem from what you learned rather than from the brief, generate many candidate solutions before judging any, build a rough artefact, and put it in front of someone. The sequencing carries the value. Defining after observing prevents you from solving the wrong problem, and prototyping before committing makes being wrong cheap. It is not linear — findings at the test stage routinely send you back to redefine — and treating it as a five-step process to march through is the most common way to get nothing from it.
Framework by 6days on 6days — https://6days.apexaion.ai/framework/design-thinking
An ordered process with 5 phases.
Observe the people in their situation.
Frame the real problem from what you saw.
Generate many options before judging any.
Build the crudest thing that can be wrong.
Put it in front of real people and learn.
Watch and talk to the people who live with the problem, where they actually encounter it. Watch what they do rather than trusting what they say; the workarounds they have stopped noticing are where the real problem is visible.
Write a problem statement grounded in what you observed, not in the brief you were handed. If your definition is identical to the original brief, you have almost certainly skipped the observing.
Produce many candidate directions with evaluation explicitly suspended. The first plausible idea is a local optimum and will kill the search if allowed to. Quantity first, judgement second, deliberately separated.
Build the crudest thing that could elicit a real reaction — paper, a clickable sketch, a manual process behind a form. Fidelity is not a virtue here; it is a liability, because polish makes people admire the artefact and makes you reluctant to discard it.
Put it in front of someone from the affected group and watch them struggle without helping them. Most tests send you back to define rather than forward to build, and that is the loop working rather than failing.
Worked example
A hospital is asked to reduce missed outpatient appointments and briefs a team to build an SMS reminder system. Observation first: patients who miss appointments overwhelmingly received the letter and remembered the date. The barriers are transport, unpredictable shift work, and a booking line answered only during working hours — the hours they are at work. The problem is redefined from 'patients forget' to 'patients cannot attend or rearrange within the constraints of their lives.' Prototypes: a text-back rescheduling line, evening slots, a standby list. The reminder system, which was the entire original brief, addresses a cause that barely exists.
The approach draws on design practice and cognitive research going back to the 1960s, with roots in work on the nature of design problems by figures such as Herbert Simon and Horst Rittel. Its current business form was shaped substantially by the firm IDEO and by the Stanford d.school from the 1990s onward. The five-stage articulation is one popular formulation among several, not a canonical definition.
Related ways to think about this.
Not all features are equal: some delight, some merely satisfy, and some only hurt when missing.
Use when Use it when a roadmap needs to balance table-stakes against differentiation, when entering an established category where expectations are already set, or when heavy feature investment is somehow producing no measurable satisfaction gain.
Avoid when Avoid it in a genuinely new category, where customers have no expectations to classify against and the survey returns noise. It is survey-based, so it inherits every weakness of stated preference — people are poor predictors of their own delight. It is also expensive to run properly and stale quickly; a three-year-old Kano study is a historical document.
People don't buy products, they hire them for a job — find out what the job is.
Use when Use it when demographic segmentation has stopped generating insight, when you cannot explain why customers churn or convert, when entering an adjacent market, or when a roadmap has become a queue of the loudest requests with no organising logic.
Avoid when Avoid it for incremental optimisation of a well-understood product — you know the job, and reopening it is procrastination. It is weak for infrastructure and compliance work with no discretionary hiring decision. Done badly it collapses into vague poetry about customer aspirations, and 'the job' becomes whatever the loudest person already wanted, now with better rhetoric.
Strip a problem back to what must be true, then rebuild — instead of copying what exists.
Use when Use it when an industry's costs or practices have been stable for a long time without obvious justification, when you are entering a field as an outsider and lack the incumbents' assumptions, or when repeated incremental attempts have all failed and the problem may be framed wrongly.
Avoid when Avoid it for routine decisions — it is slow, effortful, and analogy is right most of the time. It is also a common vehicle for arrogance: reasoning from first principles while lacking domain knowledge tends to rediscover why the convention exists, expensively. If experts cannot explain why a practice exists, that is worth investigating; if they can, listen.
