Progress
0%
◆ Design for engineers

From JS developer to UX-fluent product engineer

You already have the hardest skill: you can ship. The gap to "good at design" isn't talent — it's a vocabulary, a set of heuristics you can apply in code, and reps on real interfaces. Click the checkboxes as you go; your progress is tracked live.

5Core disciplines
12 wksGuided plan
8Design heuristics
∞Reps on real UI

01 Foundations you must internalise

These are the four primitives everything else is built on. Learn them as constraints — like knowing how the event loop works, but for perception.

Visual hierarchy

Every screen must answer "where do I look first, second, third?" Hierarchy comes from size, weight, colour, contrast, and space — not from making everything bold.

Spacing & rhythm

Whitespace is not empty — it's grouping. Use a consistent scale (4/8/12/16/24/32/48) instead of arbitrary pixel values. Related things sit close; unrelated things get air.

Typography

Type does 80% of the work on most product UIs. Cap yourself at 2 families and a small modular scale (1.25 or 1.333). Watch measure: 45–75 characters per line.

Colour & contrast

Colour is a system, not a preference: a neutral ramp, one brand hue, and semantic tokens (success/warn/danger). Contrast minimum is WCAG AA 4.5:1 for body text.

Nielsen's heuristics — the usability checklist

1. Visibility of system status. Spinners, skeletons, "Saved ✓" — the system always tells you what's happening. (Loading states are your job, not the designer's.)
2. Match the real world. Users' language beats internal jargon. "Invoices", not "billing_entities".
3. User control & freedom. Undo, cancel, back. Never trap someone in a flow or modal.
4. Consistency & standards. Same word, same behaviour, same place. Don't reinvent the dropdown.
5. Error prevention. Disable invalid actions, confirm destructive ones, defaults that can't hurt.
6. Recognition over recall. Show options; don't make people remember. Autocomplete > freeform codes.
7. Flexibility & efficiency. Keyboard shortcuts, bulk actions, saved views for power users.
8. Aesthetic & minimalist design. Every element earns its place. Remove, then remove again.
9. Help users recover from errors. Plain-language messages that say what broke and how to fix it.
10. Help & documentation. Contextual help at the point of confusion, not a 40-page manual.

02 Interaction design — the part you actually build

This is where a JS dev has an unfair advantage: you can reason in states.

Every component has ≥7 states

Design and build all of them, not just the one in the mockup.

defaulthoverfocus-visible activedisabledloading errorempty

Feedback latency & perceived speed

Users forgive slowness that is acknowledged. The classic thresholds to design against:

// design targets, not code < 100ms → feels instant (pure client action) < 1s → flow intact, show nothing or inline > 1s → show spinner / optimistic UI > 10s → show progress + allow backgrounding

State-machine thinking

A form is a state machine. So is onboarding, checkout, a drag-and-drop. Name the states explicitly instead of juggling five booleans.

// not this let isLoading, isError, isEmpty, isSaving; // this let status = 'idle' | 'validating' | 'saving' | 'saved' | 'error';

Design tokens → CSS variables

Bridge design and code with a single source of truth. Tokens let designers and devs speak the same language.

Anti-pattern → better pattern

✗ Avoid

  • Hiding errors until submit, then dumping a summary
  • Disabling the submit button with no reason given
  • Confirm-everything modals ("Are you sure?" on a toggle)
  • Full-page spinners that wipe context
  • Free-text fields where a picker exists
  • Placeholder used as the label
  • Toast-only feedback for critical errors

✓ Prefer

  • Inline validation on blur, re-validate on input
  • Keep it enabled; if clicked, say exactly what's missing
  • Undo patterns; confirm only destructive & irreversible
  • Local skeletons that preserve layout & context
  • Typeahead / pickers that prevent typos at the source
  • Persistent visible label + hint text
  • Durable, in-place messaging next to the cause

03 Live demo: feel the difference

Both fields do the same thing. Only one respects the human. Type an invalid email into each and watch what happens.

✗ Errors only on submit

✓ Validate on blur, explain inline

Live demo · focus states are not optional

Tab through the buttons below. The "before" version had its outline removed — see how easy it is to get lost? Click the buttons to compare :focus-visible handling.

Press Tab and watch where focus goes.

04 Build a system, not one-off screens

Design maturity = you stop styling screens and start composing primitives. This is also where your engineering brain pays off.

Component inventory

Catalog what actually exists before inventing a new thing. Most "new" UI is a variant of something you already have.

ButtonInputSelect ModalTooltipTabs TableToastMenu

Accessibility as engineering

a11y is not a phase — it's correctness. And it's mostly mechanical in JS frameworks.

Design craft tools

You don't need to become a Figma wizard, but you should be dangerous in it — to inspect, prototype, and communicate.

Figma autolayoutVariables/tokens Prototype flowDev mode inspect

Motion & micro-interactions

Motion explains change: where something came from, what it's related to, whether it worked. Keep it fast (150–250ms) and respect prefers-reduced-motion.

05 Process: how UX people actually work

Adopting the process is what turns "makes things pretty" into "solves the right problem".

1 · Understand

Talk to 5 users before designing. Watch them use the current thing. Write down the jobs-to-be-done in their words.

2 · Diverge

Sketch 5–10 rough options fast (paper, Excalidraw). Quantity first. Bad ideas unlock good ones.

3 · Decide

Converge against criteria: user value, effort, risk. Document the trade-off, not just the outcome.

4 · Prototype

Cheapest thing that tests the riskiest assumption. HTML/CSS prototype > hi-fi mock when uncertain.

5 · Test

5 users, tasks, no leading questions. Watch where they hesitate. You're testing the design, not them.

6 · Ship & measure

Instrument the flow. Task success rate, time-on-task, error rate, drop-off. Close the loop with data.

06 Your 12-week plan

Deliberate practice beats reading. One hour a day, each week with a concrete output you can show.

Weeks 1–2 · See

Copy 10 great UIs by rebuilding them in HTML/CSS from screenshot. No shortcuts, no Tailwind first pass.

Output: a "copies" folder of 10 pixel-attempts

Weeks 3–4 · Primitives

Build a personal design system: tokens, then Button/Input/Card across all 7 states.

Output: token file + 3 polished components

Weeks 5–6 · Patterns

Build a real form flow and a data table with empty/loading/error states. Keyboard-first.

Output: one accessible, stateful flow

Weeks 7–8 · Research

Read Refactoring UI + Don't Make Me Think. Run 5 user tests on your own project.

Output: a test report with 5 findings you acted on

Weeks 9–10 · Systems

Refactor an existing project of yours to use tokens + primitives. Delete 70% of ad-hoc CSS.

Output: before/after diff

Weeks 11–12 · Ship & measure

Pick one flow, add analytics, iterate once based on data. Write up what you learned.

Output: a case-study write-up

07 Learning resources that are worth your time

Curated, not exhaustive. Start with the two books in bold.

📕 Refactoring UI

Adam Wathan & Steve Schoger. The single most actionable book for devs who want to design. Written for engineers.

📗 Don't Make Me Think

Steve Krug. Usability fundamentals in an afternoon. The classic baseline.

📘 The Design of Everyday Things

Don Norman. Affordances, signifiers, mapping. The vocabulary behind everything.

📙 Laws of UX

Jon Yablonski. Fitts, Hick, Jakob, Miller — heuristics with real examples.

🌐 Refactoring UI video course

If you learn by watching someone iterate, this is it.

🛠 Practice sources

Frontend Mentor, UI Challenges, Mobbin for pattern research, Dribbble for taste (not for structure).

08 Questions you'll hit along the way

Do I need to learn Figma properly?
Enough to inspect and communicate. Fluency in Figma is a nice-to-have; fluency in state thinking and heuristics is the actual skill. Many excellent product engineers live in code and use Figma only for handoff inspection.
How do I build taste, not just knowledge?
Taste is compressed repetition. Copy good work deliberately (the "10 copies" exercise), then analyse why it works, then apply the principle to something original. Volume + reflection. There is no shortcut and no replacement.
Where does JS framework come in?
Everywhere, but later. React/Vue/Svelte just render your states. Your leverage comes from modelling those states well. A well-modelled state machine renders identically in any framework.
What's the single highest-ROI habit?
Designing all the non-happy states. An interface that handles empty, loading, error, and success gracefully feels dramatically more polished than one that only handles success — and it's a purely engineering discipline, so it's yours to own.
How do I give and take design feedback?
Talk about the user and the goal, never "I like/dislike". "What's the user trying to do here?" and "What happens if they do X?" are the two questions that defuse almost every design disagreement.