Originally written Jan 2024

The AI feature needed a name. Not a product name – it was never going to appear on a press release. An internal name, the thing people would use in meetings, in documentation, and in the question "Have you tried the X yet?"

We'd been calling it "the AI assistant". Generic enough to mean anything, which meant it meant nothing. People treated it like a search feature. They typed questions into it and expected answers. That's not what it was.

"Copilot AI" changed something. The word 'copilot' implies a specific relationship – you're still flying the plane. The AI is there to assist, to surface, to flag, to suggest. Not to take the controls. Legal professionals who'd been cautious about AI automation understood Copilot in a way they didn't understand an assistant.

A name is the first piece of design. It sets the mental model before the interface does.

What a name actually does

Names are load-bearing in a way that doesn't get enough design attention.

Before anyone sees the interface, they've heard the name. They've built expectations from it. The name tells them what to try the feature for, what success looks like, and whether they should be cautious. A name that suggests automation makes legal professionals nervous. A name that suggests assistance makes them curious.

Names also travel in a way that interfaces don't. An interface lives on a screen. A name lives in conversation – in the meeting where someone says, "We used the Copilot for this", in the message to a colleague, and in the training session. A feature people can refer to by name gets talked about. A feature without a memorable name doesn't get referred to at all.

What names need to be done

Set the right expectation. A name communicates scope. Copilot says, "Assistant. Autopilot says replacement. The assistant says passively. Each creates a different mental model of what the feature will do and what the user's role is. The right expectation makes the first use intuitive. The wrong expectation makes the first use a correction exercise.

Create a stable identity. The Niland Test – the evaluation framework built for testing prompt performance against real users – became useful partly because it had a name. A named thing gets referenced, built upon, and challenged. "The Niland Test said this prompt was ready" carries more weight than "we ran some testing." Names make invisible work visible and repeatable.

Enable conversation. The Action Desk needed a name that described what it was for, not how it worked. Action Desk says: This is where you act. It doesn't say anything about the technical architecture underneath. People who'd never seen the product understood roughly what to expect from the name before they opened it.

Carry the right connotations. Words carry history. Copilot has aviation connotations – a trained second-in-command who keeps you safe, not an autopilot that replaces you. Those connotations were useful in a legal context where autonomy concerns were great. The name was doing persuasion work before the feature had to.

What bad naming creates

The inverse of a clear name is an accurate but unusable one. "AI-assisted case history view" describes the feature technically and fails as a name. Nobody refers to features by their technical description in the middle of a working day. They shorten it, make something up, or stop referring to it at all.

More damaging than the unmemorable name is the one that sets the wrong expectation. Features named for their technical capability rather than their user value position themselves as engineering achievements rather than design ones. Users who don't understand the technology feel excluded rather than helped.

The name that causes the most damage implies a scope that the feature can't fulfil. If the name says the AI will decide, but the feature only recommends, every user who trusts the name will feel underwhelmed by the reality.

A note on naming

Naming happens late in most product processes. The feature gets built, tested, and iterated – then someone asks, "What should we call this?" at the point when there's very little room to change what the feature actually does.

The more useful sequence is the reverse: agree on the name early, use it to pressure-test the scope, and let the name act as a brief for the interface. If you can't name it clearly, you probably haven't got the scope right yet.

This connects to an earlier post about terminology – the word 'instruct' revealing an entire wrong mental model in a legal workflow. Naming works at two levels: the vocabulary of a domain and the vocabulary of the product you're building inside it. Both deserve the same rigour.

A feature name is a design decision. It deserves the same rigour as any other.