The Solo Practice. How one person designs, practises and ships.

Warm-up: where are you now?

Every other guide in this course is about the product. This one is about you, the person making it. That makes it the guide most people skim, and the one that decides whether the rest of the course sticks. Knowledge you do not practise fades in weeks. A routine you keep for six months turns into skill.

Study it in five sittings, one per Part plus the wrap-up. Do the exercises on your own product; if you do not have one yet, use the capstone in chapter 17 as your product from day one. Three questions first, to see what you already believe about practice.

The whole design process for one person is a loop of twelve small steps in four phases (understand, shape, make, learn), and the skill is choosing how much of each step a change deserves.

Textbook design processes are drawn for teams of ten: a researcher hands insights to a designer, who hands mockups to engineers, who hand a build to QA. Each hand-off needs a document, so the process fills with documents. When you are alone, there are no hand-offs between people. There is only one hand-off left, and it is the dangerous one: from you-today to you-in-three-weeks, who has forgotten the reasoning.

So the solo loop keeps every thinking step and cuts most communication artifacts. You still frame the problem before solving it, still look at more than one solution, still test with real people. You just do each step in the smallest form that does its job: a paragraph instead of a deck, a sketch instead of a mockup, a coded prototype instead of a clickable one.

What each step is for, in one line

1. Idea journal. Capture every problem you notice (yours and users') with the date and the situation. Ideas are cheap; the journal is how you notice which ones keep coming back.
2. Problem brief. One page: who has the problem, when, what they do today, what "solved" looks like, what you will not do. Forces you to separate the problem from your favourite solution. (Deep dive in Problems Worth Solving.)
3. Research. Talk to three to five people, read support emails, watch someone do the task today, study how three other products solve it. Hours, not weeks.
4. Sketches. Many rough options, fast. Their job is to make you compare, so you never ship your first idea by default.
5. Flows. The sequence of places and actions, drawn as a breadboard or a simple flow diagram, before any screen is drawn properly.
6. Wireframes. Layout and hierarchy in grey boxes, only for screens whose structure is genuinely uncertain.
7. Visual. Type, colour, spacing, icons, applied through your tokens and components (see Systems & Platforms).
8. Prototype. Something that moves, so you can feel timing, gestures and transitions that static pictures hide.
9. Build. The real thing. For you, often the prototype grows into it.
10. Test. Watch real people use it, before and after shipping (see Testing & Iteration).
11. Ship. Release it with a changelog entry that says what changed and why.
12. Learn. Compare what happened with what you expected in the brief. Write the gap down. It becomes the next entry in the journal.

Process proportional to risk

Not every change runs every step at full size. A typo fix runs the loop in five minutes: notice, fix, ship. A new product runs it over months. The question to ask is: how expensive is it to be wrong here? If a mistake is cheap to undo (a label, a colour), skip ahead to build and learn from real use. If it is expensive (data model, navigation structure, pricing, anything that changes users' habits), spend more time in understand and shape, where changing your mind costs an eraser.

Kent Beck's old programming advice, "make it work, make it right, make it fast", has a design equivalent: make it right (the problem), then make it work (the flow), then make it good (the craft). Solo makers usually invert it. They start with the craft they enjoy (a beautiful header, a custom font) on a flow that has not been questioned, for a problem nobody confirmed.

In the wild

• Basecamp's Shape UpRyan Singer, 2019
  Work is "shaped" (problem, appetite, rough solution, rabbit holes) before it is handed to a small team for a six-week cycle. Separate shaping from building, even if you do both: decide the boundaries first, then build inside them.
• OvercastMarco Arment, 2014 onward
  A podcast app designed, built and supported by one person for over a decade, with features such as Smart Speed and Voice Boost that came from the maker's own listening problems. The idea journal can start with your own daily friction, as long as you then check others share it.
• ReederSilvio Rizzi, 2010 onward
  A one-person reader app that has been redesigned several times, including a rethought new Reeder released in 2024 alongside the older app renamed Reeder Classic. The loop does not end at version 1; "learn" can lead to rethinking the whole product.

Keep five small living documents (a one-page brief per project, a decision log, a design principles page, a screen inventory and a public changelog) and nothing else until you feel a real need.

Documents in a team are messages between people. Your documents are messages between versions of you. That changes the test for whether a document is worth keeping: will I read this again, and will it change what I do? A persona you wrote once and never opened fails. A decision log you check every time you are tempted to reopen a settled question passes.

The five below each answer a question you will ask yourself repeatedly. They are plain text on purpose. Markdown files in your repo (a /design folder) beat a sprawling workspace in a separate tool, because they live next to the code, are versioned with it, and are searchable from your editor.

1. The one-page brief

One per project or significant feature. Its job is to stop you from solving the wrong problem and to let you measure success later. The "No-gos" line is the most valuable: it is where scope creep is prevented in advance. The "Appetite" line comes from Shape Up: instead of estimating how long something will take, decide how much time it is worth, then design a solution that fits.

# Brief: [feature or product name]          Date: 2026-11-01

Problem       Who struggles, in what situation, doing what?
              (One paragraph. No solution words.)
Evidence      What makes me believe this is real?
              (3 user quotes, support emails, my own diary entries)
Today         What do they do now instead? What does it cost them?
Solved looks  What will be observably different when this works?
like          (A behaviour or number, not "users will love it")
Appetite      How much time is this worth? (e.g. 2 weeks, then stop)
No-gos        What I will deliberately NOT do in this version.
Risks         The 1 to 3 unknowns most likely to sink it.
Check on      Date I will compare results with this page.

2. The decision log

Software architects use Architecture Decision Records, a format Michael Nygard proposed in 2011: short notes recording context, decision and consequences. The design version is even shorter. Its value appears in month four, when you are about to change the reading font back to the one you rejected in month one, and the log tells you why you rejected it. It turns re-litigation into a two-minute read.

3. Design principles

Three to five sentences that describe what your product prefers when two good things conflict. "Simple" is not a principle, because nobody argues for complicated. A real principle has a cost: "Reading beats managing: we would rather lose a power feature than add a screen that pulls you out of the text." You use them as tie-breakers in chapter 14.

# Principles for [product]
1. [X] over [Y]: [one sentence on what we give up and why]
2. ...
(Test each one: would a reasonable competitor choose the opposite?
 If not, it is a platitude, not a principle.)

4. Screen inventory

A list of every screen, sheet, dialog and important state, with its status. Its job is to make the whole product visible at once, so you notice the empty state nobody designed and the settings screen still using last year's styles. A simple table works; a single canvas of thumbnails works better once you have more than twenty screens.

| Screen         | States designed            | Status  | Last pass |
|----------------|----------------------------|---------|-----------|
| Library        | full, empty, loading, error| shipped | 2026-10   |
| Book detail    | full, no cover, long title | shipped | 2026-09   |
| Add book sheet | search, manual, duplicate  | WIP     |           |
| Settings       | default                    | stale!  | 2025-12   |

5. The changelog

Public, dated, human. Olivier Lacan's "Keep a Changelog" convention groups entries as Added, Changed, Fixed and Removed, newest first. For a product (not a library), write for users: what they can now do, not which files changed. It doubles as your progress record, your marketing and your memory. Linear's public changelog is a well-known example of a changelog that also communicates craft and pace.

## 1.4 · 2026-11-01
Added    Reading streaks you can turn off (Settings › Reading).
Changed  Book covers load 2x faster on slow connections.
Fixed    Long titles no longer overlap the author name.
Removed  The "Popular" tab. Few people used it and it
         pulled attention away from your own library.

In the wild

• Linear changelogLinear, 2019 onward
  A frequent, illustrated public changelog that reads as a record of steady craft. A changelog can be part of the product's personality, not just a list.
• Keep a ChangelogOlivier Lacan, keepachangelog.com
  A short convention: newest first, dated, grouped by type of change, written for humans. Borrow a standard instead of inventing a format.
• Architecture Decision RecordsMichael Nygard, 2011
  Short records of context, decision, status and consequences, kept in the codebase. Decisions age better when their context is written next to them.

A UI sketch is a thinking tool, not a drawing: it needs only eight shapes, it should take under a minute, and its value comes from making many so you can compare them.

Bill Buxton's Sketching User Experiences (2007) draws a sharp line between sketches and prototypes. Sketches are quick, cheap, plentiful, ambiguous and disposable; they suggest and explore. Prototypes are more refined and specific; they describe and test. The mistake solo makers make is skipping straight to the second kind, so the first idea becomes the only idea.

The mechanism is simple. Your first idea is usually the most obvious one, the one every competitor also had. Ideas two to five are where you start recombining. Ideas six to eight are often strange, and strange ideas contain the fresh pieces. But you only reach idea eight if each idea costs less than a minute. That is why sketches must be ugly: a sketch that takes ten minutes to make is a sketch you will defend instead of throw away.

Thumbnails before frames

Start smaller than you think. A thumbnail the size of a postage stamp (about 4 × 7 cm for a phone screen) can only hold the big decisions: what is at the top, what is the main thing, where is the action. That is exactly the level you should be deciding at first. Use a thick pen (a marker or a 0.8 mm felt-tip), never a fine pencil. The thick line physically prevents detail, which keeps you on structure. Ryan Singer's "fat marker sketches" (next chapter) use the same trick.

Crazy 8s and 6-8-5

Crazy 8s, popularised by Jake Knapp's Google Ventures design sprint (described in his book Sprint, 2016), is the most useful timed sketching drill: fold a sheet of A4 into eight panels and sketch eight variations of one idea, one minute each. A close cousin, often called 6-8-5, asks for six to eight ideas in five minutes. The time pressure is the active ingredient. It stops you polishing and forces you past the obvious.

Do them on one specific question, not "the app". Good prompts: "the first screen after install", "how a finished book is celebrated", "how to show reading progress without a number". Use the timer below with a real sheet of paper.

After the eight: pick, then combine

Sketching produces options; choosing is a separate step. Put the sheet on the wall, step away for ten minutes, then put a dot on the two or three panels that answer the question best and circle any single good piece in the others (a placement, a label, an interaction). Your next sketch combines the dotted panels with the circled pieces. That combination is usually better than any of the eight.

In the wild

• Google Ventures design sprintJake Knapp and colleagues, 2010s
  A five-day process where Crazy 8s is the warm-up before a more detailed three-panel solution sketch. Fast divergent sketches feed one slower, considered sketch.
• Sketching User ExperiencesBill Buxton, 2007
  Argues that sketching is the core activity of design, and that a design process with only one idea has no design in it. The number of options you compare is a measure of how much designing you did.
• The Back of the NapkinDan Roam, 2008
  A practical book on solving problems with simple pictures, written for people who say they cannot draw. Drawing skill is irrelevant; visual thinking is the skill.

Before you draw screens, draw the flow as words (places, the things you can do there, and where they lead), then sketch only the layout ideas that matter with a marker too fat for detail.

In Shape Up, Ryan Singer borrows the word "breadboard" from electronics, where engineers wire a circuit on a board to prove it works before designing the case. A design breadboard has three elements, all written as plain text: places (screens, dialogs, menus you can navigate to), affordances (things you can act on there: buttons, fields, links, and also important pieces of copy) and connection lines (arrows showing where an affordance takes you).

Why words? Because a breadboard has no layout, it cannot get stuck on layout. You can see in two minutes that your "add book" flow has five places when it could have two, or that the "duplicate found" case has no exit. These are the expensive mistakes, and visual mockups hide them behind good looks.

Fat marker sketches

When the idea is inherently visual (a calendar, a reading progress graphic, a layout where position matters), breadboards are not enough. Singer's answer is the fat marker sketch: drawn with a pen so broad that adding detail is impossible. It fixes the arrangement of the important elements and leaves everything else open. Its purpose is to set boundaries for the build, not to specify it, so you keep room to discover the details while making.

Appetite and rabbit holes

Shape Up pairs these sketches with two more ideas worth stealing whole. Appetite: decide up front how much time a problem deserves (Shape Up uses small batches of a week or two and big batches of six weeks), and design a solution that fits that budget. This is "fixed time, variable scope", the opposite of estimating. Rabbit holes: before building, list the parts most likely to explode (sync conflicts, an unclear edge case, a technical unknown) and decide in advance how you will avoid them, often by cutting them.

In the wild

• Shape UpRyan Singer, Basecamp, 2019 (free online)
  Introduces breadboarding, fat marker sketches, appetites, rabbit holes, six-week cycles and hill charts. Most of it was written for small teams and adapts naturally to a team of one.
• HEY emailBasecamp, 2020
  Built by Basecamp using the same shaping process, with distinctive flows such as screening first-time senders. A strong flow decision (who reaches your inbox) is visible in a breadboard long before any visual design.

Every prototype exists to answer one question; choose the cheapest fidelity that can answer it, and throw it away (or grow it) once it has.

Stephanie Houde and Charles Hill's 1997 paper "What do Prototypes Prototype?" sorted prototypes by the question they explore: the role a product plays in someone's life, its look and feel, or its implementation (can it be built, will it perform). Different questions need different prototypes. A clickable Figma file is good at "do people find the path?" and useless at "does this scroll feel smooth with 2,000 books?". A paper sketch is good at "is this the right screen?" and useless at "is this type comfortable for an hour?".

Fidelity has several separate dimensions: visual (how real it looks), content (real or fake data), interaction (does it respond) and data (does it handle real volumes and edge cases). You can mix them. A grey wireframe filled with your real library of 300 books is low visual fidelity but high content fidelity, and it will reveal problems that a beautiful mockup with six perfect book covers never will.

Wireframing fast

Wireframes earn their place only when layout is genuinely uncertain: a dense dashboard, a settings screen with 30 options, a first-run screen that must explain a lot. For everything else, go from sketch to code. When you do wireframe, use three greys (text, rule, fill), one real typeface at real sizes, real content, and no colour. Colour invites aesthetic debate before structure is settled. Time-box each screen to 20 minutes.

Prototyping options, by question

In the wild

• Facebook Paper and OrigamiFacebook, 2013 to 2014
  The team behind Paper (with Mike Matas among its designers) prototyped its gesture-driven interface with a Quartz Composer toolkit that Facebook released as Origami, later Origami Studio. When interaction is the product, prototype in a medium that has real physics.
• SwiftUI previewsApple, 2019 onward
  Live previews beside the code, with the #Preview macro since Xcode 15, let one view render in several states and sizes at once. For native makers, the code editor is a capable prototyping tool.

If you can build, the material is the best design tool: design the hard 20% on paper, then shape the rest directly in code, with a playground that shows every state of every component at once and reloads in under a second.

Loren Brichter designed and built Tweetie himself and introduced pull-to-refresh in Tweetie 2 (2009), an interaction that is hard to imagine coming from a static mockup: it is about how a list feels when you pull past its top. Silvio Rizzi has designed and built Reeder alone for over a decade. Both work as designer-engineers. Their advantage is not speed; it is that they can feel the product while shaping it, and adjust the parts mockups cannot show: timing, scrolling, loading, real text, edge cases.

In recent years companies such as Vercel and Linear have hired for this hybrid role and called it "design engineer": someone who designs at the level of the shipped interface, in code, with taste. For a solo maker it is not a job title. It is simply how you work, and the goal is to do it on purpose rather than by accident.

The three tools that make it work

1. Hot reload. Change a value, see it in under a second without losing state. Vite's hot module replacement on the web, SwiftUI previews, Jetpack Compose previews and Flutter hot reload all give you this. If your loop is slower than two seconds, fix that first; design iteration dies above it.
2. A component playground. One page (or preview) that renders every component in every state side by side: default, hover, pressed, focus, disabled, loading, empty, error, long text, right-to-left, dark mode. Storybook is the full version; "Storybook-lite" is a single /playground route in your own app. Ladle is a lighter Storybook-compatible option for React.
3. Tokens as the only source of values. Every colour, size, radius and duration comes from a named token, so tuning a value in one place updates the whole product (see Systems & Platforms).

In the wild

• Tweetie 2Loren Brichter, 2009
  Introduced pull-to-refresh, later adopted across iOS and the industry (Twitter acquired Tweetie in 2010). Interactions that live in motion are discovered by people who build and feel them.
• Sindre Sorhus's Mac apps2010s to 2020s
  A prolific solo developer who ships many small, focused, native utilities. A personal component kit and fast tooling let one person maintain many polished products.
• Storybookopen source, 2016 onward
  The standard tool for developing UI components in isolation, state by state. Isolation is what makes rare states visible; you can get 80% of it with one page.

Pick one canvas tool, one motion tool if you need it, and your code stack; learn them deeply; and change tools only when a specific, recurring job is blocked, never because something new launched.

Design tools change every year; design skill barely changes in a decade. A tool is worth switching to only if it removes friction you feel weekly. Each switch has a hidden cost: weeks of slower work, migrated files, lost muscle memory, and the attention you spent evaluating instead of designing. Tool-hopping is the solo maker's favourite form of productive-feeling procrastination.

The landscape

The cost of switching

In the wild

• FigmaFigma, launched 2016
  A browser-based, multiplayer canvas that became the default UI design tool. For a solo maker the value is not multiplayer; it is the ecosystem of community files to study.
• PenpotKaleidos, open source
  An open-source design tool whose layouts follow CSS flex and grid concepts. A tool whose model matches your code reduces translation work.
• Rive2020s
  Lets designers build interactive animations with state machines that run in the shipped app. When motion is the product, choose a tool whose output ships, not one that only demonstrates.

Part one recap: connect the ideas

Taste is the trained ability to perceive quality and explain why; it develops faster than skill, so for a long time you will see that your work is not good enough, and that gap is the sign you are on the right path.

In a widely shared 2009 interview about storytelling, Ira Glass, the host of This American Life, described what he wished someone had told him as a beginner. Paraphrased: people get into creative work because they have good taste. For the first few years, what they make is not as good as what their taste tells them it should be. That gap is painful, many quit inside it, and the only way through is a large volume of work, made on deadlines, so that skill slowly catches up with taste.

Two things follow for you. First, the discomfort you feel looking at your own app next to Things or iA Writer is not evidence of lack of talent; it is evidence that your taste works. Second, the way out is volume and practice, not more consumption alone.

Taste is perception plus reasons

Kathy Sierra, in Badass: Making Users Awesome (2015), describes how experts in many fields develop "perceptual knowledge": they can tell good from bad quickly, often before they can explain it, after high-quantity exposure to high-quality examples with feedback. Her example is chicken sexers, who learn to classify chicks by being corrected over many examples, not by memorising rules. The design equivalent: look at many excellent screens, compare them with mediocre ones, and get feedback on your judgements.

Paul Graham's essay "Taste for Makers" (2002) argues the other half: taste is not merely personal preference, because some things really are better, and the qualities of good design (simplicity, timelessness, solving the right problem, suggestiveness) can be discussed. So training taste has two parts: seeing (perceptual exposure) and saying (explaining why). Seeing without saying gives you vague feelings you cannot act on. Saying without seeing gives you rules you apply without judgement.

Four ways to grow taste, in order of power

1. Consume great work daily, briefly. Ten minutes with excellent products, books, type and objects. Exposure calibrates what "good" looks like.
2. Analyse: ask "why" five levels deep. Why is this list calm? No separators. Why does that work? Whitespace groups. Why is it enough? Rows are tall. Why can they be? Few items per day by design. Now you have learned something about Things' philosophy, not its pixels.
3. Copy exactly. Recreate a great screen pixel for pixel (chapter 12). Copying forces you to measure what you only glanced at.
4. Make and compare. Make your version, place it next to the best example, and list every difference. This is where perception becomes skill.

In the wild

• Things 3Cultured Code, 2017
  A task manager often cited for restraint: a quiet palette, a single accent and careful motion. A great study object because each decision is small and visible.
• iA WriterInformation Architects, 2010 onward
  A writing app built around a single typeface family and almost no chrome. Taste often shows most in what is left out.

A swipe file is only useful if every item carries a written note about what it does well and why; an unannotated folder of screenshots is a graveyard, not a library.

Copywriters have kept "swipe files" of great ads for a century. Designers do the same with screenshots, but most designer swipe files fail for one reason: saving is so easy that it replaces thinking. You press a shortcut, feel the small reward of collecting, and never look again. Austin Kleon's Steal Like an Artist (2012) makes the case for collecting influences; the key word is steal, which means understanding something well enough to transform it.

The rule: no save without a sentence. Each item gets a title, the source, the tags you will search by, and one to three sentences on what decision makes it good and where you might use it. That sentence is where the learning happens; the image is just the reminder.

How to structure it

Tag by pattern (empty state, onboarding, settings, paywall, search, reading view, error, toast), not by app, because when you need ideas you are looking for a pattern. Store it somewhere searchable that you already open daily: a folder of Markdown notes with images, an app like Eagle or a notes app, or a Figma page. The tool matters less than the sentence.

## [Pattern]: [what it does in 6 words]
Source:   [app, platform, version or date]
Why:      [the decision that makes it good, 1 to 3 sentences]
Steal:    [where I could use it in my product]
Tags:     #pattern #pattern

Reference libraries

Services such as Mobbin (a large searchable library of mobile and web app screens and flows), Page Flows (recorded user flows) and Refero collect real product UI so you can compare how many apps solve the same pattern. Use them for comparison, not inspiration-scrolling: search one pattern, open ten examples, and write what the best three have in common and how they differ. That turns a library into a lesson.

In the wild

• Steal Like an ArtistAustin Kleon, 2012
  Argues for collecting and studying influences, then transforming them into your own work. Steal the thinking, not the surface.
• Mobbin2020s
  A searchable library of real app screens and flows, filterable by pattern. Best used to compare ten solutions to one problem.

Study an app in five deliberate passes (purpose, structure, screens, details, time), each with its own question, and write as you go; casual use teaches you almost nothing because good design is designed to be invisible.

Good design disappears in use. That is its job, and it is why using a great app daily does not, by itself, teach you why it is great. You need to break the spell on purpose: slow down, change your viewing distance, and ask a different question on each pass. Doctors call this a systematic examination, and the reason is the same: an unstructured look finds the obvious and misses the rest.

The protocol

1. Purpose (15 min). Read the app's site and App Store page. Write: who is it for, what job does it do, and what does it obviously refuse to do? The refusals are the strategy.
2. Structure (20 min). Map every place as a breadboard (chapter 4). Count the top-level destinations, the depth, and where settings live. Name the navigation model.
3. Screens (30 min). Screenshot the three most important screens. On each, measure: margins, the spacing scale, the type sizes and weights, how many colours and what each colour means. Squint at it to see the hierarchy.
4. Details (30 min). Hunt for empty, loading, error, offline and very long content. Read every label and message aloud. Try to break it: rotate, enlarge text, switch to dark mode, turn on VoiceOver.
5. Time (a week, 2 minutes a day). Use it for real. Note what delights on day 1 and irritates on day 7, how notifications behave, how fast it opens, what you stop noticing.

Finish with a one-paragraph verdict: the product's single strongest idea, its biggest weakness, and one thing to steal. The breakdown guides (Breakdowns: Software and Breakdowns: Reading) are worked examples of this protocol; read one before doing your own.

In the wild

• HalideLux, 2017 onward
  A camera app by a two-person team whose makers have published detailed design write-ups about their decisions. Reading the makers' reasoning alongside your own study checks your analysis.
• Heuristic evaluationJakob Nielsen and Rolf Molich, 1990
  A method for inspecting interfaces against a short list of usability principles. Structured passes find more than free exploration (see Testing & Iteration).

Skill grows from practice that has a specific goal, full attention, immediate feedback and a stretch just beyond your current ability; repeating what you already do comfortably, even for years, makes you no better.

Anders Ericsson spent his career studying how experts become expert. His 1993 study with Ralf Krampe and Clemens Tesch-Römer of violinists at a Berlin music academy found that the best students had accumulated far more hours of solitary, deliberate practice. That finding was later popularised (and oversimplified) as the "10,000-hour rule", a framing Ericsson himself criticised: hours alone do not make expertise; the kind of hours does.

In Peak he distinguishes naive practice (doing the activity again and again) from purposeful practice, which has four features: specific goals, focus, feedback, and getting out of your comfort zone. Deliberate practice adds a teacher and a well-understood path of skills. As a solo designer you rarely have a teacher, so you replace them with reference examples and structured self-comparison.

The mechanism Ericsson emphasises is mental representations: detailed internal models of what good looks like and how it is made. An expert typographer looking at a page sees rhythm, measure and colour where a novice sees "text". Deliberate practice builds those representations, and the representations are what let you design faster and better without thinking about rules.

Naive practice vs deliberate practice

In the wild

• Benjamin Franklin's writing practicedescribed in his Autobiography
  He took notes on essays from The Spectator, later rewrote them from his notes, and compared his versions with the originals to find his faults. The original is the teacher; the comparison is the feedback. This is the model for UI copywork.
• PeakAnders Ericsson and Robert Pool, 2016
  The accessible summary of decades of research on expert performance. Read chapters on purposeful practice and mental representations; skip the parts you already know.

Practise in small, repeatable, timed drills with a clear output (katas), copy great work exactly to learn its measurements, and once a week redesign one real screen from start to finish.

In martial arts a kata is a set form practised many times until it becomes automatic. Programmers borrowed the idea (Dave Thomas popularised "code katas" in the 2000s) for small exercises done for practice, not production. Design katas work the same way: thirty minutes, one skill, one output, done often. Their power is the volume. Thirty minutes a day, five days a week for 24 weeks is 60 hours of focused practice, more than most designers do deliberately in years.

Three practice formats

The kata list (34 drills)

In the wild

• Daily UIdailyui.co, 2010s
  A popular email challenge that sends one UI prompt a day for 100 days. Prompts help with consistency; add a reference and a comparison step to turn them into deliberate practice.
• Code katasDave Thomas, 2000s
  Small programming exercises meant to be repeated for practice. Repeating the same kata with a new constraint teaches more than always doing new ones.

Part two recap: connect the ideas

You need a small, deliberate feedback system: users for whether it works, peers for craft, the occasional paid expert for blind spots, and a method for sorting what you hear, because the most useful critique is specific, asked for, and about the work's goal.

Working alone, the absence of feedback is the default state. Months can pass in which nobody but you looks closely at your screens. Worse, the feedback that does arrive is random: a friend's "looks nice", a stranger's "I hate the font", an app review complaining about a feature you never built. Random feedback is either flattering or noisy, and neither helps.

Ed Catmull's Creativity, Inc. (2014) describes Pixar's Braintrust: experienced filmmakers who watch a film in progress and give candid notes, with one important rule. The Braintrust has no authority. The director decides what to do with the notes. That is your model: gather candid input from people who know the craft, then you decide, and log the decision.

Where to find people

• Peers for critique swaps. One or two other solo makers or designers at a similar level. Swap 30 minutes of focused critique every fortnight. This is the most valuable relationship in this chapter.
• Communities. Design circles on Bluesky, Mastodon and X; subreddits such as r/UI_Design and r/userexperience; Discord and Slack communities around tools and indie making. Useful for quick reactions and for finding swap partners, weaker for deep critique.
• Dribbble and showcase sites. Good for visual inspiration and reach; limited for product critique, because shots are judged in isolation, without the user's goal, flow or data.
• Mentorship platforms. Sites such as ADPList connect you with experienced designers for free or paid calls. Arrive with one specific question and screens ready.
• Paid expert reviews. Once or twice a year, pay an experienced product designer for a heuristic review or a one-hour critique. Brief them with your principles and goals so they judge the product you are making, not the one they would make.
• Users. The final critics. Watch them, do not just ask them (see Testing & Iteration).

Ask well, get useful answers

A critique swap template you can paste into a message:

CRITIQUE SWAP · 30 min each
Product + audience:  [one line]
This screen's job:   [one line]
Stage:               [sketch / prototype / shipped]
Please look for:     [1 to 3 specific questions]
Please ignore:       [things already decided or out of scope]
Format:              What works · What confuses · One thing you'd try

Handling what you hear

Feedback arrives as a mix of observations ("I didn't see the button"), interpretations ("it's cluttered") and solutions ("make it blue"). Observations are gold; take them almost at face value. Interpretations are clues; ask what caused them. Solutions are the least reliable part: the problem behind them is usually real, the suggested fix usually is not. Sort before you act.

In the wild

• Pixar Braintrustdescribed in Creativity, Inc., 2014
  Candid notes from peers, with the director keeping full authority over the film. Separate hearing feedback from deciding what to do with it.
• Rocket Surgery Made EasySteve Krug, 2010
  A short book on running small, cheap usability tests with three users. Observing a few people beats asking many for opinions.

Decide quickly when a choice is reversible and slowly when it is not, use your principles as tie-breakers, time-box everything, and stop polishing when another hour would change something no user will notice.

With nobody to disagree with you, you face two opposite failure modes. One is drift: you reopen settled questions every week because nothing marks them as settled. The other is stubbornness: nobody challenges your first idea, so it survives by default. The tools below fix both.

Reversible and irreversible

In his 2015 letter to shareholders, Jeff Bezos described two types of decisions: Type 1 decisions are consequential and nearly irreversible ("one-way doors") and deserve slow care; Type 2 decisions are reversible ("two-way doors") and should be made quickly by individuals or small groups. Most design decisions are two-way doors: a colour, a label, an icon, a spacing value. A few are one-way doors for practical purposes: your data model, URL structure, pricing model, navigation paradigm, the product's name. Spend your deliberation on those.

Principles as tie-breakers

When two options are both reasonable, do not ask "which do I like?" Ask "which does principle 1 prefer?" Your principles (chapter 2) exist exactly for this moment. If neither principle decides it, the choice probably does not matter much: pick one, log it, move on. If the principles conflict, you have discovered that their order matters; number them.

Strong opinions, weakly held

The futurist Paul Saffo described a forecasting habit he called "strong opinions, weakly held": reach a firm, specific conclusion quickly so you can act and test it, but abandon it readily when evidence contradicts it. For a solo designer this is the antidote to both failure modes. Commit firmly enough to build and ship. Write the "revisit if" line in your decision log so you know in advance what evidence would change your mind.

Bikeshedding and the time-box

C. Northcote Parkinson's "law of triviality" (in Parkinson's Law, 1957) observed that a committee will spend little time approving a nuclear reactor, which few understand, and far longer debating a bicycle shed, which everyone feels qualified to judge. Hence "bikeshedding". Alone, you bikeshed with yourself: three evenings on icon corner radii while the onboarding flow stays unexamined. The fix is a time-box written before you start: "Icon style: 45 minutes, then ship whatever is best." Remember Hofstadter's law, from Gödel, Escher, Bach (1979): it always takes longer than you expect, even when you take into account Hofstadter's law. Time-boxes protect you from that too.

When to stop polishing

A practical stop test, three questions: Would a user notice the difference? (If you need to zoom to 400% to see it, no.) Does it break a principle or a system rule? (If yes, fix it; consistency matters.) Is there a screen with a bigger problem? (There almost always is; the screen inventory tells you which.)

In the wild

• Amazon's Type 1 and Type 2 decisionsBezos shareholder letter, 2015
  Argues that treating reversible decisions as irreversible makes organisations slow. A solo maker's version: most UI decisions should take minutes.
• Parkinson's law of trivialityParkinson's Law, 1957
  Time spent on an item tends to be inversely proportional to its importance. Notice where your hours go; they often go to the shed.

Your capacity is the real constraint on your product, so design the product to fit it: budget hours for maintenance and support before features, scope to what you can sustain for years, and work in seasons rather than permanent sprints.

A team product survives one person's bad month. A solo product does not. If you burn out, the product stops: no fixes, no replies, no updates, and users notice within weeks. So sustainability is not self-care advice tacked onto a design course; it is a design constraint, as real as screen size. Every feature you add is a permanent maintenance cost paid in your hours.

Christina Maslach's research describes burnout in three dimensions: exhaustion, cynicism (detachment from the work and its users), and a reduced sense of effectiveness. The World Health Organization's ICD-11 describes burnout as an occupational phenomenon resulting from chronic workplace stress that has not been successfully managed. For solo makers the early sign is usually cynicism: support emails start to feel like attacks and you stop opening the app for fun.

Scope to capacity

Before adding a feature, estimate its lifetime cost, not its build cost. A sync feature might take three weeks to build and then two hours a week forever in conflicts, edge cases and support. A setting doubles the states you test. A new platform (Android, web, Windows) can nearly double maintenance. Paul Jarvis's Company of One argues for questioning growth itself: a business can deliberately stay small and still succeed. For a solo product, "smaller and excellent" is a strategy, not a compromise. It is also the calm-product philosophy of Honest & Calm applied to your own work.

Seasons of building

Cal Newport's Slow Productivity (2024) proposes three principles: do fewer things, work at a natural pace, and obsess over quality. "Natural pace" includes seasonality: periods of intense work followed by lighter ones. Plan your year in seasons rather than a permanent sprint.

In the wild

• Company of OnePaul Jarvis, 2019
  Makes the case for deliberately small businesses that prioritise autonomy and resilience over growth. "How small can this stay?" is a design question.
• It Doesn't Have to Be Crazy at WorkJason Fried and David Heinemeier Hansson, 2018
  Basecamp's founders on calm work habits: fewer meetings, sensible hours, saying no. Calm products are easier to make in calm working conditions.

Part three recap: connect the ideas

Six months, about 8 to 10 hours a week: each week pairs one guide (reading) with daily katas on the same skill, one weekly practice piece, and one concrete deliverable for your capstone product, so every concept is used within days of meeting it.

Reading a guide gives you a mental model. Within a week, without use, most of it is gone. The curriculum is designed so that each idea is used three times in the week you meet it: in daily katas (isolated skill), in the weekly practice (a real screen from another product) and in the capstone deliverable (your own product). Later weeks deliberately revisit earlier skills, because spaced, interleaved practice is retained far better than blocked practice.

Week by week

Two notes on the order. Identity and launch (guide 14) comes late on purpose, because naming and branding a product you have not tested is decoration. And the breakdown guides come after the craft guides, so you can read them as a designer who has wrestled with the same decisions, not as a spectator.

The daily and weekly routine

In the wild

• Shape Up cyclesBasecamp, 2019
  Six-week build cycles followed by a two-week cool-down for fixes, exploration and rest. A fixed rhythm with built-in slack is easier to keep than an open-ended plan.
• The forgetting curveHermann Ebbinghaus, 1885
  Early memory experiments showing rapid forgetting after learning, and the benefit of spaced repetition. Use each idea within days, then revisit it weeks later; the curriculum is built to do both.

Over the 24 weeks, design and ship one small, real, calm product for real users (one job, three to five screens, done excellently), so that every guide's ideas meet a real constraint and you finish with something people use.

Exercises on other people's apps train sub-skills. Only a real product trains integration: the moment when the typography decision fights the information density, the motion spec fights the battery, and the beautiful empty state turns out to be the screen people see only once. A capstone also gives you something no course certificate can: a product you can point to.

The rules are about scope. One job. Three to five main screens. Real users (at least five people who are not you). Shipped (App Store, TestFlight, or a public URL). Small enough to finish in the time the curriculum gives, real enough to teach you everything.

Pick one

• A calm reading log. Log books, see what you read this year, keep quotes. No social feed, no streak guilt.
• A focused writing app. One document at a time, beautiful type, a word goal you can hide.
• A quiet read-later app. Save articles, read them in a clean view, archive.
• A personal recipe keeper. Import, read while cooking with the screen awake, scale servings.
• Your own idea, if it passes the rules above and you can find five real users.

Milestones and deliverables

Capstone rubric

Score yourself at M4 and M7, and ask your critique partner to score you at M7 too. The gap between your score and theirs is itself useful information.

In the wild

• Small, focused indie apps2010s to 2020s
  Many beloved apps began as one job done well by one or two people: a podcast player (Overcast), a weather app, a single-purpose Mac utility. Small scope is how solo makers reach excellence.
• iA Writer's first version2010
  Launched as a deliberately minimal writing app with very few settings. Constraints can be the product's identity, not a limitation.

For a solo maker the shipped product is the portfolio; a case study adds the one thing the product cannot show: the problem, the options you rejected, the evidence, and what you would do differently.

A designer at a company shows mockups because the product belongs to someone else. You own the whole thing, so you can show something more convincing: a live product with real users, plus the reasoning behind it. Anyone evaluating you (a client, an employer, a collaborator, a future user) is really asking two questions: can this person make good things? (the product answers) and can they think? (the case study answers).

Austin Kleon's Show Your Work! argues for sharing process as you go, not only finished results. For a solo maker that habit compounds: your changelog, a short post per milestone and your decision log are already 80% of a case study by the end.

A case study template

# [Outcome-shaped title, e.g. "Logging a finished book in 6 seconds"]
Role: everything (solo) · Timeline: [weeks] · Platform: [..] · Link: [live]

1. Problem       Who, what situation, evidence (quotes, numbers).
2. Constraints   Time, being one person, platform, what I chose not to do.
3. Options       2 to 4 directions with sketches; why each was rejected.
4. Decisions     The 3 most important, each with its cost and principle.
5. Outcome       What users did. Numbers if honest; observations if not.
6. Reflection    What I got wrong, what I would do differently, what's next.

In the wild

• Halide's design postsLux, 2017 onward
  The makers publish long posts explaining the reasoning behind their camera app's interface and updates. A product with a public reasoning trail is a portfolio in itself.
• Show Your Work!Austin Kleon, 2014
  Ten short chapters on sharing process openly and regularly. Document as you go; the case study then writes itself.

Rate yourself honestly on twelve competencies at four levels, three times over the curriculum (weeks 1, 12 and 24), and spend most of your practice on the two lowest; the shape of the chart matters more than its size.

Stuart and Hubert Dreyfus described skill acquisition as a series of stages, from the novice who follows context-free rules, through the advanced beginner who starts to recognise situations, the competent performer who plans deliberately and feels responsible for outcomes, to the proficient performer who sees what matters intuitively (and, beyond, the expert). The four levels below adapt the first four stages to product design. Expert is left off on purpose: it takes years, and a self-rating of "expert" is usually a sign of the opposite.

A self-assessment is only useful if it is honest and specific. Rate yourself by evidence, not feeling: "Competent in typography" should mean you can point to a screen where measure, scale and leading were deliberate. When unsure between two levels, choose the lower. Then ask your critique partner to rate you too; the differences are the interesting part.

The matrix

In the wild

• The Dreyfus modelStuart and Hubert Dreyfus, 1980
  A five-stage model of skill acquisition used in nursing (Patricia Benner's From Novice to Expert, 1984), software and other fields. Levels describe how you see situations, not only how much you know.
• Career ladders and skill matricescommon in design teams
  Many design organisations publish competency matrices for growth conversations. A matrix turns vague "get better" into specific next steps; you can be your own manager with one.

Wrap-up

You now have a way of working, not just a set of ideas: a loop sized to risk, five living documents, fast sketching and shaping, prototypes that answer questions, a design-in-code workflow, a system for training taste, a feedback network, a way to decide alone, a capacity budget, and a six-month plan with a real product at the end. None of it works if you only read it. The two-week assignment below is the bridge.

Practice assignment for the next two weeks

1. Day 1: Create the /design folder with all five files (Exercise 2.1). Rate yourself in the skills lab and save a snapshot.
2. Day 2: Choose your capstone (or declare your current product the capstone). Write the brief and start the parking lot.
3. Days 3 to 12: One 30-minute kata each weekday, at least four on your two lowest skills, each compared with a reference and logged.
4. Day 4: Crazy 8s on your capstone's most important screen; breadboard its main flow.
5. Day 6: Start an annotated swipe file with nine entries across three patterns.
6. Day 8: Find a critique-swap partner and send them the template.
7. Day 10: Build a playground route with your first five components and their states.
8. Day 13: Run the five-pass study on one app you use daily.
9. Day 14: Put the 24-week plan in your calendar. Write half a page: what changed in how you work.

Reading list

• Shape Up
  Ryan Singer, 2019 (free online) · Breadboards, fat markers, appetite and rabbit holes; the best process book for small teams and solo makers.
• Sketching User Experiences
  Bill Buxton, 2007 · Why sketching is the core of design, and the difference between sketches and prototypes.
• Peak: Secrets from the New Science of Expertise
  Anders Ericsson and Robert Pool, 2016 · Purposeful and deliberate practice, and mental representations, from the researcher himself.
• Badass: Making Users Awesome
  Kathy Sierra, 2015 · Perceptual learning and skill building; written for product makers, and doubly useful applied to yourself.
• Ira Glass on Storytelling
  Ira Glass, 2009 (video interview series) · The source of "the Gap"; short and worth watching when you feel your work is not good enough.
• Taste for Makers
  Paul Graham, 2002 (essay) · An argument that taste can be good or bad, and a list of what good design tends to share.
• Steal Like an Artist and Show Your Work!
  Austin Kleon, 2012 and 2014 · Short books on collecting influences and sharing process; the basis for your swipe file and case studies.
• Creativity, Inc.
  Ed Catmull with Amy Wallace, 2014 · The Braintrust and candid feedback without authority.
• Sprint
  Jake Knapp with John Zeratsky and Braden Kowitz, 2016 · The design sprint, Crazy 8s and fast prototyping.
• What do Prototypes Prototype?
  Stephanie Houde and Charles Hill, 1997 (paper) · A clear model for choosing what a prototype should explore.
• Slow Productivity
  Cal Newport, 2024 · Fewer things, natural pace, obsessive quality; a sustainable rhythm for solo work.
• Company of One
  Paul Jarvis, 2019 · Staying small on purpose; scope as a business strategy.
• The Creative Habit
  Twyla Tharp, 2003 · A choreographer on routine and practice as the basis of creative work.