The design process

Empathize; define the project; ideation and modelling; designing a solution; presenting a solution.

Research findings from real users, a primary persona, and a user journey with pain points marked.

A problem statement, and a design specification whose criteria are testable and split into essential and desirable.

Because testing and users keep producing information that invalidates an earlier decision. A failed test sends you back to ideation; a missing requirement sends you back to the specification.

Diverge — generate many genuinely different approaches with judgement suspended — then converge, narrowing against the specification. They must never happen at the same time.

Brainstorming, mind mapping, thumbnail sketching, morphological analysis, and analogy or biomimicry.

They solve the problem by a different principle, so they fail and succeed for different reasons. If two ideas fail for the same reason, they are one idea.

Far enough to be judged and no further — card, foam or a quick CAD massing — all at the same fidelity, and modelling whatever part would kill the idea if it did not work.

The design specification and user needs — never personal preference. Criteria in the rows, ideas in the columns, every cell scored.

Score every cell, remove anything that fails an essential criterion, then use the desirables to choose between the survivors, and finally check the survivor against the persona.

Because several small desirables can then outvote a single essential — the exact decision the essential-desirable split exists to prevent.

An improved idea rather than a winner: the comparison shows which part of each idea was doing the work, and the developed design takes the best parts of several.

Model — build the cheapest thing that answers the current question. Test — with real users, measuring something. Refine — change the design because of what happened. Then repeat.

Because the questions get harder. Reach can be answered with card at the right height; stability needs real weight and real materials.

So an improvement can be attributed to a known change. Two changes at once hide which one worked, and can hide one making things worse.

When every essential criterion has been measured and met — not at the deadline and not when the model looks finished. Criteria not yet met are recorded honestly.

To generate performance data when tested with end-users — not to show what the product will look like.

From the question being asked. Card at the right height answers reach; a real pivot answers grip; real materials answer stability and mass.

Decide the measurement before the users arrive, give a task rather than an opinion prompt, do not help or explain, and record exactly the quantity the specification criterion names.

Because a printed part is weak across its layers and a card model has no weight. An evaluation that claims more than the model could show is worth less than one that names its limits.

Dimensioned orthographic views of every part, dimensions from a datum, a stated scale, detail views of joints at a larger scale, and an exploded assembly with numbered parts and a parts list.

Chained dimensions accumulate error along the chain; from a single datum each error stays independent.

Could somebody who has never seen the prototype build it from these sheets alone, without asking a question? Anything missing becomes a decision somebody else makes for you.

It carries appearance and proportion but no dimensions, scale, sections, materials or parts list — nothing can be cut or ordered from it. Its job is presenting the solution.

Why does this need to exist, what does it do, and how do you know it works — in that order.

It makes a point faster than a sentence could: the feature shown in use, a ghosted view of something hidden, or a section proving a claim such as cleanability.

Because measuring the miss and naming the next step reads as control of the project, while dropping the line reads as not having tested — and the gap is easy to see.

On the design intention, in the words of the problem statement — the stated need, now met — and, for a specific audience, what it changes for them.

Primary is first-hand data you collected for this project. Secondary is data collected and published by a third party for their own purposes.

Qualitative describes — reasons, feelings, behaviour, the users' own words. Quantitative counts — times, frequencies, dimensions, percentages.

Your own timings, tallies or measurements: for example how many seconds a nurse spends repositioning a table, recorded across twenty meals.

It is fast and free, it sets the standards and numbers you cannot measure, and it stops you spending limited primary hours on a question that is already answered.

User observations, interviews, surveys, questionnaires, focus groups, material testing and product analysis.

User requirements, design specification criteria, the persona, and suggestions for further development of a solution.

A stated condition rather than a vague quality — 200 wipes with a named disinfectant, not "is it durable" — plus identical samples, the same procedure each time, and a control.

Opinions tend to support whatever the designer already planned. A behaviour question produces a count that can contradict you, which is the only kind worth the hours.

Internet-based research, government data and statistics, university research, and a literature search.

To support or validate primary research: it supplies population data and standards you cannot measure, and it shows whether your own finding is normal or unusual.

Who wrote it and what do they gain? When was it produced? Where did their numbers come from, and from how many people? Who checked it before publication?

Nobody can check who produced it or how, so the figure cannot be defended. Citing also exposes the case where several of your sources are repeating one original.

Findings about users' experience, motivations and interactions — written up as a persona for each user group, plus a journey with pain points.

It is a problem the user found serious enough to solve themselves, so it shows both the problem and the kind of solution that is acceptable to them.

Name the groups, choose a primary and say why, then accommodate the others where it costs the primary nothing — resolving the conflict with a feature rather than averaging it.

They explain behaviour that otherwise looks irrational. A patient unwilling to be a nuisance will not press a call button, which rules out solutions that depend on asking for help.

The whole experience of carrying out a task, drawn as a storyboard of frames in order — starting before the user touches the product and ending after they leave it.

Marking how the task is going at each frame, so the troughs become visible. A trough you can point at is much harder to argue with than a sentence.

A frame where the journey goes wrong — the user hesitates, does extra work, feels unsafe or gives up. Each one must be stated as an observed action and effect.

A design opportunity: something specific enough to sketch and then test. A storyboard with troughs and no opportunities has diagnosed a problem and left it there.

Function — what it is for and what each part contributes. Performance — how well it does it, in numbers. Features — what it has, who each one serves, and which are never used.

It is the only one that produces baseline numbers. Without them, "better than the existing product" cannot be claimed or tested.

Either it is not needed — so it can go, freeing cost and weight — or it is not understood, which is a usability failure. Both are findings.

State the problem abstractly, find any product that solves it, and borrow the principle rather than the shape — then name the constraint that stops you copying it outright.

WHO has the problem (a recruitable group), what they NEED A WAY TO do (an outcome, never a product), and BECAUSE — the research insight with its evidence.

Because every idea generated afterwards becomes a variation of that one solution, so ideation has been decided before any analysis happened.

Could someone else recruit your users from it? Does it name an outcome rather than a product? Is the BECAUSE something you found out? Would three very different ideas all satisfy it?

It is what the final evaluation is judged against — whether the stated need is now met. A statement too vague to answer that was never specific enough.

A finding behind it, a statement of what the solution must DO, a number or condition, a test, and a band — essential or desirable.

Essential: the solution fails without it, so it filters ideas out. Desirable: a real improvement taken if it costs nothing else, used to break ties between ideas that all pass.

"Made from aluminium" writes a solution into the specification and rules out better ones. The criterion is the behaviour aluminium was wanted for.

To compare ideas against each other, to decide when development is finished, and to structure the final evaluation — which is why a vague one costs marks three stages later.