Turning 500+ error messages into one system

The product

Whatfix is a B2B digital adoption platform: in-app guidance and self-help that live on top of other companies' software. Because that guidance surfaces inside someone else's product, the words carry most of the load, never more so than when something fails. For more information, see www.whatfix.com

The chair

I came into product design through writing, and my job then was reviewing copy across other designers' features. That review seat is a vantage: you see the whole product's surface at once, not one screen at a time. It's how I caught the same failure speaking in a different voice on every feature, invisible to any single team, obvious from where I sat. From that chair it wasn't a copy problem. It was a systems problem wearing copy's clothes.

Context

At Whatfix, a B2B SaaS platform for digital adoption, I was a UX writer reviewing copy across features owned by different designers and teams. Errors were written feature by feature, so the product carried hundreds of one-off messages with no shared logic, and most never told users what happened, why, or what to do next. For a platform whose whole promise is reducing user confusion, that was the core value working against itself.

No one had scoped it, because users rarely complain about error copy. They just quietly fail. Reviewing across all that work is what made the inconsistency visible to me when it was invisible to any single feature team. It wasn't assigned. I pitched the fix to the Head of Design with screenshots, framed as product quality, not cleanup. Greenlit on the spot.

How I checked it was real, not cosmetic

Engineering handed me a markdown export of every error string. It was dirty, full of stale messages that no longer shipped. Instead of editing the export, I walked the entire product by hand, verifying each message in context: where it appears, whether it still fires, whether its guidance is even true. That walk is the decision that turned a copy audit into a product audit. I wasn't cleaning up wording, I was auditing which failures the product actually surfaced and whether each one told the user anything useful.

What I changed: one framework, engineered to spread

A model is only useful if every message actually follows it, so the real work was making it scale instead of sitting in a doc.

• 1I worked with engineering to run an automated find-and-replace across the codebase (legacy message to standardized version), plus a formula-driven sheet so future messages generate to spec.
• 2I engineered adoption where it actually happens: I componentized the messages in Figma, where designers already worked. Some adopted the components and came to me only for final review; for the ones who didn't, I turned my own workflow into a gate, use the component first, then come to me, and demoed them hands-on so designers became capable, not just compliant.

What I carry forward

You don't drive adoption of a system by telling people to use it. You meet them in the tool they already live in, make the standard the path of least resistance, and gate the ungated route. Adoption is behavioral engineering, not documentation quality.

Realizing that content problems are usually distribution problems is the thread that pulled me from writing into design. The same instinct as asking "what is this copy for?", scaled to "how does this system travel?"