How to Learn Design Without a Degree: A Build-First Curriculum

Last updated: August 2026

Most design curricula are reading lists. You work through them, you feel like you're learning, and at the end you cannot design anything — because reading about typography and setting type are unrelated skills.

This one is organised around five things you build. Each stage has one output you have to finish and a checkpoint that tells you whether you're actually ready to move on, or just tired of the stage. The resources exist to unblock the build, not to be completed.

There's an obvious irony in a directory telling you to spend less time browsing resources. We catalogue 1,900 of them. Most of the reason people don't learn design is that they consume the catalogue instead of using it.

How to use this

Do the output before you finish the resources. Start building at 30% understanding. The gaps you hit will tell you which resource to open next, and you'll retain it because you needed it.

Don't skip the checkpoints. They exist because self-taught designers consistently over-rate stages they enjoyed and under-rate ones they found dull. The gate is the point.

One stage at a time. Studying research while still learning to lay out a screen produces a person who can critique work they cannot make.

Stage	You build	Realistic time
1. Craft	10 redrawn interfaces	6–10 weeks
2. Flow	One multi-screen product flow	6–8 weeks
3. Evidence	Five user interviews + a revision	4–6 weeks
4. System	A small design system	6–8 weeks
5. Case	One real case study	4–6 weeks

Nine to fourteen months part-time. Anyone promising twelve weeks is selling a bootcamp.

---

Stage 1 — Craft

What you must be able to do: make a screen that looks deliberate rather than accidental, and explain every spacing and type decision on it.

This stage is about the eye. Not ideas, not users — whether you can tell that something is 4px off, and whether you can fix it.

Work through these, in this order:

Kern Type teaches spacing by making you do it and scoring you against a typographer. Half an hour here beats any article about kerning.

The Bézier Game does the same for the pen tool. Stop when you can complete levels with the minimum node count.

Gestalt Principles explains through interactive animation why things group the way they do. This is the actual mechanism behind "it just looks right."

Typescale and

Typogui.de for building a type scale and getting the daily details correct — dashes, quotes, spacing.

Realtime Colors for testing palettes on a real layout instead of swatches.

Figma Design for Beginners if you need the tool itself. Learn auto-layout properly now; almost every later frustration traces back to skipping it.

Your output: redraw ten existing interfaces from screenshots — apps you use daily. Not "inspired by." Match them exactly, including spacing and type. You'll discover the details you'd never have noticed.

Checkpoint: open one of your redraws next to the original at 100%. Can you list ten specific differences? If everything looks the same to you, your eye isn't calibrated yet — do five more.

---

Stage 2 — Flow

What you must be able to do: design a sequence of screens that someone can complete without you standing behind them.

Individual screens are a craft problem. Flows are a thinking problem — states, errors, empty views, what happens when someone taps back.

Laws of UX covers the psychological principles behind interface decisions. Read it once now, and return to it when a specific decision is contested.

Patttterns holds 400+ real design patterns. When you don't know how to handle something, someone has solved it — start from the convention and deviate deliberately.

Refero and

Mobbin are where you go to see how shipped products handle the exact flow you're stuck on. Refero's search is the stronger of the two for finding a specific pattern.

Checklist Design lists what every component and page actually needs. Use it as a completeness check before you call a screen finished.

Invisible Details and

Motion Design Principles cover the transitions and micro-decisions that separate competent from considered.

Your output: one complete flow — onboarding, checkout, or booking. Every state: loading, empty, error, success, offline, and the longest realistic content. Prototype it in Figma so it's clickable.

Checkpoint: hand it to someone who has never seen it and say nothing. If you have to explain a single step, the flow is wrong, not the person. Fix it and repeat.

---

Stage 3 — Evidence

What you must be able to do: find out you were wrong, on purpose, before you ship.

This is the stage self-taught designers skip most often, and the one that separates people who get hired from people with attractive portfolios.

UX Research Field Guide is the most complete free introduction — plans, recruiting, methods, analysis. Treat it as the textbook for this stage.

Guide to UXR covers the practical parts, including what goes wrong in real sessions.

Design Kit from IDEO gives you concrete methods with steps, which is what you need when you've read about research but never run any.

Built for Mars publishes teardowns of real products' UX. Studying how someone else diagnoses a product teaches diagnosis faster than theory.

People Nerds and

MeasuringU for how research is practised in teams, and for the quantitative side when you need to defend a finding with numbers.

Lyssna for cheap unmoderated tests once you know what to ask.

Your output: five moderated interviews with real people using the flow you built in stage 2. Record them. Then revise the flow based on what you saw, and write down what you changed and why.

Checkpoint: did you change something you were confident about? If your research confirmed everything, you either asked leading questions or watched for agreement instead of confusion. Run two more.

---

Stage 4 — System

What you must be able to do: make fifty screens that look like one product, and hand them to a developer without a translation meeting.

Design System University is the most structured curriculum here — tokens, governance, component APIs, the organisational side.

The Design System Guide and

Hey Design Systems are the shorter routes in if you want orientation before committing.

Material Design is worth studying as documentation even if you never build on it — it's a public example of a system documented thoroughly.

Component Gallery shows how shipping teams document components, and

Storybook is where component truth lives once code exists.

shadcn/ui is worth understanding because a large share of React products are built on it — knowing what your developer already has prevents you specifying things that exist.

Accessibility belongs here, not as an afterthought:

Access Guide for a friendly introduction,

A11Y Project for depth,

Microsoft Inclusive Design for the method that reframes it around situational constraints, and

Stark to check contrast and focus order while you design.

Your output: a small design system for your stage-2 product — colour and type tokens, spacing scale, six to eight components with every state, and written rules. Not a page of swatches. Rules like "cards use 16px padding and 8px radius, always."

Checkpoint: design a screen you haven't designed before using only your system, changing nothing. If you have to invent a new component or break a rule, the system is incomplete. Fix it and try again.

---

Stage 5 — Case

What you must be able to do: explain a decision to someone who was not there and does not care about your process.

Portfolios do not fail because the work is ugly. They fail because they show final screens and nothing about the reasoning.

Case Study Club publishes case studies weekly. Read ten before writing yours — you'll see the shape.

Bestfolios curates portfolios that got people hired, which is a different set from portfolios that get likes.

Product Design Interview covers the career mechanics — interviews, promotion, positioning — which nobody teaches and everybody needs.

Semplice if you want a portfolio you own permanently. See our portfolio builders guide for the alternatives.

Need a brief?

Briefbox,

FakeClients and

Good Briefs generate practice work. Use these only if you have no real project — invented briefs are visibly weaker than real constraints.

Your output: one case study covering the problem, the constraints, what you tried, what you rejected and why, what shipped, and what happened. The rejected options section is what hiring managers actually read.

Checkpoint: give it to someone outside design. Can they explain what problem you solved and why your solution addresses it? If not, you've written a process diary, not a case study.

---

What to skip

Dribbble shots as a learning method. They optimise for a beautiful crop, not a working product. Fine for visual reference in stage 1; misleading after that. See Dribbble alternatives.

Tool tutorials before fundamentals. Learning every Figma feature before you can space text produces someone fast at making bad screens.

Certification mills. No employer has ever cared about a UX certificate. They care about the case study from stage 5.

Trend content. Neumorphism, glassmorphism, whatever is next. Trends are a stage-1 concern at most.

Reading about design instead of doing it. Including, at some point, this page.

When you're actually ready

You're ready to apply when you have two case studies — one from a real project or freelance client, one self-directed — that each show a problem, your reasoning, and an outcome. Not five projects. Two, with depth.

If you want ongoing input rather than a curriculum,

Design Better,

High Resolution and

Spec are worth following, and

Untools covers the thinking frameworks that transfer beyond design entirely.

Browse everything we catalogue in design courses and UX research — around 120 reviewed learning resources in total.