Design systems / Content strategy
2024 / Anonymized case study
Content design system for an enterprise app suite
A portfolio of enterprise tools had one design system and dozens of product dialects. I created the content patterns that helped teams ship with a shared language.
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
Adoption needed practical proof.
55+
apps
20%
guide adoption
15%
fewer test issues
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 so teams could adopt it through the broader design system.
Outcome
Impact signals
- Standardized content guidance across 55+ enterprise applications.
- Made the UX writing guide easier for product teams to apply without a writer in every review.
- Created reusable review criteria for terminology, action labels, errors, empty states, and settings.
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