Lesson 2 of 5 · 46 min

Naming & terminology

Naming is the highest-leverage, lowest-cost AI pattern work — and the foundation an AI design system has to fix first. How Microsoft, Google, and Adobe standardised their AI vocabularies, the three-layer naming taxonomy (capability · model family · trust tier), why names are now read by agents as well as humans, and the failure modes of ad-hoc naming.

Lesson 2 · Vocabulary

Naming & terminology for AI

The cheapest leverage you will ever get

Naming feels like a copy decision, so designers hand it off or bikeshed it late. That is backwards. Into Design Systems’ rule for any AI-ready system is to “fix your foundations first — naming conventions, token structure, and component descriptions” before you expose them to AI generation. And Brad Frost’s finding is that AI code generation works best on consistent conventions — so the names your system uses are now leveraged by both humans and the agents reading your design system. Naming is the highest-leverage, lowest-cost pattern work in the whole track: it costs a spreadsheet and a decision, and it determines whether users (and tools) can tell your AI features apart at all.
Why naming is a pattern and not just words: a name is the strongest signal a user gets about what an AI feature is, how much to trust it, and who is acting. NN/g’s caution cuts the other way too — names are branding decisions, and you cannot rely on a name alone to convey capability. So the discipline is to use names systematically: pick a small set of prefixes that each carry one meaning (capability, model family, or trust tier), and refuse ad-hoc naming everywhere else. Get this right and a user who learns one name (“Copilot assists,” “Studio generates”) transfers that understanding across every surface.
UX: Designing for CopilotMicrosoft (DIS214H)

How the big three actually standardised

Look at what the three companies that ship AI at the largest scale converged on, because it is a master class in naming-as-pattern. Microsoft normalized one capability word — Copilot — across Office, GitHub, Power Platform, and Security, so “Copilot” reliably means “an assistant that helps you in this surface.” Google layered a capability prefix — Magic (Magic Compose, Magic Editor) — for in-product generative experiences, and gave the underlying model family a single mononym, Gemini. Adobe anchored generative media around Firefly, kept classic ML under Sensei, and named the provenance layer Content Credentials. Three companies, the same move: a stable capability prefix, a model-family mononym, and (for Adobe) an explicit trust/provenance name.
code
1WHAT THE BIG THREE STANDARDISED ON23  vendor     capability word     model family   provenance / trust name4  --------   -----------------   ------------   -----------------------------5  Microsoft  Copilot (Office,    Copilot /      AI badge, Throw & Catch6             GitHub, Security)   Designer7  Google     Magic (Compose,     Gemini         (in-product signaling /8             Editor)                            settings)9  Adobe      Firefly             Firefly        Content Credentials (C2PA),10             (Sensei = classic                  Content Authenticity app11             ML)1213  The pattern: ONE capability prefix + ONE model mononym + an explicit14  trust/provenance name. Reuse them everywhere; refuse ad-hoc naming.
Two verbatim anchors worth quoting in a review. Google positions Magic Compose as an “experimental feature within Google Messages” that uses “Google’s generative AI technology” to “craft stylized, suggested responses” — notice the name does triple duty (capability = Magic, surface = Messages, mode = suggested). Microsoft frames 365 Copilot as a unified, “AI-forward design system.” Interview angle. When asked “how would you name a new AI feature,” the strong answer references this convergence — capability prefix, model mononym, trust tier — instead of proposing a clever one-off product name.

The three-layer naming taxonomy

Treat every AI name as up to three stacked layers, and decide each layer deliberately:
  1. 01Capability — what it does, in plain-English verbs: Copilot (assists), Studio/Magic (generates), Agent (acts autonomously). This is the layer users reason about most; keep it to two or three words across the whole product.
  2. 02Model family — a single mononym for the underlying model: Gemini, Firefly, or your internal model name. One name, reused, so “powered by X” is legible and versioning has a stable anchor.
  3. 03Trust tier — the strongest signal of provenance and risk: Suggested, Draft, Executed, Inspectable. This is where naming meets the provenance domain (next lesson) — the word tells the user how much to verify.
The operational rule: pick your prefix family once, reuse it across every surface, and refuse ad-hoc naming. A feature is then named by composing layers — “Magic Compose” (capability + surface), “Suggested reply” (trust tier + object), “Firefly Generative Fill” (model + capability). The reason this matters beyond tidiness: Brad Frost’s point that AI code generation keys off consistent conventions means your naming is now machine-read. Inconsistent names (“Smart…”, “AI…”, “Auto…”, “✨…” all meaning the same thing) confuse users and degrade the agents that consume your design system.

Case study: the “Magic” vs “AI” vs “Smart” divergence

Compare two naming philosophies. Google’s Magic prefix is experience-first — it tells the user what they get (something delightful and generated) and deliberately avoids the word “AI.” Gmail’s older Smart prefix (Smart Compose, Smart Reply) is capability-first — it signals “context-aware assist.” The risk both manage is the one UXDesign.cc documents: when “AI” gets stamped on every mundane feature, users start dismissing the label. Google’s answer is to brand the outcome (Magic) rather than the technology (AI); Microsoft’s is to brand the role (Copilot, a co-pilot, not the pilot). Both are defensible; an undifferentiated “AI everything” is not.
The failure case is concrete and common: a product where “AI Assistant,” “Smart Suggestions,” “Auto-complete,” and a “✨” menu item all refer to overlapping capabilities, named by whichever team shipped first. Users cannot build a mental model; support tickets ask “what is the difference between X and Y” (when there is none); and a later agent integration cannot map intent to feature. Interview angle. “Walk me through your process for ensuring consistency across products” is a real design-systems prompt — naming governance (a single source-of-truth glossary, a prefix policy, a review gate on new feature names) is a strong, concrete answer.
code
1NAMING GOVERNANCE GATE -- the checklist a new AI feature name must pass23  1. capability   reuse an approved prefix (Copilot/Studio/Agent)?   [y/n]4  2. model        cite the model family by its one mononym?          [y/n]5  3. trust tier   does the verb match the real blast radius?         [y/n]6                  (Suggested = confirms; Auto/Done = already happened)7  4. collision    distinct from every existing feature's meaning?    [y/n]8  5. lexicon      verbs/nouns drawn from the controlled vocabulary?  [y/n]9  6. machine      consistent enough for codegen to map intent->feature?1011  Any "no" -> back to the glossary owner, not to ship. The gate is cheap;12  un-naming a shipped "Smart/AI/Auto" soup later is not.

Terminology that travels: content & system messages

Naming is not only feature names — it is the terminology the system uses to talk about itself in microcopy, empty states, and error messages. Kontent.ai’s applied finding is that disclosure works only when it is plain-language and persistent, avoiding “overly technical or scary terms.” Shape of AI’s Disclosure pattern adds that verbs carry the load: “Summarized with AI,” “AI-edited,” “Drafted by AI” set accurate expectations far better than a generic “AI-powered.” So the terminology layer of the system needs a small controlled vocabulary of verbs (suggest, draft, summarise, generate, execute) used consistently, mapped to trust tiers. Interview angle. A portfolio piece that includes a short “AI lexicon” — the approved verbs/nouns and what each promises — signals content-design maturity that most candidates skip.

When the name extends into a whole brand system (Gemini)

At the largest scale, the model-family name anchors an entire visual language — and Google’s Gemini is the reference. The brand uses a “warm, spatial, rounded quality” built on the circle; gradients act as “context builders” with “sharp, almost opaque leading edges that diffuse at the tail” to direct attention; and motion conveys “thinking, analysis, and intelligence” so the model’s process is visible. Most instructively for this track, Gemini is deliberately “thoughtfully imperfect” — the brand openly admits the model is non-deterministic, and builds trust through “softness… clear language, and transparent signaling.” The lesson: a model-family name is not just a label, it is the hook a whole design system hangs trust cues on — so the name has to be stable enough to carry that weight.
Pick two or three naming prefixes that signal capability, model family, and trust tier — and refuse ad-hoc naming. — the convergent lesson from Microsoft (Copilot), Google (Magic + Gemini), and Adobe (Firefly + Content Credentials): names are leveraged by both humans and the agents that read your system, so consistency is the whole game.
articleBehind the design: Meet Copilot — naming, brand cues, and trust signalsMicrosoft DesignarticleAI and Design Systems — why consistent conventions matter for AI generationBrad FrostarticleEmerging best practices for disclosing AI-generated content (plain-language naming)Kontent.aiarticleThink Twice Before Adopting the AI LabelKike Peña (UX Collective)

Checkpoint

You inherit a product with “AI Assistant,” “Smart Suggestions,” “Auto-draft,” and a “✨ Enhance” menu — all overlapping capabilities named by different teams. What is the highest-leverage first fix?

ARedesign each feature’s UI to look more polished and on-brandBDefine a naming taxonomy (capability prefix · model mononym · trust-tier verb) and a governance gate, then rename to itCPick the most popular of the four names and apply it to everything
Sign up free to answer and see why

Checkpoint

A feature actually sends a calendar invite on the user’s behalf, but the team wants to label the button “Suggested time.” Why push back?

AThe label is fine — “Suggested” sounds friendlier and less intimidatingB“Suggested” should be reserved for the model family name, not an actionCThe name promises a trust tier (confirm-before-act) that contradicts the actual executed action — a trust bug
Sign up free to answer and see why

Checkpoint

An interviewer asks why Google brands generative features “Magic” instead of “AI.” What is the strongest read?

ABranding the outcome (Magic) avoids the over-labelling fatigue of stamping “AI” on everything, while still signalling something generatedB“Magic” is legally required to avoid claiming the feature uses AICIt is purely arbitrary marketing with no UX rationale
Sign up free to answer and see why

Checkpoint

Your design system will be consumed by an AI codegen tool as well as humans. How does that change your naming discipline?

AIt does not — naming is for humans; the tool reads the code, not the namesBIt raises the bar for consistency — names are now machine-read, so “Smart/AI/Auto/✨” synonyms hurt both users and the agentCYou should switch to opaque codes (feature_a, feature_b) so the tool parses them cleanly
Sign up free to answer and see why

Checkpoint

You are writing the microcopy for AI states across the product. What best reflects naming-as-pattern at the content layer?

AUse a generic “AI-powered” tag everywhere so users always know AI is involvedBVary the wording per surface so each feels bespoke and freshCUse a small controlled vocabulary of verbs (suggest, draft, summarise, generate, execute) mapped to trust tiers, applied consistently
Sign up free to answer and see why

Interview & portfolio prep

Naming questions test whether you treat vocabulary as a system and a governance problem, not a creative-writing exercise. Lead with the three-layer taxonomy and the big-three convergence; show you understand a name is a trust promise that is now machine-read. Answer each in a tight beat.
  1. 01“How would you name a new AI feature?” → compose three layers: capability prefix + model mononym + trust-tier verb; reuse the prefix family, don’t coin a one-off.
  2. 02“How did the big three standardise?” → Microsoft = Copilot (role), Google = Magic + Gemini (outcome + model), Adobe = Firefly + Content Credentials (model + provenance).
  3. 03“Why not stamp ‘AI’ on everything?” → label fatigue (UXDesign.cc); users dismiss the badge. Brand the outcome or role, scale disclosure to stakes.
  4. 04“How do you keep naming consistent across products?” → a single glossary, a prefix policy, and a review gate on new feature names — naming governance as part of the design system.
  5. 05“What makes a name a trust bug?” → when the verb mismatches the blast radius (“Suggested” on an executed action); the name promises a tier that the behaviour breaks.
  6. 06“How does AI codegen change naming?” → names are machine-read; consistent semantic conventions help the agent, synonyms (“Smart/AI/Auto/✨”) hurt it and users alike.
  7. 07“What belongs in the content/terminology layer?” → a controlled verb vocabulary (suggest/draft/summarise/generate/execute) mapped to trust tiers, plain-language and persistent.
  8. 08“What does a strong naming artifact look like in a portfolio?” → an AI lexicon: prefixes, approved verbs/nouns, and the promise each carries, plus before/after of a renaming.
Follow-ups push on governance and edge cases: “who approves a new AI feature name?”, “what do you do when marketing wants a flashy product name that breaks the taxonomy?”, “how do you name the same capability that appears at three trust tiers?” Strong answers separate the product/marketing name from the system/functional name (the taxonomy governs the latter), and resolve the trust-tier question by composing the trust-tier verb onto a stable capability prefix.

Could you propose a three-layer naming taxonomy for a product, defend it against the big-three convergence, and catch a name that is a trust bug?

New to itGetting thereConfident

Takeaways

  • Naming is the highest-leverage, lowest-cost AI pattern work — and the foundation to fix before AI generation, because names are now machine-read.
  • Use a three-layer taxonomy: capability prefix (Copilot/Magic/Agent) · model mononym (Gemini/Firefly) · trust-tier verb (Suggested/Draft/Executed).
  • The big three converged: one capability word + one model name + an explicit provenance name; reuse, refuse ad-hoc naming.
  • A name is a trust promise — the verb must match the blast radius, or it is a trust bug, not a copy nitpick.
  • At the content layer, use a small controlled vocabulary of verbs mapped to trust tiers; avoid generic “AI-powered” soup.
  • Own a naming glossary + governance gate as part of the design system, the way you own tokens and components.

Next: provenance — signalling authored vs AI-suggested vs AI-executed, the three-mode model and the patterns that make it legible.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with EnzoSign up free