What the track built
Every session in this track ended with something you could put in a file, not a feeling. That was deliberate, and tonight is why. The Cadence shared-summary feature is not a screen you draw in one sitting - it is nine decisions already made, sitting in nine artifacts, waiting to be assembled and defended. If any of them are missing, tonight will find out. That is also fine: knowing which artifact you skipped is more useful than a pretty capstone.
LiveThe nine artifacts you should have on disk5 min▶
Open your folder and check. This is the whole track, in the order it happened:
- b1 - the loop and the lab. Brief, generate, critique, direct, ship, plus the scoring standard the rest of the track ran on.
- b2 - the constraint brief. One primary action, one type scale, one spacing unit, one accent, a contrast floor. Not an adjective in sight.
- b3 - the annotated board and the rejected-options file. Direction with reasons attached, and the record of what you turned down.
- b4 - the flow, the drafted screens and the state list. Including the states generated work forgets: empty, loading, error, too-long, offline.
- b5 - the review script. Five checks in running order, written as something you can paste into a comment.
- b6 - the token set. Colour, type, spacing and radius as named values, so no number on the screen is a hand-typed one-off.
- b7 - the imagery standard. What is allowed, what is generated, what is licensed, and where the provenance is recorded.
- b8 - the copy set. Every string on the feature, including the AI-disclosure line and the error and empty states.
- b9 - the spec. The document a front-end engineer can build from without asking you a question they should not have to ask.
The capstone adds one thing to that list: the assembled, reviewed, defensible feature itself. Everything else is already yours.
Self-studyIf you skipped a session, do this instead2 min read▶
Gaps are common and mostly recoverable in an hour, but two are not worth improvising. No token set (b6)? Stop and write one - every other artifact assumes it, and the ship review checks it. No copy set (b8)? Write the strings before the review, never during; copy invented in a review is the copy that ships, and it is always the weakest part of the feature. The other two gaps are cheaper: reconstruct the rejected-options file (b3) from memory while you still can, and add the AI-specific states (b4) before you present, because the review will surface them loudly either way.
Assemble it, then test each part 8 min live
Assembly is not a design activity, and that is the point of doing it deliberately. Each artifact arrives with a test it has to pass, and the tests are small enough to run in a few minutes each. Work down the table, then read the last two rows twice, because those are the ones that decide whether this ships.
| Artifact | Where it came from | The test it must pass |
|---|---|---|
| Constraint brief | b2 · art-direction prompting | A stranger could reject your screen using only this document. No adjective is doing load-bearing work. |
| Annotated board + rejected options | b3 · research and moodboards | Every reference has a reason next to it, and at least three serious options were turned down in writing. |
| Flow, screens and state list | b4 · UI drafting | Every state in the list has a drawn screen, including empty, error, too-long and the AI-specific ones. |
| Review script | b5 · the critique lab | Someone else can run it on your work without you in the room and reach the same five verdicts. |
| Token set | b6 · design systems and tokens | Every colour, size, space and radius on the built screen resolves to a named token. Zero hand-typed values. |
| Imagery standard | b7 · illustration and imagery | Each asset passes four questions: direction, brand fit, rights, provenance. Any "probably fine" is a fail. |
| Copy set incl. AI disclosure | b8 · content design and microcopy | Read aloud without stumbling. The disclosure is visible, plain, and does not compete with the meeting title. |
| The spec | b9 · handoff to code | An engineer can build it without asking you anything the spec should already answer. |
| ★ Gate 1 - the measurable gate | the lab, on the built screen | 100 of 100 on the five checks: hierarchy, type scale, spacing rhythm, contrast, colour restraint. Run on what was built, not on the mock. |
| ★ Gate 2 - the judgement gate | you, out loud, in one sentence | You can name the idea in one sentence, and the loudest thing on screen is the thing that matters to the user. No number can stand in for this. |
LiveNaming the idea in one sentence4 min▶
The one-sentence test is harder than it sounds because the failure mode is a sentence that describes the feature rather than the idea. Feature descriptions are always available, which is why they are worthless as a test.
"It is a summary screen with a share button, an AI-generated label, the meeting title, the attendee list and the key points, in a clean modern layout."
"The whole screen exists to make one nervous decision easy: the summary is a machine's guess, and this screen makes it obvious what the machine claimed and effortless to fix it before you send it to your team."
Notice what the second sentence gives you. It tells you what the loudest thing should be - the summary text and the edit affordance, not the AI badge and not the share button. It tells you what the disclosure copy is for. It tells you which state matters most. An idea is useful precisely because it makes later decisions fall out of it.
The ship review, in running order 9 min live
Run this as a script, top to bottom, on the built thing. It takes about twenty minutes on a real feature and it is the same script every time, which is the whole value - a review that varies by mood is not a standard. The first six steps are checks. The last one is the gate.
LiveSteps 1 to 3 - the built screen, every state, the words5 min▶
- 1 · Run the five checks in order, on the built screen. Hierarchy, type scale, spacing, contrast, colour restraint - and on what shipped, not on the mock. The gap between a design file and a built component is where most of the score goes missing, because that gap is full of defaults nobody chose.
- 2 · Walk every state, including the AI-specific ones. Empty, loading, error, too-long, offline - and then the three this product owns: a low-confidence transcript, a wrong speaker attribution, and the user has corrected the summary. That last one matters most. A summary the user has edited is no longer the machine's claim, and the screen should stop presenting it as one.
- 3 · Read the copy out loud, including the disclosure line. Out loud, not in your head. Stumbling is the signal. Check that the disclosure is honest about what was generated, plain enough to skim, and not so prominent that it outranks the meeting title.
LiveSteps 4 to 7 - tokens, imagery, and the gate5 min▶
- 4 · Confirm every value came from a token. Open the inspector and pick five values at random - a padding, a font size, a border colour, a radius, a text colour. If any of them is a literal rather than a named value, you have a system that documents itself and a screen that ignores it.
- 5 · Confirm every image passes four questions. Direction: does it say something this brief asked for. Brand fit: could a competitor use it unchanged. Rights: what licence or terms cover it. Provenance: where is that recorded, and can you find it in six months. Any "probably fine" is a no.
- 6 · Score gate 1 and write the number down. Not "looks clean". The number, and which check was last to move.
- 7 · Gate 2, out loud, to another human. Name the idea in one sentence. Then point at the loudest thing on screen and say whether it is the thing that matters to the user. If those two answers disagree, you have a design change to make and the score will not help you find it.
Self-studyWhy the review runs on the built screen3 min read▶
A mock is a claim. A built screen is a fact, and the two diverge in predictable ways. Defaults leak in: line heights, focus rings, disabled states and placeholder colours arrive from the framework rather than your token set, and none of them were reviewed. Real content is longer than sample content: a meeting title that wrapped to two lines in production was one line in the mock, and the hierarchy you designed quietly inverted. States appear that no one drew, the moment data is real. And the lab measures rendered pixels, which is the honest reason to point it at the build - contrast from actual computed colours, spacing from actual computed values, hue families from what the browser painted. If you can only review one of the two, review the build.
Pass gate 1, then answer gate 2 out loud ★ 14 min · everyone runs it
The lab below starts where your feature should: all five levers on, 100 out of 100. So there is only one thing left to do with it, and it is the thing that happens in every real ship review at the last minute. Press the anti-lever once. Feel the 19 points that "can we add a colour for it?" costs when it arrives after the work is done. Then turn it off, get back to 100, and answer gate 2 with your mouth rather than your mouse.
Start at 100. Read all five rows once so you know what a clean screen looks like in the scorecard, not just on the screen.
Press Add colour. Score drops to 81. Name the three defects before you read them: a fourth hue family, two off-grid paddings, and a yellow highlight at 1.5:1.
Say the stakeholder sentence out loud: "that badge cost us a hue family, two grid values and one accessibility failure." Ninety seconds, no argument.
Turn it off. Back to 100. Now stop looking at the score and look at the screen. Name the idea in one sentence, out loud, to someone.
Point at the loudest thing on screen. Is it the thing that matters to the user, or is it the thing that was easiest to make loud? That answer is your capstone grade.
And the scoreboard for the whole track, one last time: 17 → 32 → 46 → 66 → 86 → 100. Each rung was a session, each session was one lever, and the last row is the instinct that undoes the lot.
The anti-lever almost always arrives at the end, from someone senior, with good intentions. That is what makes it expensive - the work is finished, the meeting is nearly over, and "can we add a colour for it" sounds like a small ask. The counter-move is not refusal and it is not a lecture about hue families. It is one question: "yes, if it means something. What state or category is it encoding?" Half the time the answer is nothing and the request dissolves. The other half, you have just found a genuine gap in the token set, which is a good outcome and worth the extra week.
Where every session sits in the loop 4 min live
This is the map from b1, filled in. Five steps across the top, and under each one the sessions and artifacts that serve it. Read the column widths as a warning: the tools are fastest in the middle, and the two ends - the brief and the judgement - are where the whole track spent its time, because that is where the value went when generation got cheap.
What to do with the work 7 min live
A feature that passes both gates still has to be presented, kept and learned from. Three habits carry more weight than they look like they should: the order you present in, the file you keep, and the one retrospective question you are tempted to skip.
LivePresent in this order: decision, idea, evidence4 min▶
Most designers present in exactly the wrong order - evidence first, because it is the safest, then the idea, then maybe the decision if there is time. Invert it.
- First, the decision the design serves. "People hesitate before sending an AI summary to their team, and that hesitation is where we lose the share." One sentence, in the room's language, about a real thing.
- Second, the idea. "So the screen makes the machine's claim obvious and the correction effortless." This is the sentence from gate 2. If you cannot say it here, you did not pass.
- Third, the evidence that nothing is broken. The 100, the five rows, the states, the tokens, the rights. This part is short, because it is the part nobody argues with.
The reason for the order is that evidence-first invites a review of your craft, while decision-first invites a review of the product. You want the second conversation. Craft is your job; the product is theirs, and they will engage with it.
LiveKeep the rejected-options file3 min▶
When generation is cheap, the finished screen stops being evidence of anything. Anyone can produce a plausible screen now, which means the artifact that demonstrates your value is no longer the output - it is the record of what you turned down and why.
- In reviews it pre-empts the whole "did you consider" round, because you did, in writing, with a reason.
- In portfolios and interviews it is the only part of an AI-assisted case study that is unfakeable. A polished final screen proves you have a subscription.
- Six months later it stops the team re-litigating a settled decision from memory, which is the most expensive kind of meeting.
- Keep it cheap. A thumbnail, one line on what it did well, one line on why it lost. Anything heavier will not survive a busy week.
Self-studyThe honest retrospective, two questions3 min read▶
Do this alone, in writing, before the next project starts, and answer both honestly rather than usefully.
- Which parts did the tools genuinely accelerate? Be specific and be willing to find less than you expected. Exploration volume in b3 and first-draft screens in b4 are the usual honest answers. Briefing, critique and specification usually got no faster, and sometimes got slower because there was more output to judge.
- Where did you nearly let a plausible option through? This is the question that improves you. Every AI-assisted project has at least one moment where something looked finished, felt fine, and was actually wrong - a missing state, a borrowed concept, a colour that meant nothing, copy that hedged. Find the moment. Name what caught it, or name what nearly did not.
The second answer is the one to carry into the next project, because plausibility is the specific new risk of this way of working. Bad output was always easy to reject. Plausible output is not, and no score will flag it for you.
Four things that outlive this track ◐ ongoing
- Run the full ship review on one real feature at work - not a Cadence exercise, something with users. All seven steps, on the built screen, including gate 2 out loud to another person. Write down the score and the sentence.
- Install the five-check script as a team habit. Paste it into your review template, run it in front of people for a month, and stop explaining it. A standard becomes a standard when someone else runs it without you.
- Redo one old screen and record the before and after scores. Two numbers and a screenshot pair is the most persuasive artifact you will ever have in a design conversation, and it takes an afternoon.
- Choose the next thing to learn. If you now have to set a standard for other people rather than just meet one, the leader track is where that lives: a2 - taste is the moat for the argument, and a6 - rollout and quality for the ritual, the guardrails and the twelve-month plan.
Official sources covered
This capstone reuses the standards and practices the track already taught, and adds no new vendor claims. The normative accessibility text lives with W3C and the token format with the Design Tokens Community Group; both are linked from the sessions that introduced them. Certificates and tool training stay with the official providers. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · What are the two gates that decide whether the Cadence feature ships?
Gate 1 is measurable and fast, and the lab scores it. Gate 2 is judgement and only you can score it. Passing gate 1 alone gets you a competent, forgettable screen, which is why this session treats gate 2 as the real exam.
2 · A finished screen sits at 100. Someone asks for a colour. What does the anti-lever cost, and why?
100 drops to 81 because decoration rarely breaks one thing at a time. Hierarchy and type scale hold, which is the useful lesson: structure survives decoration, colour decisions do not. The counter-move is "yes, if it encodes something".
3 · Your feature scores 100. What does that number not prove?
A 100 means nothing is measurably broken on the screen you scored. Concept, emphasis, states and brand fit are all invisible to it - and a disciplined AI workflow produces perfectly clean, entirely forgettable screens by default.