Product Design

The difference between designing the screen and deciding the screen should exist

Skip this step and you ship a feature everyone liked that changed nothing

A principle that costs you nothing to follow will never settle an argument

Five methods, two kinds of truth — what people say and what they actually do

Research arrives as a pile of moments; the experience it describes happens in sequence

Findings nobody can find get discovered again next quarter, at full price

Research gives you observations; framing turns them into one problem a team can argue with

The score is never the decision — the argument you have while producing the score is

Work users love but the business cannot justify is still work that gets cancelled

Late pushback is rarely about the design — it is about someone seeing it for the first time

Some of what you are assuming is load-bearing — work out which, and buy that answer early

If people cannot find the feature, you have not really shipped the feature

Generating options and judging them are separate jobs, and doing both at once produces neither

You know where every button is and what it means — which is exactly why you cannot test your own work

Testing tells you what is broken — measurement tells you whether you are getting better

Research that changes nothing is an expensive way to feel thorough

Colour, type, space, icons and emphasis — the five choices every screen you build afterwards inherits

Nothing stays consistent until the pieces have names — components, patterns, tokens, states

If an animation is not explaining something, it is delay you chose to ship

Most confusing interfaces are not badly drawn — they are badly worded

Who the product quietly shuts out, and which patterns work only because the user cannot see them working

Generating options is nearly free now — choosing well between them is still the whole job

The system you are designing for already exists, and it has opinions

Ask how long and you get a number; ask what worries them and you get the real schedule

Throwing a file over the wall is the moment you stop controlling the outcome

The bugs you catch before release are the last cheap ones

The best time to hear that something takes three months is before you have drawn it

A component library with no owner is a pile of old decisions quietly going out of date

As a design team grows, the craft holds up — the coordination around it does not

Nobody compares your Android app with your iOS app — they compare it with everything else on the phone

The metrics you chose before building are the ones that judge you after launch

Shipping a change and learning whether it worked are two different activities

The first release is your worst-informed version of the product; treat it that way