Revision Cheat Sheet
By Pritesh Yadav 3 min read —
A fast, scannable recap of the whole guide. Read it before you ship any screen.
The core principles
- Absorb complexity so the user doesn't have to. Hard problem, obvious surface.
- Design for the job, not the feature — what progress is the user trying to make?
- Match the mental model — make it work how they already think it works.
- Close both gulfs — make actions findable (execution) and results clear (evaluation).
- Cut cognitive load — show less, group the rest, recognition over recall.
- Default to what 90% want so most users configure nothing.
- Every state is mandatory — handle loading, empty, and error, always.
- Never show raw output — no codes, UUIDs, or stack traces; plain language only.
The laws of UX (quick reference)
| Law | What it says | So you should… |
|---|---|---|
| Hick's Law | More choices = slower decisions | Trim or stage options |
| Miller's Law | ~7 items fit in short-term memory | Chunk & group content |
| Fitts's Law | Bigger, closer targets are faster | Make key buttons large |
| Jakob's Law | Users expect your app to work like others | Follow known patterns |
| Peak-end rule | Judged by peak & ending | Design strong peaks & clean endings |
| Curse of knowledge | Experts forget what's confusing | Test with real beginners |
Nielsen's 10 usability heuristics
- Visibility of system status
- Match between system & the real world
- User control & freedom (undo / escape)
- Consistency & standards
- Error prevention
- Recognition rather than recall
- Flexibility & efficiency of use
- Aesthetic & minimalist design
- Help users recognize & recover from errors
- Help & documentation
The "make it obvious" checklist
- Placement — is it where someone would intuitively look?
- Label — plain words, no jargon (Store Name, not slug)?
- Signifier — does it look clickable/draggable/editable?
- Default — set to the common case?
- Feedback — does the user know it worked?
- Constraint — is the wrong action prevented, not just punished?
- Empty/error state — helpful next step, never a blank or raw error?
- Confirmation — destructive actions state what is lost?
Ask before you ship any UI
+----------------------------------------------+ | 1. What JOB is the user doing here? | | 2. Where would a beginner LOOK for this? | | 3. Is the most common action the EASIEST? | | 4. Loading / empty / error -- all handled? | | 5. Would a non-technical owner get every | | label without asking? | | 6. After they act, do they KNOW it worked? | | 7. Did I test at 375px (phone)? | | 8. Am I tricking or pressuring anyone? | +----------------------------------------------+
Key idea: If a user couldn't find it, the placement is wrong. If they couldn't read it, the label is wrong. If they didn't know it worked, the feedback is missing. Obvious is not luck — it's this checklist.