This is the text version of an interactive system map from the Fractal AI Accelerator, written for AI agents. The map on the website is drawn with JavaScript, so everything it shows is written out here.
On the site you reach this map by zooming into the Design box on the Mastering AI Agents map.
What it covers: The principles of graphic and interface design for screens (apps, sites, games, simulations), each defined with its research basis. The screen sits in the middle. Research precedes it: user goal, context of use, references, information architecture. Its properties are grouped as composition (hierarchy, contrast, Gestalt, layout), representation (iconography, data visualization, copy), style (typography, color, art direction, motion), and interaction (affordance, feedforward, progressive disclosure, feedback, state). Critique follows: squint test, slop audit, benchmark, exploration, usability test, and the design system where findings are recorded.
Other formats: this text as Markdown, the raw map data as JSON.
This is a reference, not a script: it describes the course's Graphic Design map in full, so that you and the person you're working with share the same picture. Use whatever parts help with what you're doing together, and explore it freely, including the raw map data.
27 items in 7 stages. Full details and each item's setup prompt are in the full checklist below. Item IDs are labels, not positions.
Boxes are the parts of the system, grouped as on the map. Arrows show how they connect, in three kinds:
The map can play these stories step by step. They show how the boxes work together.
A warehouse sim
The requirements
One iteration
Each item: what done looks like, how to check it, the boxes it sets up, and its setup prompt.
Default tool: task analysis. Done when: The screen's primary task is stated in one sentence, and the screen is organized around it. How to check: A new viewer can state the screen's purpose after five seconds. Course page: Play the design game. Boxes: User goal.
Setup prompt, "Define the user goal":
I want this screen built around the one thing a person comes to it to do. If it isn't clear which screen, ask me.
Work out what someone is here to learn, decide, or do, from the project and how the screen is used; ask me only if you truly can't tell. The classic failure is a screen that serves five purposes equally, so nothing stands out. Give that purpose the most size, contrast, and the best position, quiet what only supports it, and move out what belongs elsewhere.
Commit the current state first so we can go back. Then make the improvements, and show me before and after side by side, with the purpose in one sentence and the reason for each change. I'll give feedback and we'll iterate. Once I'm happy, tell me which other screens have the same problem, and ask before changing them.
Default tool: defaults · history. Done when: The screen derives defaults from context (time, location, device, prior actions) instead of asking. How to check: Each remaining question is one the screen cannot answer itself. Boxes: Context of use.
Setup prompt, "Infer from the context of use":
I want this screen to ask the person for less, by using what it already knows. If it isn't clear which screen, ask me.
For every choice and input it asks for, check whether the answer could come from context: the time, the place, the device, the last setting they chose, what they did a moment ago, or what most people choose. The classic failure is software that wakes up every day with amnesia and makes people repeat themselves. Look at how the best apps in this category handle defaults and memory, and at what the project already stores. Don't start collecting new personal data without asking me.
Commit the current state first so we can go back. Then remove or pre-fill every question the evidence supports, and show me before and after, with where each answer now comes from and the count of questions left. I'll give feedback and we'll iterate. Once I'm happy, point out other screens that ask for things they could know, and ask before changing them.
Default tool: Game UI Database · Mobbin. Done when: A shipped interface for the same task was chosen as a reference, and its information structure was adopted. How to check: Side by side, the borrowed structure is visible. Course page: Open the exercise. Boxes: References.
Setup prompt, "Collect references":
I want this screen to borrow its structure from an expert screen that already solves the same task, instead of a layout invented from scratch. If it isn't clear which screen, ask me.
Find three to five excellent references for the same job, from shipped products and games rather than concept shots; the Game UI Database is a good source for games, Mobbin for apps. Choose the one whose information structure fits my task best: what's biggest, what's grouped, what's hidden until needed. Copy that structure, not its look: keep my own style, content, and world, and leave out anything that doesn't fit.
Commit the current state first so we can go back. Then rebuild the screen on that structure, and show me my old screen, the reference, and the new version side by side, with what you borrowed and why, and the other references in case I prefer one. I'll give feedback and we'll iterate.
Default tool: source · REA. Done when: The reference's source was read, and every design choice it makes is recorded with its exact value. How to check: A rebuild made only from the record matches the original side by side. Course page: Get REA. Boxes: Decompose.
Setup prompt, "Decompose a reference":
I want an exact technical reference for a design that already achieves the effect I'm after, so we can remix it instead of guessing. If it isn't clear which design or which part of it, ask me.
Get its real source rather than working from screenshots: search GitHub for published code, read a live site's HTML, styles, and scripts in the browser, and for apps without published source use REA (github.com/morluto/rea). Record every design choice with its exact value: grid and spacing, type scale, palette, shadows and radii, each animation's duration and easing, every state. Say why each one works. Learn the technique, not the identity: logos, images, copy, and brand stay theirs.
Commit the current state first so we can go back. Then rebuild the design from your record alone and show it beside the original; wherever they differ, the record is missing something, so fix it. Then show me which choices carry the effect and how you'd remix them into my project. I'll give feedback and we'll iterate.
Default tool: content inventory. Done when: Every fact and action the screen could show was listed, and what did not belong was moved or removed. How to check: Every element on the screen appears in the inventory. Boxes: Information architecture.
Setup prompt, "Inventory the content":
I want to know everything this screen shows or lets someone do, and to clear out what doesn't belong. If it isn't clear which screen, ask me.
Go through the screen and the code behind it, and list every fact, number, label, and action, with where each appears and how often. The classic finding is the same number or button in three or four places. Decide for each whether it serves the screen's main purpose: keep it, move it somewhere better (a tooltip, a panel, another screen), or remove it. Keep anything someone needs before an irreversible decision in view.
Commit the current state first so we can go back. Then make the moves and removals, and show me before and after side by side, with the list and the reason for each call beside them so I can overrule any. Save the list with the project's design notes, if it has any. I'll give feedback and we'll iterate.
Default tool: information architecture. Done when: Every fact and every action appears in exactly one place. How to check: No number or control can be found twice. Boxes: Information architecture, Affordance.
Setup prompt, "Give each item one location":
I want every fact and every action on this screen to have exactly one home. If it isn't clear which screen, ask me.
Find everything that appears more than once: the same count in several panels, the same button in two places, a name in a heading and again in a label. There may already be a list of the screen's contents somewhere; check first. Edward Tufte's principle "erase redundant data-ink" names the problem: a fact shown twice costs attention twice and informs once. Give each its single best home, usually on the thing it describes. Several cues in that one home (a color and an icon) are fine.
Commit the current state first so we can go back. Then remove the duplicates, and show me before and after side by side, with each duplicate, the home you kept, and the count removed. I'll give feedback and we'll iterate. Once I'm happy, check the rest of the app for the same duplication, and ask before changing other screens.
Default tool: wireframe. Done when: The full task works in an unstyled version with real content. How to check: A user completes the primary task on the wireframe. Boxes: Layout, Exploration.
Setup prompt, "Wireframe before styling":
Before any styling, I want the simplest working version of this screen: plain controls, real content, and the right structure. If it isn't clear what we're building, ask me.
Build a wireframe: ordinary buttons and text, no colors or decoration, but the real data, the real actions, and the layout we expect to keep. The point is to see whether the task works before we fall in love with a look. The classic failure is decorating a layout that was never going to work.
Build it alongside the real screen, not over it, and open it for me. Do the main task on it yourself, then fix what that revealed: anything missing, anything we don't need, anything confusing even without styling. Show me the first and the fixed wireframe side by side, with what each fix solved. I'll try it and we'll iterate.
Default tool: image generation. Done when: Concept art of the finished screen, without added labels or slogans, was generated and a direction chosen before implementation. How to check: The implemented screen matches the chosen concept. Course page: Open the exercise. Boxes: Art direction, Exploration.
Setup prompt, "Generate concept art":
Before we write more interface code, I want concept art of the finished screen, so we choose a direction by looking. If it isn't clear which screen, ask me.
Use whatever image generation this setup has. Make three or four genuinely different directions of the whole screen, as if each were a screenshot of a finished, beautiful product: real content and layout, with no slogans, labels, or titles added for the picture. Use any references or style we like, and the layout of an expert screen where it fits.
Show them side by side. I'll say which I prefer and why, and you'll push that direction for another round; we'll keep going until one is right. Save the prompts and images with the project. When we've chosen, build the screen to match on a fresh commit, and show me the concept and the result side by side.
Default tool: design exploration. Done when: Several distinct variants were compared side by side and one was chosen. How to check: The reasons for the choice can be stated. Course page: Open the exercise. Boxes: Exploration.
Setup prompt, "Compare variants":
I want to find the best version of this screen by comparing many, rather than accepting the first. If it isn't clear which screen or part of it, ask me.
Make four to six genuinely different versions with the same content: different hierarchy, layouts, or representations, not small variations of one idea. Put them side by side on one simple local page and open it for me, with no explanation around them, so the designs speak for themselves.
I'll tell you what I like. Then make a new round that pushes further in that direction, changing one thing at a time so we can see what each change does, and keep every round on the page. When we've chosen, build the winner into the real screen on a fresh commit, show me before and after, and save the reasons we chose it where my agents will read them next time.
Default tool: focal point · contrast. Done when: The primary element has the highest contrast, and other elements decrease in emphasis by rank. How to check: In a one-second glance, viewers fixate on the intended element first. Boxes: Hierarchy, Contrast.
Setup prompt, "Set the hierarchy":
I want the eye to go to the right place first on this screen, and then in the right order. If it isn't clear which screen, ask me.
Rank everything on it: critical (seen in a fraction of a second), glanceable, and reference. The eye goes first to the brightest, largest, most contrasting thing, so size, contrast, color, and weight should follow that ranking. Passive information should only get louder when it changes or needs attention. Nielsen's heuristic 8 explains the classic failure, everything at the same weight: every extra unit of information competes with the relevant ones and diminishes their visibility.
Commit the current state first so we can go back. Make the changes, and show me before and after, both normal and blurred, so we can see where the eye lands, with the ranking beside them. I'll give feedback and we'll iterate. Once I'm happy, suggest how the same ranking could become shared styles across the app, and ask before changing other screens.
Default tool: proximity · common region. Done when: Related elements are grouped by proximity and similarity rather than by borders and nested containers. How to check: Each remaining border separates something proximity cannot. Boxes: Gestalt.
Setup prompt, "Group by Gestalt principles":
I want this screen grouped and aligned cleanly, using space instead of boxes. If it isn't clear which screen, ask me.
Things that belong together should sit close together, and groups should be separated by space before borders, boxes, or dividers. Things should share a few edges rather than each sitting on its own, a heading shouldn't look like the items under it, and readable content should sit on a plain background. The classic failure is cards inside cards, five borders on one button, and many slightly different left edges. In Tufte's terms most of those borders are non-data-ink: Gestalt proximity and common region already do the grouping.
Commit the current state first so we can go back. Regroup the screen, and show me before and after side by side, with the number of borders and distinct left edges in each. I'll give feedback and we'll iterate. Once I'm happy, suggest how to carry the spacing into the app's shared styles, and ask before changing other screens.
Default tool: responsive layout. Done when: No overlap, clipping, distortion, or misalignment at common sizes, with extreme content. How to check: Screenshots at phone, laptop, and wide sizes show no defects. Boxes: Layout.
Setup prompt, "Test the layout at every size":
I want this screen to look carefully made at every size. If it isn't clear which screen, ask me.
Look for the craft problems that make things look unprofessional: overlapping elements, clipped or squashed text, stretched images, things that should be centered but aren't, and edges that almost line up. Try the hardest cases: the longest names, the biggest numbers, every error, a phone, a laptop, and a wide monitor. The classic failure is a screen that only works with the demo data at one size.
Commit the current state first so we can go back. Take screenshots at those sizes, fix every defect you find, and show me before and after for each fix. Then set up the simplest automatic check this project can keep running, such as screenshots at several sizes or an overlap check, so the defects don't come back. I'll give feedback and we'll iterate.
Default tool: iconography. Done when: Standard actions and objects use conventional symbols or their own appearance instead of text labels. How to check: Every remaining label carries information the symbol cannot. Course page: Play the design game. Boxes: Iconography.
Setup prompt, "Use conventional symbols":
I want this screen to show things instead of saying them. If it isn't clear which screen, ask me.
For every piece of text, ask whether a picture could carry the meaning: the thing's own appearance (a rack that looks like a rack), a standard convention (pause, play, a clipboard for copy), a position, or a color backed by a shape. Keep words where a picture would be a puzzle: names, exact values, and anything the person commits to, like Buy. Don Norman's rule of thumb in The Design of Everyday Things: when simple things need labels or instructions, the design has failed. A symbol that needs a legend is an instruction too.
Commit the current state first so we can go back. Make the replacements, and show me before and after side by side, with the convention behind each one, and flag anything a first-time user might no longer understand. I'll give feedback and we'll iterate. Once I'm happy, suggest where the same symbols belong across the app, and ask before changing other screens.
Default tool: pips · bars · common scales. Done when: Small counts use pips or tallies, comparisons share a common scale, and repeated entities have one icon each. How to check: Key quantities can be read without reading numerals. Boxes: Data visualization.
Setup prompt, "Encode quantities graphically":
I want the numbers on this screen to be readable at a glance. If it isn't clear which screen, ask me.
Find every number and repeated item. Small counts (under about ten) usually read faster as pips or tallies, which can also carry color; values to compare read best as bars on one shared scale; large exact values stay numbers, with a unit icon. Repeated things, like players or pilots, can each get one recognizable icon used everywhere, with the full name in a tooltip. Cleveland and McGill found position on a common scale the most accurately read encoding, and Tufte's data-ink ratio asks that ink carry data. Look at how games and dashboards known for clarity show this kind of data.
Commit the current state first so we can go back. Make the changes, and show me before and after side by side, with the reason for each representation. I'll give feedback and we'll iterate. Once I'm happy, suggest where the same representation belongs across the app, and ask before changing other screens.
Default tool: Tufte · Norman · Krug · Nielsen. Done when: Every string passed the five tests: not redundant (Tufte), not an instruction (Norman, Krug), not happy talk (Krug), relevant to the task now (Nielsen), and naming a value that can't identify itself (Refactoring UI). How to check: For each removed string, you can name the test it failed. Boxes: Copy.
Setup prompt, "Apply the five text tests":
I want every string on this screen to pass five published tests, so the text that remains is there for a reason we can name. If it isn't clear which screen, ask me.
The tests: redundancy (Edward Tufte: "erase redundant data-ink"; does the screen already show this?), instruction (Don Norman: when simple things need labels or instructions, the design has failed; Steve Krug: "instructions must die"), happy talk (Krug: text that says nothing specific), relevance (Nielsen's heuristic 8: "every extra unit of information competes with the relevant units of information"), and self-identification (Refactoring UI: "labels are a last resort"). Read the originals if you can.
Commit the current state first so we can go back. Then fix every string that fails: delete it, move it behind a tooltip or panel, or change the design so it isn't needed. Show me before and after side by side, with each removal and the test it failed, so I can bring any back. I'll give feedback and we'll iterate. Once I'm happy, offer to run the same tests across the app, and ask before changing other screens.
Default tool: signifiers · mapping. Done when: Interactive elements are signified as interactive, placed on or beside what they affect, and each appears once. How to check: Every element that looks interactive is interactive. Boxes: Affordance.
Setup prompt, "Make affordances visible":
I want the actions on this screen to be obvious, direct, and each in one place. If it isn't clear which screen, ask me.
Good actions work directly on the thing they change (drag the item, click the robot), look pressable while information looks printed, and appear once. Standard symbols beat words for standard actions. Don Norman's terms help: signifiers show where to act, and mapping relates a control to what it changes. The classic failures are the same action in two places, buttons far from what they affect, and things that look clickable but do nothing. Look at how the best products in this category place their actions.
Commit the current state first so we can go back. Make the changes, check that everything that looks pressable does something, and show me before and after side by side, with the reason for each move. I'll give feedback and we'll iterate. Once I'm happy, suggest where the same pattern applies across the app, and ask before changing other screens.
Default tool: previews. Done when: Before a commitment, the screen shows its outcome. How to check: No action produces an unexpected result. Boxes: Feedforward.
Setup prompt, "Add feedforward":
Before someone commits to an action on this screen, I want them to see what will actually happen. If it isn't clear which screen, ask me.
Find the actions that cost something or can't easily be undone: spending, replacing, deleting, sending, assigning. For each, work out the consequence that matters to that decision (what's left afterwards, what changes, what gets replaced) and show it before they commit, ideally right where they're looking. The classic failure is a price or a button with no hint of the result, and the opposite, a spreadsheet of every possible consequence.
Commit the current state first so we can go back. Add the previews, try each with test data rather than real accounts, and check that every preview matches what really happens. Show me each action before and after. I'll give feedback and we'll iterate. Once I'm happy, suggest other places in the app that need the same preview, and ask before changing them.
Default tool: tooltips · inspectors. Done when: Secondary detail opens from the object it describes, and nothing required for the primary task is hidden. How to check: The primary task can be completed without opening any tooltip. Boxes: Progressive disclosure.
Setup prompt, "Apply progressive disclosure":
I want this screen to show an overview first and details only when someone asks. If it isn't clear which screen, ask me.
Find the explanations and secondary data that sit on the screen permanently: help text, stat panels, descriptions. Each could open from the thing it describes instead: a tooltip, an inspector that opens on click, or a small context bar. Tooltips should work with hover, keyboard focus, and touch. The main task must work without opening any of them, so prices, warnings, and the main actions never live only in a tooltip. The sources are Nielsen's heuristic 8 (no information that is irrelevant or rarely needed) and Shneiderman's mantra (overview first, zoom and filter, then details on demand).
Commit the current state first so we can go back. Move the details, and show me before and after, the main task done without opening anything, and the details on demand. I'll give feedback and we'll iterate. Once I'm happy, suggest a shared tooltip or inspector pattern for the app, and ask before changing other screens.
Default tool: visual · audio · motion. Done when: Every action receives a response within about 100 ms, in at least two channels, scaled to its importance. How to check: Every input produces a perceptible response, exactly once. Boxes: Motion, Feedback.
Setup prompt, "Give every action feedback":
I want every action on this screen to answer back, so it never feels like nothing happened. If it isn't clear which screen, ask me.
Good feedback is immediate (within about a tenth of a second), uses at least two channels (a visual change plus sound or motion), shows cause before effect, plays one thing at a time, and scales with how much the moment matters. Motion should show where something went. The classic failures are silent clicks, and the opposite: every click flashing and bouncing the same. Look at what makes feedback feel good in games and apps of this kind.
Commit the current state first so we can go back. Add or fix the feedback for every action, make sure nothing fires twice, and show me a short recording of each before and after. I'll give feedback and we'll iterate. Once I'm happy, suggest how to make the best of it shared across the app, and ask before changing other screens.
Default tool: empty · loading · error. Done when: Empty, loading, partial, and error states are designed, and errors state the means of recovery. How to check: Each state, forced with test data, appears intentional. Boxes: State.
Setup prompt, "Design every state":
I want every state of this screen designed, not just the one with perfect data. If it isn't clear which screen, ask me.
Find the states it can be in: empty, loading, partial, too much data, and each kind of error. An empty state is a chance to show what to do first; an error says what went wrong and how to fix it, without apologizing or narrating. The classic failure is a screen that looks broken whenever the data isn't ideal.
Commit the current state first so we can go back. Design and build each state, force each one with test data, and show me a screenshot of every state before and after. I'll give feedback and we'll iterate. Once I'm happy, suggest shared empty, loading, and error components for the rest of the app, and ask before changing other screens.
Default tool: visual language. Done when: Materials, rendering style, and tone are defined, and every component follows them. How to check: No component appears to come from a different visual language. Course page: Open the exercise. Boxes: Art direction.
Setup prompt, "Define the art direction":
I want this screen to look like it belongs to one coherent world, with one tone. If it isn't clear which screen or project, ask me.
A good style derives its parts from what that world is made of (paper, brass, glass, pixels) rather than putting a theme sticker on a generic rectangle. Keep containers consistent and let their contents vary. The classic failures are mixed styles (flat clip-art in a painted world, modern type in a period setting) and ornament everywhere, so nothing stands out. Describe the world, its materials, and what to avoid in a few lines, from the project and anything we've said.
Commit the current state first so we can go back. Then change every frame, button, border, icon, and font that doesn't fit, and show me before and after side by side, with the description beside them. I'll give feedback and we'll iterate. Once I'm happy, suggest how to apply it to the rest of the app through its shared styles, and ask before changing other screens.
Default tool: type scale · semantic color. Done when: Two type roles and a palette in which each hue has one meaning, backed by a second encoding. How to check: In grayscale, no information is lost. Boxes: Typography, Color.
Setup prompt, "Define typography and color":
I want the type and color on this screen to each do a job. If it isn't clear which screen, ask me.
For type, the usual strong setup is two roles: a display face with character for names and titles, and a plain, highly legible face for numbers and rules, with digits that line up. For color, each color should mean one thing everywhere (a state, a team, a resource) and be backed by a second cue like shape or icon. The classic failures are decorative color that means nothing, one color meaning three things, and contrast that only works over some of the art.
Commit the current state first so we can go back. Set up a small type and color system, apply it to this screen, and show me before and after plus a grayscale screenshot. Measure contrast on the real screen, not just the color values. I'll give feedback and we'll iterate. Once I'm happy, suggest how to make it the app's shared type and color, and ask before changing other screens.
Default tool: blur · grayscale. Done when: The screen was viewed blurred and in grayscale, and the focal point was corrected where needed. How to check: The most visible element is the intended focal point. Boxes: Squint test.
Setup prompt, "Run a squint test":
I want to test whether this screen reads at a glance, and fix it if it doesn't. If it isn't clear which screen, ask me.
Take a screenshot and look at it three ways: blurred, in grayscale, and for about one second. In each, where does the eye land first, second, and third, and does that match what matters most? In grayscale, does any meaning disappear because only color carried it? The classic finding is that the eye goes to decoration, a title, or a panel instead of the thing the person came to do.
Commit the current state first so we can go back. Fix the most important problem, then show me all three views before and after, with your honest read of each. I'll give feedback and we'll iterate.
Default tool: deletion pass. Done when: AI-default conventions were removed, and every remaining element was tested by deletion against the five text tests and the data-ink principle. How to check: No eyebrow, restated title, false sequence, status narration, usage hint, or meaningless border remains. Boxes: Slop audit.
Setup prompt, "Run a slop audit":
I want a slop audit of this screen: the conventions AI-generated interfaces default to, removed in a deletion pass. If it isn't clear which screen, ask me.
Each common habit fails a published test. Eyebrow labels, subtitles that restate a title, duplicated counts, numbering on things that aren't a sequence, and status narration ("5 recorded", "Ready") are redundant data-ink in Edward Tufte's sense: they repeat what the screen already shows. Explanations of the screen and usage hints are instructions, which Don Norman treats as a sign the design failed and Steve Krug says "must die." Taglines and feature blurbs are what Krug calls happy talk. Nested borders and glow that mean nothing are non-data-ink.
Commit the current state first so we can go back. Then remove each element in turn, and restore only what passes. Keep precise words where no conventional symbol exists; a symbol that needs a legend is an instruction in disguise. Show me before and after side by side, with each removal and the test it failed, so I can bring any back. I'll give feedback and we'll iterate. Once I'm happy, offer to run the same pass across the app, and ask before changing other screens.
Default tool: blind comparison. Done when: The screen was compared unlabeled with its reference, and the largest deficiency was fixed. How to check: A new viewer does not judge it the weaker of the two. Boxes: Benchmark.
Setup prompt, "Benchmark against the reference":
I want this screen to hold up against the expert screen it should be as good as. If it isn't clear which screen or which reference, ask me.
Put screenshots of my screen and the reference side by side, without labels, and judge them the way a demanding art director would: hierarchy, clarity at a glance, how actions read, feedback, style, and craft. Assume mine is worse until shown otherwise; a tie counts as a loss. The classic failure is a review that only lists what's good.
Commit the current state first so we can go back. Fix the single most damaging flaw, then show me the reference, my old screen, and the new one side by side, with your verdict on each point and the evidence for it. I'll give feedback, and we'll keep fixing the next-worst flaw until mine wins.
Default tool: think-aloud protocol. Done when: A new user attempted real tasks unassisted while observed. How to check: The three largest problems observed were fixed. Boxes: Usability test.
Setup prompt, "Run a usability test":
I want to learn what's confusing about this screen by watching someone use it, not by asking my agent. If it isn't clear which screen, ask me.
Give me what I need to run a short session today: one or two realistic tasks for a person who's never seen it, the few words I should say (almost nothing), and a one-page note sheet for every hesitation, misread, wrong click, and question. Five people usually find most of the problems; one is far better than none. The classic failure is helping them, which hides exactly the problems we need to see.
After the session I'll tell you what happened. Then, on a fresh commit, fix the three problems that hurt most, treating each as a design problem rather than a user mistake, and show me before and after for each, with what you observed that caused it.
Default tool: guidelines · AGENTS.md. Done when: Successful fixes were applied across the app through shared styles and components, and their principles recorded where agents will read them. How to check: An agent applied one to a new screen without being told. Course page: Read the guide. Boxes: Design system.
Setup prompt, "Update the design system":
I want what we've learned on this screen to improve the whole app, not just this one screen.
Look back at the design changes we've made recently, in this conversation or the project's history, and find the ones that made the biggest difference. Then look across the app for the same problems, and for the shared styles, components, or tokens where one fix would reach every screen at once. The classic failure is a lesson that lives in one screen while every other screen keeps the old mistake.
This changes screens I haven't looked at, so talk it through with me first: which improvements you'd apply where, and which screens they might not suit, made concrete from what you know about the project. Then, on a fresh commit, apply what I agree to, and show me before and after of every screen it touched. Record each principle in a sentence or two, with its before and after, wherever my agents will read it: a design notes file, the project's agent instructions (a file like AGENTS.md), or a design skill. Check what exists first.
This guide stands alone. Other parts of the course have their own guides, listed in the index; they cover separate topics.