Member-only story
How to avoid “UX content by committee” with acceptance criteria
Tell me you’re a Product-Manager-turned-Content-Designer without telling me directly, right?
Whether you’re a professional UX Writer or a Designer responsible for your own interface text, there’s little that’s more infuriating in professional life than “copy by committee”. Obviously, everyone can write, which means that all sorts of people may begin to leave all manner of suggestions and tips and requests on your copy in your Figma files.
Of course, not everyone should write, and while suggestions and feedback can be helpful, it can often turn into a game of trying to appease people who are giving feedback based on opinion rather than UX needs.
Believe me, I’ve been in situations before where I’ve received 16 comments from 12 people representing 5 different competencies where it seems the only solution is to find words that don’t currently exist in the English language.
Back in the day as a Product Manager…
I’m sure you’ve seen Jira tickets with acceptance criteria before. In case not, they’re requirements the work done needs to meet for the ticket to count as “done”, and usually set out essential functions and behaviours that need to be technically possible for the user to accomplish.
When I was an eager young Product Manager, I’d sometimes make requests for things outside of the acceptance criteria, and the engineering Engineering Manager would react by sending me a passive-aggressive gif of a dog rolling its eyes, before saying “We agreed and signed off on the acceptance criteria during sprint planning, you can’t add to them now.”
So, as a UX Writer, I make use of acceptance criteria in my own work. When I’m working on interface copy that I know is going to be tricky and get a lot of feedback, before I draft anything, I define acceptance criteria.
Acceptance criteria for UX Writers
As with acceptance criteria on a Jira ticket, the idea here is to list everything that a string needs to accomplish —…
