NDA Notice:
This case study uses abstracted or representative examples to illustrate design approach and decision-making rather than proprietary systems or internal documentation. Public-facing work is shown for illustrative purposes only.
Role
Lead UX Designer
Product
Enterprise Design System CMS (Internal)
Timeframe
~3 sprints (balanced alongside core product responsibilities)
Collaborators:
Product Managers, Business Analysts, Developers, QA, Content Editors, Designers, Marketing Partners
Tools:
Enterprise CMS platform, design and prototyping tools, internal documentation and collaboration tools
The Problem Everyone Had Learned to Live With
When you work inside a tool long enough, you stop noticing how broken it is — or you notice, but you’ve already built the workarounds, so you stop expecting it to change.
This was a significant issue that plagued the design system’s internal CMS. I used it regularly for testing component functionality, verifying that designs rendered correctly, and checking that guidance aligned with what the system could actually produce. Over time, I began to notice what colleagues had already noticed but accepted as unchangeable: the tool had become genuinely hard to use, and no one believed the issues were significant enough to warrant fixing it.
Long, unstructured menus. Templates preloaded with modules requiring manual cleanup before real work could start. Vague error messages easy to miss and hard to act on. A field hierarchy that didn’t match the front-end layout, creating persistent confusion between design and build. None of these were dramatic failures, just accumulated friction that slows everyone down a little, every day, until it becomes background noise.
I decided to find out how deep it went.
Taking It On
This wasn’t an assigned project. I initiated it myself, scoping the work to fit within roughly three sprints alongside regular responsibilities. I recognized that the problems weren’t going to surface themselves, and the people experiencing them had already adapted. Someone needed to document the full picture, frame it in terms leadership could act on, and make the case for why this work belonged on the roadmap.
Heuristic Evaluation
I started with a self-led heuristic evaluation, structuring the audit around four areas I identified as highest risk given how the CMS was being used: discoverability, task efficiency, error recovery, and alignment between CMS structure and front-end output. The goal was to document patterns, not just individual issues, so that the case for improvement would be systemic rather than anecdotal. The evaluation confirmed patterns I’d suspected, but one issue stood out as particularly telling.
When a content author finished building a page and clicked to publish, the system would sometimes do nothing. No confirmation, no error, no signal of any kind. The only recourse was scrolling to the top of the page, finding a vague error message, then scrolling back through the entire template, making sure to check accordions, nested fields, buried configurations, to locate the problem through trial and error. It was one of the most consistent frustrations across the team, and one of the most costly. Every instance meant time lost, content potentially unpublished, and a user left to debug a system that should have guided them. It was a clear illustration of the broader pattern I was documenting: the CMS communicated poorly exactly when clear communication mattered most, and the people bearing that cost had simply stopped expecting better.
Examples of systemic usability patterns that reduce efficiency, consistency, and accessibility.
User Interviews
The audit told me what I could see, and the interviews told me what it felt like to live with it. I conducted structured one-on-one sessions across disciplines, including product managers, business analysts, developers, QA, content authors, designers, and marketing partners. I asked about workflows, friction points, and what they’d fix first.
What came back was a picture of a team that had quietly adapted to a system that wasn’t working. Their workarounds were so ingrained, that they had stopped recognizing them as workarounds. One content team member put it directly:
“It’s been so long since I actually took a look at these issues directly, and this experience has been eye opening. I just wish it would work the way we need it to from the start, instead of us having to waste time figuring out workarounds. I’m happy that someone is finally willing to listen.”
The relief that someone was actually paying attention was itself a finding. It told me something important not just about the tool, but about the organization: UX debt in internal systems tends to persist not because no one experiences it, but because no one believes raising it will lead anywhere. Part of what I was doing with this research was demonstrating that it could.
Synthesis
Five themes emerged consistently across the audit and interviews. Of these, error messaging and menu taxonomy represented the highest combined impact, affecting every user type, every workflow, and every day. I used severity and frequency of impact to prioritize the recommendations I brought to leadership, knowing that a ranked argument would be harder to dismiss than an undifferentiated list of complaints.
Making the Case
I brought my findings to our cross-functional governance group, framing it as a problem report, believing the volume of user issues would compel action. In hindsight, a business case for prioritization would have landed better. That said, I anchored the issues with productivity implications, used anonymized examples to make them concrete, and included conceptual workflow improvements to show solutions were within reach. The goal wasn’t just to surface problems, it was to make solving them feel achievable.
Stakeholders acknowledged the problems, expressed surprise at how systemic they were, and recognized the productivity implications. The conversation was substantive, but in the end the work didn’t move forward. Broader platform considerations took priority, and the improvements stayed off the roadmap.
What That Outcome Actually Means
It would be easy to frame a project that didn’t get actioned as a failure. But the impact showed up differently than expected.
Conversations about moving to a new framework had been circulating before my work began, but without a documented, cross-validated picture of what the current experience was actually costing the organization, there wasn’t enough to drive a decision. My research provided that picture. It became part of the evidence base that moved those discussions from conversation to commitment, and when the decision to rebuild the system on a more current, scalable framework was finally made, the impact reached further than any individual CMS fix would have produced.
What I would do differently in the future: Tie pain points to measurable outcomes earlier. Time wasted per task. Onboarding hours lost. Maintenance costs from workarounds. The qualitative case was strong. A quantitative frame would have made it harder to defer.
What I’d Tell Anyone Starting Similar Work
UX debt in internal tools is almost always underestimated, because the people bearing the cost have already optimized around it. Making it visible requires more than identifying problems. It requires framing them in terms that connect to outcomes the organization already cares about.
I walked away from this experience with three main takeaways:
- Remember to always pair UX findings with business impact from the start. The qualitative case I built was strong enough to generate real discussion, but not strong enough to survive competing priorities. If I had walked in with estimates of time lost per task, hours spent on workarounds, or onboarding costs attributable to CMS complexity, the conversation would have been about cost and return rather than comfort and timing. That’s a harder argument to defer.
- Longstanding inefficiencies become invisible as users adapt. Surfacing how much institutional knowledge has been quietly converted into workaround muscle memory is its own form of value.
- Unimplemented research still shapes decisions. The work didn’t land on a sprint board, but it informed a platform-level decision with longer reach than any individual CMS fix would have had. Sometimes that’s the more meaningful outcome.