Two Claude skills instead of one

One tool became two, named for the words people already use.

The product

Accolade is a B2B SaaS platform for multifamily property operations - how teams run leasing and maintenance across a portfolio of communities, increasingly through AI-driven tools like automated tour scheduling and a multilingual phone assistant. Getting teams to actually adopt those tools is its own design problem. For more information, see www.accoladehq.com

The chair

I came into product design through writing, so I listen to the exact words people use to ask for work; that's a content strategist's ear. Most people build an internal AI tool by reaching for engineering questions: what does it do, how good is the output. I reach for a design question: what is this tool for, and who reaches for it? The most consequential decision here wasn't a prompt. It was where I drew the boundary between two tools, and I drew it by listening to how my teammates already talk.

Context

At Accolade I was the entire UX writing function: one person supporting my own product work plus two other PMs, across three product lines. I was the bandwidth bottleneck; PM workflows stalled waiting on me for copy. So I built tools to scale myself and let people self-serve when I was out. Self-initiated, AI-native: Claude skills, not a doc. But the interesting part isn't that I used AI. It's the design call I made with it.

The question: one tool or two?

The obvious build is a single "UX Copy" skill with a mode toggle: write-mode and review-mode behind one dropdown. I didn't build that. I split it into two separately named skills, a UX writing skill and a UX review skill, plus a third, separate support-documentation skill aimed at PMs.

How I knew where to draw the line

I didn't guess. I listened to how designers actually asked me for help. They always said "can you review my copies." They never once said "can you write my copies." That's the whole signal.

A tool named "UX review" hooks into a request they already make out loud; a tool named "UX writing" has nothing in their vocabulary to attach to, no matter how good it is. The boundary between the two tools wasn't a technical convenience; it mapped onto language people already used.

What I built

I demoed each one hands-on to its target audience: designers for writing and review, PMs for docs.

Outcome, including the part that didn't land

The UX review skill got adopted: designers now self-serve first-pass checks when I'm out, and I do the final pass. The support-docs skill is in active use by two PMs. The UX writing skill, same audience, same demo, same me, didn't get adopted; it stayed my personal tool.

That gap is the whole point: review stuck and writing didn't, in the same window, so adoption wasn't about tool quality or my experience; it was about whether the name matched a request people already made. On throughput, my own committed turnaround to PMs moved from 4–5 days to 2–3 for copy, and 1–2 days to 1 for feature naming, over about two months.

Published as "Bottleneck, no more!" on Medium

What I carry forward

Tool adoption is architected before you write a line of prompt. Most people would ship one skill with a mode parameter; I split it into two because adoption follows the user's existing language, not the tool's quality, and you can engineer that in advance by drawing tool boundaries to match how people already talk about the work.

Designers adopted by language match, PMs by competence match; same underlying rule: a tool gets picked up when it fits the model of the work already in someone's head.