Building the Eye: How to Practise Design

Nineteen articles. You now know more about how interfaces work than most people who make them for a living.

And you can't design yet.

That isn't discouragement, it's the same sentence the How to Learn sphere ends its chunking article with: you've understood the recipe — you're not a chef yet. This last article is about the distance between the two, and how to cross it deliberately instead of hoping it happens.

The gap

Ira Glass described the thing nobody warns you about, and it explains most people who quit.

You get into this work because you have taste — you can tell good from bad, and that's why the field appealed to you. Then you start making things, and for a long stretch your taste is far ahead of your ability. You can see precisely how bad your own work is. That's an unpleasant place to be, and it's where most people conclude they lack talent.

But the diagnosis is exactly backwards. Being able to see that your work is bad is the qualification. The people who don't see it don't improve, because they have nothing to steer by.

Your taste running ahead of your hands isn't a sign of no talent. It's the steering.

The only known way through is volume of finished work with feedback attached. Not more reading. Not a better tool.

What your chunks are

The How to Learn sphere describes skill as a library of fused blocks — a chef thinks "the sauté," not twelve steps. Design has exactly the same structure, and it's worth knowing what the blocks are so you can build them on purpose:

A form. An empty state. A confirmation flow. An onboarding. A settings page. A data table. A search-and-filter interface. A pricing page. A multi-step wizard. An error recovery path. A dashboard. A mobile navigation.

That's a dozen chunks. An experienced designer meeting "we need a settings page" doesn't start from zero — they recall the structure, the usual traps, the three decisions that matter, and spend their attention on what's specific to this product.

You build these the same way chunks are always built: by making each one several times, in different contexts, with the result checked. Not by reading about them.

Copy, close, rebuild

The oldest technique in every craft, and it works here provided you do the second half.

Redraw an interface you admire, precisely. Every spacing, every size, every state. It'll take a couple of hours and you'll notice fifty decisions you'd never have seen as a user — why that gap is 24 and not 16, why the secondary button is a text link, why the label sits where it does.

Then close it and rebuild from memory. This is the part everyone skips, and it's the only part where the skill forms. Struggling to remember whether the heading was above or beside is exactly the effort that builds the block.

And interrogate the links, not the steps. For each decision ask why this and why here — because the steps won't transfer to your next project, and the reasoning will. That's the same warning the chunking article gives about worked examples: watching what is done, and missing why.

The weekly teardown

A repeatable half-hour that compounds faster than any course:

Pick one real flow in a product you use — signing up, cancelling, changing a payment method, inviting a colleague.
Walk it and record friction. Every hesitation, every re-read, every moment you weren't sure what happened. Screenshot as you go.
Name the decisions. For three screens, say what was decided and what the alternative was.
Find one thing that's genuinely well done. Harder than finding faults, and better training — criticism is easy and teaches less than recognising a good solution and understanding why it's good.
Propose one change with a rationale. One. Written as: problem, change, why it's better, how you'd check.

Do this weekly for six months and you'll have analysed twenty-five real products and made twenty-five arguments. That's a portfolio's worth of thinking as a side effect.

Mix your practice

The How to Learn sphere's key ring article applies here with no modification. Ten landing pages in a row train "apply the landing page method" and never train choosing one. Real work hands you an unlabelled problem.

So interleave deliberately: a form this week, a data table next, then a mobile flow, then a settings page, then an onboarding. And each time, before you start, name the problem yourself instead of inheriting it from a tutorial's heading — because in the field nobody tells you which method the situation needs.

Practise at the edge, too. Deliberate practice means a narrow goal per session and work on what you can't do yet: "today I'm working out how to structure a filter panel with twelve filters," not "I'll design a bit."

Where feedback comes from

Practice without feedback just makes your habits more permanent. Three sources, in ascending order of value:

Your own reference comparison. Put your version beside a strong example and list the differences. Cheap, immediate, and better than nothing — but limited to what you can already see.

Critique from another person. Use the structure from the critique article: give them the problem, the constraints and what you need feedback on. One person, twenty minutes, weekly.

A real user attempting a real task. The most brutal and by far the most valuable. Five people, three tasks, and you keep quiet. Nothing else corrects a wrong model as fast.

Notice that all three require finished work. This is the practical reason to finish things: an unfinished design can't be tested, critiqued or compared, so it teaches you nothing.

A portfolio is evidence of thinking

The most common portfolio mistake is showing screens. Anyone can produce screens; the thing being hired is judgement.

A case study that works has five parts:

The problem — with evidence. Who, what situation, what was going wrong, how you knew.
What you did — the research, what you tried, what you discarded.
The decisions and their reasons — three or four real ones, including the trade-offs and the constraints you worked inside.
What happened — testing results, metrics, or honestly: "not shipped, here's what I'd check."
What didn't work — the version you got wrong and what changed your mind. This section persuades more than the rest combined, because it's the only one that can't be faked.

Three deep cases beat twelve shallow ones. And an unsolicited redesign of a famous app is the weakest possible piece unless you did research first and stated the constraints you assumed — otherwise it's a demonstration that you'll redesign things without knowing why they are the way they are, which is the opposite of the hire.

Where to get real projects

The answer isn't "wait for a job."

Fix something real and small. A local business with a broken booking form, a nonprofit's donation flow, an open-source tool with a confusing settings screen. Real constraints, real users, and a real person who'll tell you if it worked.

Rebuild a flow you personally use — but test it with five people afterwards. That last step turns an exercise into evidence.

Design for your own product, if you're building one. You'll have the constraints problem solved and the "you are not the user" problem at its worst; run the tests.

Volunteer for the ugly work at your job — the admin panel, the error states, the settings. Nobody wants it, it's full of real problems, and it's where you'll learn fastest.

The whole sphere as one checklist

Twenty articles, in the order you'd actually use them:

State the problem — who, in what situation, what's blocking them, how you'll know it's fixed.
Check you're not designing for yourself — write your assumptions down.
Talk to five people about the last time it happened. Past, specific, their words.
Watch someone do it. Look for workarounds and hesitations.
Look at the numbers to find where, then go back to people to learn why.
Synthesise — group raw notes, name each group with a sentence, keep the insight that could have come out otherwise.
Prioritise by frequency, impact, persistence. Take one.
Structure it — grouping and labels in the user's words; card sort, tree test.
Draw the flow — entry points, interruptions, the return, the exit.
Design all five states of every screen, not just the ideal one.
Lay it out from a system — spacing scale, type scale, three levels of hierarchy, one primary per screen.
Use standard controls, and be inventive only where your product is genuinely different.
Write the words properly — outcomes on buttons, errors with three parts, tone matched to the stakes.
Check accessibility — keyboard, contrast, semantics, targets, reduced motion.
Prototype the risky assumption at the lowest fidelity that answers the question.
Test with five people, silently, on real tasks. Fix two things. Test again.
Get it critiqued — framed, with the decider named, and log the decisions.
Build with the engineers, not after them. Review what shipped.
Measure what you said you'd measure, and go find out why.
Write down what you learned — because the next project starts here.

Nobody runs all twenty every time. But when a screen is wrong and you can't say why, the fault is almost always at a numbered step that got skipped, and the list will find it faster than staring at the screen will.

Check yourself

Close the article and answer in your own words:

What is the gap Ira Glass describes, and why is seeing your own work's flaws a good sign?
Name five design chunks you could build deliberately.
What's the half of the copy technique that everyone skips, and why does it matter?
Describe the weekly teardown routine in five steps.
Why is interleaving your practice more useful than repeating one type of screen?
What are the five parts of a case study, and which one persuades most?
Why does practising require finishing things?

In short

Reading this path isn't the skill. The gap between taste and ability is normal, and seeing your own work's flaws is the qualification, not the disqualification.
Design chunks are recurring structures — forms, empty states, onboardings, tables, settings. Build them by making each several times in varied contexts.
Copy an interface precisely, then close it and rebuild from memory, interrogating why each decision was made rather than what was done.
The weekly teardown: walk a real flow, record friction, name the decisions, find one thing done well, propose one change with a rationale.
Interleave problem types and practise at the edge with a narrow goal, because real work never labels which method it needs.
Feedback comes from reference comparison, critique and real users — all three require finished work.
A portfolio shows judgement, not screens: problem, process, decisions with reasons, results, and what you got wrong.
Get real constraints from small real projects, and use the twenty-step checklist when a screen is wrong and you can't say why.