Design you can defend.

Developers often treat design as a taste layer applied at the end — which is why 'make it look nicer' feels unanswerable. Design is a set of decisions about attention, priority, and clarity, and those have defensible right answers.

• What a design is actually optimizing for — task completion, not admiration
• Visual hierarchy: deciding what a user should see first, second, third
• Why 'clean' usually means 'nothing competing for attention', not 'empty'

Every screen answers three questions, in this order:

  1. What is this?          // orientation — where am I?
  2. What can I do here?    // the primary action, unmistakable
  3. What else exists?      // secondary options, quieter

<KW>A screen with three equally-loud buttons has answered #2 with
"you decide" — which is the designer declining to design.</KW>

THE SQUINT TEST
  Blur your eyes at the screen. Whatever still stands out
  IS your hierarchy — whether you intended it or not.

Tool confusion wastes weeks. Knowing what each tool is actually for — and which one is worth learning deeply in 2026 — saves you from investing in the wrong software or from polishing pixels before the layout is even decided.

• Figma: the current industry default, and the four features that actually matter
• Adobe XD's status, and why it's no longer the tool to learn first
• Low-fidelity sketching (paper, Excalidraw) as a separate, faster thinking mode

FIGMA — learn this one properly
  Free tier is genuinely enough to be hired on. Browser-based,
  so nothing to install. The four things worth real practice:
    Auto Layout  — flex/gap, but visual. Makes designs responsive.
    Components   — one source of truth, reused everywhere.
    Variants     — all six states of a button in ONE component.
    Dev Mode     — how developers read spacing/tokens from your file.

ADOBE XD — know what it is, don't start here
  Adobe moved XD into maintenance mode and stopped selling it
  standalone. It still opens old files, but new features stopped.
  Learn it only if a specific employer already runs on it.

PENPOT — the open-source alternative
  Free, self-hostable, Figma-like. Worth knowing it exists.

SKETCHING (paper / Excalidraw) — where you should START
  Deliberately ugly = fast. You throw away 5 layouts in 10 minutes
  because none of them cost anything to make.

<KW>The trap: polished tools invite polishing. Choosing a border
radius before the layout is settled is procrastination that
looks like progress.</KW>

Most 'it looks off but I don't know why' interfaces are alignment and proximity problems. These are learnable rules, not intuition — which is exactly why developers can pick them up quickly.

• Proximity and grouping — spacing communicates relationship before text does
• Alignment, and why inconsistent edges read as sloppy even unconsciously
• Size, weight, and position as hierarchy tools instead of color alone

Spacing tells the user what belongs together,
before they read a single word.

AMBIGUOUS — is the label attached above or below?
  label     margin-bottom: 16px
  input     margin-bottom: 16px

CLEAR — tight inside a group, loose between groups
  label     margin-bottom: 6px    // bound to its own input
  input     margin-bottom: 28px   // separated from next field

<KW>THE RULE
Space WITHIN a group must be smaller than space BETWEEN groups.</KW>

Type is most of what's on screen in almost every app, and it's the fastest lever for making an interface feel considered — but 'pick a nice font' is the least useful part of it.

• Type scale — a fixed set of sizes instead of arbitrary values
• Line height and measure (line length), and why both affect readability
• Weight and case as hierarchy tools, and when uppercase actively hurts

A TYPE SCALE — pick from these, never invent one mid-project
  --text-xs:   12px   // captions, metadata
  --text-sm:   14px   // secondary text
  --text-base: 16px   // body — never smaller for real reading
  --text-lg:   20px
  --text-xl:   28px
  --text-2xl:  40px   // page titles

LINE HEIGHT — tighter for headings, looser for body
  heading  line-height: 1.15   // large text needs less room
  body     line-height: 1.6    // small text needs more

MEASURE — cap body text around 65 characters
  max-width: 65ch;

Color is where most developer-built UIs fail accessibility, and it fails silently — nothing errors, it just becomes unusable for a meaningful slice of your users.

• WCAG contrast ratios, and computing them instead of eyeballing
• Semantic color (success/warning/danger) kept separate from brand color
• Why color must never be the only carrier of meaning

WCAG AA MINIMUMS — the numbers that matter
  Body text (< 18px)                4.5 : 1
  Large text (>= 24px, or 18px bold)  3 : 1
  UI components & borders             3 : 1

Color alone fails ~1 in 12 men (color vision deficiency).

BAD — only red distinguishes this from a normal message
  <span style="color: red">Payment failed</span>

GOOD — color + icon + explicit words: three channels
  <span role="alert">⚠ Error: Payment failed — card declined</span>

This is the stage that makes a developer-built UI stop looking developer-built. Consistency is more visible than any individual choice — and it's purely mechanical to achieve.

• A spacing scale (4/8pt) instead of arbitrary pixel values
• Design tokens as the shared vocabulary between design and code
• Why consistency beats perfection on any single value

A SPACING SCALE — every gap comes from this list
  --space-1:   4px
  --space-2:   8px
  --space-3:  12px
  --space-4:  16px
  --space-6:  24px
  --space-8:  32px
  --space-12: 48px

BAD — three "roughly medium" gaps, none intentional
  padding: 13px;  margin: 18px;  gap: 22px;

GOOD — from the scale, consistent with everything else
  padding: var(--space-3);  margin: var(--space-4);  gap: var(--space-6);

In Figma this is exactly what Auto Layout gap values should be.

Designing only the default state is the single most common reason a built UI feels broken. Real components live mostly in their non-default states.

• The full state set: default, hover, focus, active, disabled, loading, error
• Empty states as a design opportunity, not an oversight
• Skeletons vs. spinners, and what each communicates

A BUTTON HAS AT LEAST SIX STATES
Designing one is designing 1/6 of a button.

  default            // resting
  :hover             // affordance — "this is clickable"
  :focus-visible     // keyboard position — NEVER remove
  :active            // press feedback
  :disabled          // unavailable, and ideally why
  [data-loading]     // in progress — prevents double-submit

<KW>In Figma: this is exactly what Variants are for — one component,
a State property, six values.</KW>

EMPTY STATE — a user's first impression of a feature
  "No projects yet" + a button
  beats a blank rectangle, every time.

Accessibility gets framed as a compliance chore, which is why it gets skipped. It's really about whether your interface works for people using it differently than you do — and most fixes are small.

• Keyboard navigation, focus order, and visible focus indicators
• Semantic HTML — why the right element beats ARIA in almost every case
• Labels, alt text, and testing with an actual screen reader

THE WORST LINE OF CSS IN COMMON USE
  *:focus { outline: none; }
  // keyboard users are now lost on your page

DO THIS INSTEAD — style it, don't delete it
  :focus-visible {
    outline: 2px solid var(--accent);
    outline-offset: 2px;
  }

A div with a click handler is invisible to keyboards
and screen readers:
  <div onClick={save}>Save</div>       // unreachable
  <button onClick={save}>Save</button> // focusable + announced, free

You cannot see your own interface with fresh eyes — you know where everything is. Five real users will find problems no amount of internal review surfaces.

• Running a simple usability test — tasks, not opinions
• Why watching silently beats asking 'do you like it?'
• Why ~5 users surfaces most usability problems

BAD PROMPT — invites politeness, produces flattery
  "Do you like this design?"

GOOD PROMPT — a task, then silence
  "Sign up and create your first project."
  Then say nothing. Every hesitation is data.

RECORD FOR EACH USER
  - Where did they pause?
  - What did they click that wasn't it?
  - What did they say out loud while confused?

<KW>5 of 5 users hitting the same wall is not a small sample.
It's a wall.</KW>

The gap between a design and the built version is where most quality quietly leaks out. Closing it is a process problem with a concrete solution, not a talent problem.

• Reading a design spec: spacing, sizes, states, and behavior
• Translating designs into tokens and reusable components
• Design systems — and when building one is premature

A design hands over values.
Tokens make them enforceable in code.

  :root {
    --space-4: 16px;
    --radius-md: 10px;
    --text-base: 16px;
    --color-accent: #FF7500;
  }

Build the component once, with every state, then reuse it:
  <Button variant="primary" loading={saving}>Save</Button>

<KW>A design system is worth it when you're reusing components,
not before. Two screens don't need one; twenty do.</KW>

Knowing the rules doesn't make you hireable — being able to show judgment does. This is the honest map from 'I can use Figma' to work people pay for, including what actually separates each level.

• The four levels, and what genuinely distinguishes each one
• Case studies over screenshots — the portfolio format that gets replies
• Getting real work with no experience, and what to charge first

THE FOUR LEVELS

  1. CAN USE THE TOOL
     Knows Figma. Copies layouts that look nice.
     Not yet hireable as a designer.

  2. CAN MAKE IT LOOK GOOD
     Consistent spacing, type scale, decent taste.
     Hireable as a junior. Ceiling: needs direction.

  3. CAN DEFEND EVERY DECISION
     "This is primary because it's the one action
      90% of users came for. I tested the other way
      and completion dropped."
     This is the jump that pays. Most never make it.

  4. CAN SET DIRECTION
     Decides what NOT to build. Runs the system.
     Makes other designers better.

PORTFOLIO: case studies, not galleries
  ✗ 12 pretty screenshots
  ✓ 3 case studies, each:
      - the problem, and who had it
      - what you tried and REJECTED (and why)
      - what changed after testing
      - the outcome, measured if possible

<KW>Two rejected approaches say more about your judgment
than ten polished screens.</KW>

GETTING THE FIRST REAL WORK
  - Redesign something real and badly designed, publish
    the case study (a govt form, a local business site)
  - Offer one free/cheap project for a real person with
    a real deadline — constraints teach what practice can't
  - Contribute to open-source design systems
  - Start freelance small; raise rates every 2 projects