Read with: Engineering is strict. Design is open.
Design is part of the solution, and so is being able to explain it. These are the practices I use to reason about a design, argue for a redesign, and know when not to.
Customer conversations: the Mom Test
Ask someone whether your idea is good and they'll be kind, the way your mom would. So, following Rob Fitzpatrick's The Mom Test, I don't pitch:
- Talk about their life, not your idea
- Ask about specifics in the past, not opinions about the future
- Talk less and listen more
What people already did, and what they'll commit to now, decides what gets designed. There's a worked example in the Scoreboard post.
Intuition: when to go, and when not to
- Go looks like go: one clear primary action, labelled with what it does.
- Not yet looks like not yet: a disabled button that says what's missing.
- Stop costs a moment, saved for deleting, paying, or sending to everyone.
- Undo beats "Are you sure?".
- Feedback answers every tap.
The same signals apply to me as the designer. I decide on the spot when a change is cheap to undo and a pattern I've seen work. I stop and check when it's hard to reverse, touches a lot of people, or is new territory. When instinct and evidence disagree, that's usually the most useful thing I learn.
Information architecture
Get the structure right before the screens.
Wireframing
Wireframes surface issues early and give people something concrete to react to, before pixels are spent.