NO. CMS–01
TYPE: UX Case Study
STATUS: Design Complete
Everyone had a different tool for the same problem.
A ground-up redesign of an internal complaint & ticket management system — replacing a pile of overlapping tools with one shared way to raise, route, approve, and close an issue, for every team that touches one.
Role
UX Designer — research through structure & screen design
Timeline
Discovery → Synthesis → Structure → Validation
Platform
Web · Desktop + mobile-responsive
Organization
Multi-team enterprise · internal tool (NDA)
3 ticket types
8 user groups
5 permission tiers
2 rounds of research
8 feedback themes
Context
What this system needed to do
CMS is the tool a company's teams use to raise, route, and close out problems — like the company's own internal help desk. Everything runs through one of three ticket types.
(01)
Service Request
A straightforward ask for data, access, or information.
(02)
Incident Ticket
Something broken in a business application.
(03)
Change Request
A request for something new, needing manager / business sign-off.
Business Analysts
Business Users & Managers
Tech Leads
Developers
Program Managers
QAs
IT Employees
Support Team
The old way
Nobody owned the whole process. There was no single source of truth, screenshots couldn't be attached, notifications reached the wrong people, and closed tickets kept no record of when or how they were resolved. Teams stitched the work together across a pile of tools:
Jira
Microsoft Teams & Planner
Excel trackers
Freshworks
Plain email
IT Services portal
Build, not buy
Plenty of ticketing tools already exist. Here's why none of them quite fit.
The org had already tried Jira, Freshworks, Zendesk, ServiceNow, and Microsoft Planner — glued together with Excel and email. The tools aren't bad. They just weren't shaped around this org's approval chain, three ticket types, or eight internal roles.
What we needed
An approval chain matching how the business works
Role-based access across 8 groups
One shared view across 3 ticket types
Licensing cost at scale
Ease of use for non-technical staff
This system
✓
Built for it
✓
Built for it
✓
Built for it
✓
Built for it
✓
Built for it
This isn't a claim that generic tools are worse in general — they simply weren't shaped for this org's specific structure.
Research & discovery
Two rounds of interviews, sorted into eight themes
First we spoke with the people who create and process tickets, then with the program managers overseeing them. Everything they said was sorted into named themes.
03
Ease of Use & Accessibility
“Why does this take five clicks?”
04
Support & Knowledge Management
“Someone solved this before — where's the record?”
07
Resolver Collaboration & Assignment
“Who's actually working this?”
08
Workflow & Approval Management
“This has sat with a manager for a week.”
01
Ticket Tracking & Visibility
“Where is this ticket, and who has it?”
02
Workflow & Process Clarity
“What happens after I hit submit?”
05
Performance & Monitoring
“How is my team actually doing?”
06
Integration & Contextual Support
“Why am I explaining this over email again?”
“
I can't attach a screenshot when writing up an issue.
“
Every escalation means explaining the backstory again.
“
I get asked for feedback on tickets that were never mine.
“
There's no reliable way to search by ticket number.
“
A ticket says closed — nobody recorded when or how.
Persona · Creator group
The Business Analyst
A composite drawn from interviews. She bridges business needs and technology — turning colleagues' requests into trackable tickets.
Composite · not one real person
Pain points
·
Struggles to track ticket details
·
Info isn't logically organized
·
Helping others eats her own time
·
Too many irrelevant notifications
Goals
·
Faster, simpler ticket raising
·
Easy search and traceability
·
Less IT dependency for permissions
·
Timely updates
Needs from product
·
Simple interface
·
Real-time status alerts
·
Full audit trail
Also wants
·
Exportable reports
·
Modern tech without odd limits
Synthesis
People across eight roles need one shared system to raise, route, approve, and close three very different kinds of requests — with enough visibility that both individual processors and leadership can act before something falls through the cracks.
What the system had to achieve
✓
Real-time visibility into status, ownership & history
✓
A transparent staged workflow with escalation
✓
The next action always surfaced
✓
Safe collaboration via comments & notifications
✓
Dashboards and exportable reports
✓
Automatic role-based permissions
In scope vs. next phase
In scope
— Full lifecycle for all 3 ticket types
— 5-tier permission model across 8 groups
— Dashboard, reporting & notifications
— Search, help & support
Out of scope (this phase)
— Automated / AI-assisted routing
— Customer-facing self-service knowledge base
— Predictive analytics
Structure
Information architecture & system mapping
a
Permission tiers
Eight groups touching one ticket needed five stacking access tiers — reusable levels of access, not per-person settings.
Resolver
Does the fix — status changes, attachments, notes, replies.
Data Analyzer
Sees metrics, dashboards & reports without acting on tickets.
Common
Create, edit, view, notes, approval request — everyone's baseline.
Processor
Re-types, assigns to a resolver, updates.
Approver
Approves / rejects, mainly change requests.
Validator
Double-checks a resolver's fix before closing.
Tech Leads
Creator
Processor
Viewer
Developers
Creator
Viewer
Resolver
Program Managers
Creator
Processor
Viewer
Approver
Data Analyzer
Business Analysts
Creator
Viewer
Business Users & Managers
Creator
Viewer
Approver
Data Analyzer
QAs
Creator
Viewer
Validator
IT Employees
Creator
Viewer
Approver
Data Analyzer
Support Team
The safety net — a mix of everything
b
Ticket lifecycle
1
Creation
Someone hits a wall and logs it — what, which application, which business area.
2
Processing
Routed to the right team based on severity.
3
Approval
Change requests pause here for sign-off.
only when required
4
Resolution
The resolver, usually a developer, does the fix.
5
Closure
Creator or system confirms and closes it.
c
Site map / information architecture
CMS Ticketing Platform
Main navigation
01
Dashboard
The home base for every role.
›
My tickets summary
›
SLA / at-risk widget
›
Quick “+ New ticket” action
02
Ticket Management
The core of the product.
›
Ticket Overview queue
›
Create Ticket adaptive form
›
Ticket Detail (conversation / attachments / timeline / properties)
›
Parent & child linked tickets
03
Approvals
Sign-off, in one place.
›
Approval queue
›
Approve / reject action
›
Approval history
04
Reports & Analytics
How the team is doing.
›
Ticket metrics dashboard
›
Team workload view
›
Export
05
Notifications
The right people, only.
›
In-app alerts
›
Email digest
›
Preferences
06
Global Search
Find any ticket, fast.
›
By ticket number
›
By title / owner
›
Recent searches
07
Help & Support
Guidance in the flow.
›
Guides & FAQs
›
Contact support
›
Product tips
08
Access & Permissions
role-gated
Who can do what.
›
Role assignment
›
Tier mapping
›
User group management
09
Login & Account
Getting in.
›
Sign in
›
Password reset
›
Profile & role display
d
Card-sort output
The categories that emerged from sorting research feedback:
Dashboard
Help & Support
Reports & Analytics
Integrations
Progress Stages
Usability & Accessibility
Search & Findability
Access & Permissions
Ticket Management
Notifications
From feedback to features
Turning grouped feedback into what the product does
Draft — grouped by intent
Design Language
Consistent branding, jargon-free UX copy.
System Scalability
Backend built to grow, reusable components.
UI Design
Intuitive layout surfacing key info first.
Technical Features
Comments, replies, email previews, linked tickets, a real text editor.
Final — what the product does
Login & Dashboard
One home base for every role.
Ticket Management
Create / edit / view with parent & child linking.
Reports & Ticket Metrics
Exportable, shareable, always current.
Notifications
In-app + email, right people only.
Global Search
Find a ticket by number, every time.
Help & Support
Guidance built into the flow.
Key decisions
Four calls that shaped the system
(01)
One adaptive ticket flow, not three
The same shell across Service / Incident / Change, with type-specific fields.
Why · The same people process all three types daily, so one mental model beats three.
(03)
Findability came before decoration
Global search and filters prioritized over visual polish.
Why · “I can't find my ticket” was the single most repeated complaint.
(02)
Permission tiers, not per-person settings
Five reusable tiers instead of individual toggles.
Why · Tiers scale — new roles just map onto existing tiers.
(04)
One detail view for everything
Conversation, files, and history together — not separate tabs on separate pages.
Why · People were re-explaining context over email because nothing kept the full story in one place.
Task flow
Completing one ticket, start to finish
This shows the system's logic, not specific screens — every branch a ticket can take, for any type.
Start / end
Step
Decision
Someone hits a problem
Log in
Click “+ New Ticket”
Choose ticket type
Fill in details & attach files
Submit
Is this a Change Request?
Yes
routes to an Approver first
No
skips straight to processing
Did the Approver approve it?
Yes
continues
No
sent back to creator with notes → loops to “fill in details”
Processor assigns a Resolver
Resolver works the ticket & updates status
Does this type need a Validator's check?
Yes
Validator checks the fix
No
skips ahead
Ticket marked Resolved, creator notified
Creator reviews and closes
Ticket closed
Footnote: the two decision points map directly to the Approver and Validator permission tiers from the research.
User flow
Three real journeys through the product
Where the task flow shows the system's logic, this shows a specific person's screen-by-screen path — from opening the app to being done.
Creator
Reporting a problem
Trigger
Hits a wall in a business application
Outcome
Issue logged and tracked
Login
Dashboard
Create Ticket
type + details + files
Ticket Detail
confirmation view
Track it
Creator
Checking on a ticket already raised
Trigger
Wants to know if anything's moved
Outcome
Status confirmed, no messages sent
Login
Ticket Overview
“my tickets” tab
Ticket Detail
status + conversation
Close
if resolved
Processor / Program Manager
Reporting on tickets
Trigger
Needs to show leadership how the team's doing
A shareable report, no manual Excel work
Login
Dashboard
Reports & Analytics
Apply Filters
Export
Inside the product
Key screens, brought to life
Illustrative mockups built to demonstrate structure — not final production art. All data below is dummy data.
Outcome
Where it landed — honestly
Done
Login
Done
View ticket details
Done
Dashboard
Done
Notifications
Done
Ticket list
Done
Create / edit ticket
Done
Global search
In progress
Help & Support
Designed outcomes
tagged, not measured
Faster triage
At-a-glance status and priority let processors sort quickly.
Less back-and-forth
Type-adaptive fields collect the right details up front.
Fewer “where's my ticket” asks
Search plus a single detail view answer it directly.
Leadership visibility
Dashboards and exports replace manual reporting.
Honest framing
This system was designed and validated against research and task flows, but it is not yet measured in live production. Worth tracking post-launch:
Time-to-first-response
% resolved within SLA by type
Reopen rate
Satisfaction over the first two quarters
Business case
Why it holds up over time
Feasibility
›
Reused components meant new screens assembled fast.
›
Phased delivery — core flows first, Help & Support followed.
›
Low training cost, since it matches roles people already hold.
Scalability
›
Permission tiers mean new roles map on without a redesign.
›
The information architecture has room for new modules.
›
One system company-wide, with no added per-seat licensing as headcount grows.
Reflection & next steps
What I'd carry forward
Worked
Running the same feedback-mapping process on every stakeholder surfaced role-specific needs a single-pass synthesis would have smoothed over.
Next steps
Finish Help & Support, run usability testing, instrument the shipped product, and check designed outcomes against real usage.
I'd change
Add real usability testing with actual Creators and Processors before finalizing screens — not just stakeholder review.
One learning
Designing one adaptive shell for three ticket types took longer upfront but kept the system learnable — worth doing again for similar multi-entity systems.
Ticket closed
Case study built from the UX research, role mapping, system structure, and feature design work behind the CMS ticketing platform. Screens in the “Inside the Product” section are illustrative mockups built to demonstrate structure — not final production art or measured results.