Words are interface 7 min live
Copy is not applied to a design. Copy is a large part of the design, and it is the part users read first, slowest and most literally. There are four places where the words carry the whole screen and a beautiful layout cannot rescue them. Labels: a button should say what happens next for the user, not what the system does internally. Empty states: what this is, why it is empty, and the one action that fills it. Errors: what happened, what it means for me, what to do now, and never a sentence that blames the user. Confirmations: what changed, and how to undo it. Get those four right and an ordinary layout feels considered. Get them wrong and no amount of spacing rhythm saves you.
LiveWhat AI is genuinely good and genuinely bad at here4 min▶
This is the clearest split in the whole track, and it is worth stating plainly before you open a model.
- Genuinely good: variants. Ask for fifteen ways to phrase an empty state at forty characters and you get fifteen usable starting points in seconds. Volume on wording is exactly the cheap step from b1.
- Genuinely good: consistency sweeps. Paste twelve of your existing strings and ask which ones break your own conventions - tense, capitalisation, person, whether buttons are verbs. It catches drift a human reviewer skims past.
- Genuinely bad: knowing which variant is true. "Your summary is ready in seconds" is a product claim. Only you know whether Cadence takes seconds, whether it always succeeds, and whether a human ever reviews it. A model will write the confident version because confident copy is the most likely copy.
- Genuinely bad: knowing what the user is feeling. The same error string reads as helpful at first use and insulting at the third failure. State of mind is context the model does not have unless you hand it over.
So the working pattern is the loop from b1, applied to sentences: you supply product truth and constraints, the model supplies range, you choose. Never the other way round.
Self-studyThe copy prompt that produces options instead of rewrites4 min read▶
The usual complaint about AI microcopy is that you ask for three options and get one sentence three times. That is a brief problem, not a model problem. A vague ask has only one likely answer, so all three answers converge on it.
"Write friendly microcopy for this screen."
"Cadence is a meeting-notes app. This is the empty state of the Shared summaries list. Product truth: summaries are generated from the meeting transcript after the meeting ends, they are always editable, and nothing is shared until the user presses Share. Voice: plain, calm, second person, no exclamation marks, sentence case. Budget: heading 32 characters max, body 90 max, one button label 18 max. User state of mind: first week, unsure whether this app did anything useful yet. Forbidden words: seamless, effortless, magic, powered, simply, just. Give me three options that differ in APPROACH, not wording - one that explains the mechanism, one that names the benefit, one that gives a single instruction. Label each approach and state what it assumes about the user."
Six things changed: product truth, voice constraints, a character budget per slot, the user's state of mind, a forbidden-words list, and an explicit demand for different approaches rather than different phrasing. The last one does most of the work. Asking a model to vary the strategy forces it off the single most likely sentence, and the labels let you argue about the approach in review instead of the adjectives.
Disclosure copy that builds trust 7 min live
Cadence has one structural problem: it puts machine-written summaries in front of humans who were not in the room. Every trust decision in the product runs through a few short strings. Five rules hold up: say what was generated and from what, so the user knows the boundary of the claim. Put the uncertainty where the user acts, not in a footer nobody scrolls to. Make correction the obvious path rather than a buried edit, because a summary the user can fix in one tap is a summary they will trust. Never imply human review that did not happen - "verified" and "checked" are words you have to earn. And avoid the two failure modes at either end: bragging, where "AI-powered" is pasted on as a feature badge, and burying, where the disclosure is written in legalese at 11px grey-on-grey.
| Disclosure moment in Cadence | What the user is actually asking | The copy job |
|---|---|---|
| A generated summary, first view | Who wrote this, and from what? | One line above the body naming the source and the mechanism: generated from the transcript of this meeting, editable. No badge, no adjectives. |
| A low-confidence transcript segment | Is this bit reliable? | Mark the segment itself, not the page. Say the audio was unclear here, and put an open-the-recording action next to the doubt so checking is one tap. |
| An unclear speaker attribution | Did that person really say that? | Never guess in a confident voice. Show the uncertainty inline, name the two candidates if you have them, and make reassigning the speaker the primary action. |
| A shared summary, seen by a recipient who was not there | Can I act on this? | The disclosure has to travel with the artifact. The recipient never saw it generated, so the shared view needs its own line naming the source, the meeting, and who shared it. |
LiveRewriting one disclosure line four ways4 min▶
Same moment, the top of a generated Cadence summary. Watch what each version promises.
"✨ AI-powered summary - intelligently verified for accuracy."
"Summary generated from this meeting's transcript. It can miss things - edit any line."
Two more versions worth having in your pocket. The buried one: a 10px grey line at the bottom of the page reading "Content on this page may be generated by automated systems in accordance with our terms". Technically present, functionally absent, and as you will see in the lab it is usually a contrast failure too. The overcorrected one: a modal on every open that makes the user acknowledge the summary might be wrong, which trains them to dismiss warnings and buys you nothing.
The good version fits in one line, is placed where the user reads before acting, and ends with the action that fixes the problem it just admitted. That last clause is the part teams leave out.
Self-studyWhere uncertainty has to live3 min read▶
The rule is not "disclose somewhere". It is disclose at the point of action. A user who is about to press Share is making a decision, and that is the only moment the caveat can change anything. The same words in a settings page, a footer, a help article or an onboarding screen three days ago have no effect on that decision.
- At the segment for a doubt about one line - inline, next to the words in question.
- At the top of the artifact for a doubt about the whole thing - above the body, before the reader forms a belief.
- At the button for a doubt that matters to a decision - in or beside the Share confirmation, where the user is committing.
- Travelling with the artifact for anything that leaves your product, because the recipient inherits the claim without the context.
And one honesty test before you ship a line: read it aloud and ask what it promises. If a reasonable person would conclude a human checked this, and no human did, the line is a defect regardless of how warm it sounds.
Pairing copy with visuals 6 min live
If you lay out first and write later, the words have to fit the boxes, and that is how a screen ends up saying "Submit" - it was the only verb that fit. Reverse it. Write the real labels first, then lay out around them, then break them on purpose. Four habits carry most of the value.
LiveFour habits that keep copy and layout honest4 min▶
- Write the labels before the layout. Real strings, not lorem and not placeholders. Then the layout is designed to fit words that exist, rather than words being trimmed to fit a layout that already shipped to Figma.
- Design for the longest plausible string and the shortest. Both ends break things. A 4-character meeting title leaves a card looking broken and empty; a 90-character one wraps to three lines and pushes your primary action below the fold. Draw both, not the comfortable middle.
- Localise-proof it. Avoid baked-in word order - a sentence assembled from fragments like "Shared" + name + "with" + count will be wrong in most languages. Avoid text inside images, which cannot be translated, cannot be selected, cannot be read by a screen reader and cannot reflow. Leave room: many languages run substantially longer than English, so a label that exactly fills its button in English will not fit.
- Check that reading order matches visual order. The order a screen reader announces things is the DOM order, not the visual arrangement. A disclosure line that sits visually above the summary but comes after it in markup is disclosed to sighted users and hidden from everyone else.
Self-studyCopy length is a hierarchy decision3 min read▶
This is the connection back to b5 that most content-design guidance skips. A two-line title is not a longer version of a one-line title - it is a different composition. It occupies more of the first read, it pushes everything below it down, it changes the ratio between the title and the next element in your type scale, and it can quietly create a second loudest thing on the screen.
- Length competes. Three lines of body copy set at 16px can out-shout a 25px heading purely by area. "One loudest thing" is about perceived weight, and weight includes how much space something takes.
- Length breaks the scale's promise. A 1.25 ratio gives you a clean step from 20px to 25px. That step is invisible when the smaller item is a paragraph and the larger one is two words.
- Length breaks the spacing rhythm. An extra wrapped line adds one line-height, not one spacing step, so a stack that sat neatly on the 8px grid stops doing so at the longest string.
So when you cut a heading from twelve words to five, you are not being terse for its own sake - you are making a hierarchy and rhythm decision that the lab can measure. Run the b5 checks on your longest-string version, not your prettiest one.
Write Cadence's words, then check them ★ 20 min · everyone runs it
Three strings, written live, then measured. You will write Cadence's empty state, its low-confidence banner, and its share-confirmation copy - and then run the lab with hierarchy, type scale, spacing and contrast on, which is 86 out of 100 on the track's ladder. Read the remaining contrast row carefully. The low-contrast metadata line is exactly where disclosure copy usually gets hidden, which makes it a copy decision failing an accessibility check rather than a colour mistake.
Empty state. Three slots: heading under 32 characters, body under 90, one button label under 18. Say what this list is, why it is empty, and the single action. No exclamation marks.
Low-confidence banner. Attach it to the segment, not the page. Name what was unclear, and put the check-the-recording action inside the banner so correction is one tap away.
Share confirmation. Two jobs in one line: name what changed and to whom, and carry the disclosure that the recipient never saw generated. Then offer Undo.
Stress the strings. Retype each one at its longest plausible length and its shortest. Note which layout decision breaks first - it is usually the button, and usually because the label grew.
Now measure. Turn on hierarchy, type scale, spacing and contrast in the lab below. Find the metadata line in the contrast rows and ask yourself where your disclosure copy would have gone.
The pattern to watch for in your own product: a disclosure line that passes legal review and fails a contrast check. It happens because the sentence is treated as a compliance artifact rather than as content, so it gets the smallest size and the palest grey on the screen - visually saying "ignore this" while the words say "this was machine-written". Both halves of that are copy decisions. Put the line at 16px in body colour above the summary and the tension disappears.
Try it yourself - this week ◐ 30-40 min total
- Take one screen in a product you work on and audit only the four places: labels, empty state, error, confirmation. Write the current string and a replacement for each, with a character budget you actually respected.
- Write the constrained copy prompt from Part 1 for one of those slots - product truth, voice, budget, state of mind, forbidden words, three different approaches. Keep the model's three options and mark which assumption each one makes about the user.
- Find one disclosure line in any product you use that either brags or buries. Rewrite it to name the source, place the uncertainty where the user acts, and end on the correction path.
- Retype your longest and shortest plausible strings into the layout and screenshot both. Bring the version that broke to b9 - the spec you write there has to name string extremes as a state.
Official sources covered
This session teaches words as design material and the disclosure problem that comes with putting machine-written text in front of people. Platform content guidelines are referenced and linked rather than reproduced - they change, and the reasoning below outlives the wording. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Cadence needs to disclose that a summary was machine-written. Where does that line belong?
Uncertainty only changes behaviour where a decision is being made. A footer is present but functionally absent, and an onboarding screen was three days ago. The line has to sit above the body before the reader forms a belief, and travel with the artifact when it is shared to someone who never saw it generated.
2 · What is the four-part pattern for error copy?
An error is a moment where the user needs a next step, not a diagnosis. "Invalid input" fails on all four counts. Technical causes and reference codes belong in a detail the user can expand, not in the first line, and "friendly" without a next step is just a cheerful dead end.
3 · Why design against the longest and shortest plausible strings rather than a typical one?
A very short title leaves a card looking broken; a very long one wraps, pushes the primary action down, adds a line-height rather than a spacing step, and can create a second loudest thing by sheer area. Expansion varies by language and by string, so there is no single safe multiplier - draw both ends and check the b5 measurements on the long one.