Name the actions in the user's verbs
Tags: naming, affordances, agents
Look at the buttons in almost any generative product and they describe the model: Generate. Summarise. Rewrite. Expand. Ask AI. Every one is accurate about the mechanism, and every one is silent about the job the person arrived to do.
The team's vocabulary becomes the label
This happens for an understandable reason. The operations are the vocabulary the team works in all day — the prompt summarises, the pipeline rewrites, the endpoint generates. So when it is time to label the control, the operation is the word to hand.
But nobody opens a product wanting to summarise. They want to catch up on a thread before a meeting. They want to reply to a parent before the bell. They want to turn a page of notes into something they can hand out.
An action named for the operation makes the user translate their goal into your mechanism before they can begin — work out that "catch up" means "summarise", that "make this simpler for my class" means "rewrite" — and that translation is exactly the step where people hesitate, guess, or leave.
The label is doing recognition, not description
The operation underneath can be identical. That is the point. Renaming the action does not change what the model does; it changes what the control is for.
A description tells the user what will happen mechanically. A recognisable label tells them this is the thing you came for. The second is what gets clicked, because it matches a goal the person already holds rather than asking them to form a new one.
A test that holds up surprisingly well: would the user say this word aloud about their day?
- Nobody says they summarised. They say they caught up.
- Nobody says they generated a document. They say they wrote the proposal.
- Nobody says they rewrote with simpler vocabulary. They say they made it work for Year 4.
Where the operation word fails that test, it is the team's vocabulary, not the user's.
Why this matters more for generative products
Traditional software had the same temptation and mostly resisted it, because its operations were narrow — Save, Print, Send are both the mechanism and the goal. A generative model is different: one operation serves dozens of goals. "Rewrite" is how you shorten a message, formalise it, translate its register, and adapt it for a child, all at once.
So a single operation-named button hides a dozen recognisable actions behind one unrecognisable one. Splitting it by goal is not cosmetic. It is how a user discovers that the capability they need exists at all.
This extends to agents, where the tools an agent exposes are an interface too. A tool called update_record is legible to the model and opaque to the person approving it; reschedule the delivery is legible to both.
When the operation name is right
- For expert users whose job is the operation. An editor genuinely does summarise; a data team genuinely does classify. When the operation is the goal, name it.
- When the goals are too many to enumerate. A general-purpose surface cannot list every outcome, and a few goal-named actions plus an open input beats a hundred buttons.
- In the system underneath. Keep the operation vocabulary in code, logs and tool definitions. The rename is for the surface people read.
Grounded in
Poppy's actions are named for the work teachers actually do — plan a lesson, write to parents, build a quiz, adapt content to a reading level — rather than for anything the model does to text.
The last one is the clearest case. Adapt content to a reading level and rewrite with simpler vocabulary can be the same model call. Only one of them is something a teacher says about their afternoon, and only one of them is recognised in the two seconds a teacher has between one class leaving and the next arriving.
Anti-patterns
- The sparkle button. A single "✨ AI" control that does something unspecified. It names the technology and nothing else.
- Operation verbs everywhere. Generate, Summarise, Rewrite — accurate, and a translation exercise for every user.
- One button hiding many goals. "Rewrite" standing in for shorten, formalise, simplify and translate, none of which anyone can find.
- Agent tools named for the database. Legible to the model, opaque to the person approving its actions.
- Renaming without changing the output. A goal-named action that produces generic output has made a promise the result does not keep.
The smallest version worth building
List every action label in the product. Next to each, write the sentence a user would actually say about why they wanted it. Wherever those two disagree, the sentence is the better label.
That is an afternoon of copy, it touches no model code, and it is usually the cheapest adoption improvement available.
Related patterns
- Capability before the cursor — which actions to show before the user types; this is what to call them.
- Wizard or conversation — goal-named actions are often the entry points to a structured flow rather than a chat.
- Declare the inputs before the run — the same legibility requirement for what an agent needs, rather than what it does.