A UX writing bot has to see the screenA UX writing bot has to see the screen

A copy review that cannot see the screen reviews a different thing than the one about to ship. A label that reads well in a text box can be wrong in the layout around it, because it repeats the heading above it, competes with the button beside it, or gets cut off on a small screen. The UX Writing Bot started out reading only the text typed into a thread, and the update that mattered most to me was the one that taught it to look.

What the team asks it

My team uses the bot in Slack. People ask it to review the copy in a screenshot, to draft options for a string, to check copy against the voice guide, and to answer content-design questions. Those four jobs differ in how much the bot has to know about the screen. A draft of options for a string can work from a sentence of description, a voice check needs the guide, and a copy review needs the picture, which is why the screenshot capability matters most.

Show it the screen

You drop a screenshot into a thread, @mention the bot and ask it to review the copy in the image, and it folds the picture in as context alongside whatever you type. Context changes what a review can catch: a heading and a label saying the same thing, a tooltip that restates its field, an error that sits three inches from the field it describes, a link that only makes sense beside the visual it came from, a playful tone on a screen about money. None of those show up in a pasted string, and all of them show up in a screenshot.

Where it goes wrong

The two failures I see most are that it misses context in the screenshot and that it is confident but wrong. A review of a label can ignore the state the screen is in or the step of the flow it belongs to, because a single frame does not show what came before it. The confident-but-wrong failure is the more expensive one: the bot states guidance as settled when it is not what the voice guide says, and a confident answer gets applied without anyone checking it. A bot used by a whole team multiplies that, and a rule the guide leaves vague gets filled with the most average version of the rule. A guide written for a reader that takes every sentence literally is the subject of your voice and tone guide has a new reader.

How it is evaluated

Evaluation today comes from usage and feedback in Slack: whether people keep asking, what they say when it helps, and what they say when it does not. When I announced the screenshot update I asked the team to break it and tell me what it gets right, what it fumbles and what is missing. Each of those three answers points at a different fix: what it gets right is what to protect, what it fumbles is what to tighten in the instructions, and what is missing is what to build next.

What I would add

Slack feedback tells you how the bot feels to use, and a review bot also needs a way to catch a quiet change in what it flags. My suggestion is to keep the instructions in a file under version control, date the reason for each rule, and keep a handful of screenshots with the findings you expect, so that an edit that changes what the bot catches fails a check before it reaches a designer. Keeping the screenshot with each report from the team turns every report into one of those cases. I have not set this up for the bot, and I am recommending it as the next step.