Project
Strunk
A microcopy management product that treats product language as infrastructure, keeping UX writing consistent across an entire platform.
- Client
- QikServe / Access Group
- Timeframe
- 2023
Named after the right book
Strunk is a microcopy management tool, named after Strunk and White's Elements of Style, which tells you most of what you need to know about its temperament. It began as an internal tool at QikServe and was later rebuilt for the Access estate, and it exists because product language turned out to be the least managed material on the entire platform.
Its job is unglamorous and constant: manage the labels, prompts, errors and guidance that make an interface usable, across many products and many surfaces, so the platform speaks with one voice no matter which team shipped the screen.
Language drift is a platform bug
On a platform with twenty-plus products, language drifts the way untended code does. One action ships under three names. Error messages contradict each other. The same setting is a preference in one product and an option in another, and tone fragments between products written years apart by people who never met.
The cost is real but diffuse, which is exactly why nobody owns it. Guests hesitate, support tickets repeat themselves, translators quote for the same string five times, and brand erodes one inconsistent button at a time. Drift never appears on a roadmap because it never broke anything on any single day. It just makes everything slightly worse, permanently.
What Strunk does
Strunk treats copy as a managed system rather than a scatter of strings across code and design files.
- A governed copy library with structured keys, so every string has one home and one owner
- Review workflow, so language changes get the same scrutiny as design changes
- Export into product surfaces, so the approved string is the shipped string, with no retyping in between
- Structure that scales with the platform instead of collapsing around product number twelve
Words are infrastructure. Treat them with the same discipline as a design system and they stop drifting.
Two lives
The QikServe version proved the idea on one product family. The Access rebuild was the real test: could the model survive an estate of 300-plus features without turning into bureaucracy? It could, mostly because we kept the rules few and the tooling fast. Governance that slows a team down gets routed around, however correct it is.
Rebuilding also sharpened the model. The second version assumed multiple products, multiple tones and shared strings from the first day, rather than having them bolted on later, and it sat beside the Evo design system as the language half of the same idea.
Team and credits
Strunk was small enough to feel personal and shared enough to survive me moving on.
- Conceived and designed by me
- Built with platform engineering at QikServe, then rebuilt with engineering teams for the Access estate
- Product teams across the portfolio, who adopted the library and contributed the awkward edge cases that improved it
- The design team, who kept the tone rules alive in daily work
What it taught me
Content needs systems thinking as much as components do, and the same moves work: a single source of truth, light governance, and a structure other teams can adopt without asking permission first. Once writing became infrastructure, arguing for its quality stopped being a matter of taste.
It also taught me that naming a tool after a style guide sets a useful standard. Strunk had to be as clear and economical as the book it borrowed from, or the joke would have been on us. Omit needless words turned out to be a decent product strategy as well as a writing rule.