Design systems / Content strategy
2024 / Anonymized case study
Content design system for an enterprise app suite
I created UX writing standards across 55+ enterprise applications, reducing repeated content-related usability findings by 15% in workflows using the new label, error, empty-state, and settings patterns.
Visual mockups
The system had to look usable before it could be adopted.
Recreated artifacts showing the guideline surface, terminology logic, component-level examples, and review checks teams could use without a writer in every room.
Content system workspace
Action pattern
Save changes
Use when the action updates existing information, preferences, or settings.
Before
Submit
Too generic for settings, forms, and profile flows that all had different outcomes.
After
Save changes
Names the result and gives teams a reusable label for the same user job.
Usage rule
Do not introduce a new verb unless the user is doing a meaningfully different action.
Notification settings
Terminology matrix
One vocabulary across the app suite.
Project
Job / record
The shared container for related work across apps.
Settings
Configuration
User or workspace preferences that can be changed.
Save changes
Submit
A primary action that updates existing information.
Governance snapshot
The standards needed practical proof.
55+
applications covered
15%
fewer repeated content-related findings
Reusable standards
for labels, errors, empty states, and settings
Overview
What changed
This project turned scattered product language across an enterprise software portfolio into a practical content system. The work defined shared terminology, UI copy patterns, voice principles, and governance so separate applications could feel like one coherent product ecosystem.
Role
My part
- Led the content audit across a large suite of enterprise applications, documenting inconsistent labels, errors, empty states, and workflow language.
- Created UX writing guidelines, reusable content patterns, and examples that teams could apply inside a unified design system.
- Partnered with product designers, engineers, researchers, and product managers to make the system usable across different software teams.
Problem
The product moment was unclear
The company owned many enterprise applications, but the product language had grown app by app. Similar actions used different labels. Error messages varied in tone and usefulness. Teams were making copy decisions from scratch, which made the ecosystem feel fragmented and made usability testing harder to compare.
Constraints
Rules of the work
- The system had to work across mature products, newer apps, and teams with different release cycles.
- Patterns needed to be specific enough to guide writing, but flexible enough for technical workflows.
- Engineering and design teams needed examples they could implement without waiting for a writer on every screen.
Users
Who needed clarity
- Enterprise users moving between related tools to complete technical workflows.
- Product designers and engineers applying shared design-system components.
- Researchers and product partners trying to evaluate experiences with more consistent language.
Before / after
Examples in context, with the reason for each change
Design system pattern
Primary action used across forms and settings screens.
Before
Submit
After
Save changes
Error message pattern
Reusable error pattern for failed saves across enterprise tools.
Before
Save failed.
After
We couldn't save your changes. Complete the required fields, then try again.
Content decisions
The writing system underneath
Create patterns by user job, not by app
The system grouped guidance around jobs like save, review, fix, configure, and confirm so teams could reuse patterns across products.
Use Save changes for edits to existing settings. Use Create when the action makes a new object.
Normalize vocabulary across the portfolio
I documented preferred terms, avoided terms, and usage notes for recurring concepts so users did not have to relearn the same idea in each app.
Use project for the shared work container. Avoid job or record unless the object is meaningfully different.
Build governance into the system
The guide included review questions, example copy, and component-level notes so non-writers could make better decisions before content review.
Does the message tell users what happened, why it matters, and what they can do next?
Process
How I got there
- Audited labels, forms, errors, empty states, navigation, and settings copy across the application suite.
- Mapped duplicate terms and inconsistent patterns to the workflows they affected.
- Drafted UX writing principles, term guidance, and reusable patterns for common component states.
- Reviewed examples with product design, engineering, and research partners to make sure the system worked in real screens.
- Packaged the guidance as component-level rules, examples, and review checks inside the broader design system.
Outcome
Impact signals
- Standardized UX writing guidance across 55+ enterprise applications.
- Reduced repeated content-related usability findings by 15% in workflows using the new label, error, empty-state, and settings patterns.
- Created reusable review criteria for terminology, action labels, errors, empty states, and settings so teams could make stronger content decisions without a writer in every review.
- Gave Product, Design, and Engineering a shared reference for content decisions across complex enterprise workflows.
Measurement note: Repeated content-related findings were tracked from recurring issues surfaced during task-based testing and design QA on workflows that used the updated patterns. This was a content-quality signal, not a global product performance metric.
Learnings
What I would carry forward
- A content design system is only useful if teams can apply it without a writer in the room.
- Terminology is product architecture, especially across an enterprise suite.
- Governance should feel like a shortcut, not another review layer.
Next project