Risograph print inspired by Kalina Ivanova
Why one capability with several names is an IA problem, not a branding one.
Somewhere along the way, the same idea grew multiple different names. A claim assistant in one place. A billing aid in another. A care assistant in a third. Each one was reasonable when it shipped. Each team named the thing in front of them, in the language of their own context. Nobody set out to build all of these features together. We just never stopped to notice we’d named one thing many different times.
The reflex is to treat this as a branding cleanup. Pick the best name, deprecate the rest, update the strings. Branding is the smallest part of what’s actually wrong.
The cost lands on the user, specifically the user who moves between contexts. A clinician working in care delivery in the morning and billing in the afternoon meets what is functionally the same assistant twice, wearing two names, behaving like two products. Every renamed instance is a small demand that they relearn a pattern they already knew. Multiply that across a day and the names aren’t a cosmetic problem. They’re a cognitive tax on the people least able to spare the attention.
So the argument I’ve been making internally is to lean on one pattern name and let it adapt to context rather than fragment by context. Same assistant, same mental model, different capabilities depending on where you are. The name is the promise that the thing you learned over here still works over there.
That’s why I’d file this under information architecture rather than naming. A name isn’t a label you stick on a finished feature. It’s a claim about what category the feature belongs to, and categories are how people navigate. When the names fragment, the user’s map fragments with them. Consolidating isn’t about a tidier vocabulary. It’s about giving people one model to learn instead of five, which is the same work IA always does, just at the level of words.