Enterprise UX · B2B Workflow Design
Designed to give support teams real-time SLA-risk visibility and cut the back-and-forth caused by missing ticket information — replacing a process with zero shared visibility across 1,500+ active requests.
Resolve · Ticketing Tool
⌕ Search ticket
+ New Ticket
Ticket Overview
All
1,504
New
4
On Going
23
Hold
56
Over Due
16
Resolved
49
Ticket No.
Status
Priority
Pending With
Impact
#2767686156
New
High
Emery Philips
Critical
#5109316525
On Going
Medium
Miracle Donin
Medium
#1597108744
Over Due
Low
Tiana Workman
Low
#3215187297
Hold
High
Emerson Dias
Medium
#3914973390
Resolved
Medium
Davis Curtis
Medium
PLACEHOLDER — swap for real screen
Ticket Overview — primary queue for processors
fig. 01 / dummy data
00 / Context & Role
The client runs dozens of internal business applications — ERP modules, order management tools, custom-built systems — used daily by staff across multiple business units. When something broke or needed a change, there was no standard way to report it, track it, or get it to the right person.
As the number of internal tools grew, this informal process stopped scaling. Requests fell through cracks. There was no audit trail. Leadership had zero visibility into where bottlenecks were forming.
My role
Sole UX/UI designer, end-to-end — stakeholder research through final hi-fi screens and supporting design system.
Constraints
No existing design system to inherit
Three structurally different ticket types, one coherent UI
Desktop + mobile-responsive, since PMs triage on the move
01 / Research & Discovery
Three ticket types, three different shapes of work
The first real discovery wasn't a pain point — it was realizing "tickets" weren't one thing.
Type 01
Service Request
Routine asks, lower complexity, fast resolution path.
Type 02
Incident Ticket
Something's broken. Urgency-driven, SLA-sensitive.
Type 03
Change Request
Requires manager/business approval. Effort + timeline fields.
Key insights from synthesis
Personas
The Creator
Employee · Ticket Raiser
Wants a low-friction way to report an issue without knowing internal routing logic
Needs status visibility without messaging someone directly
Wants confidence the request reached the right person
The Processor / Program Manager
Resolver · Triage Owner
Needs a prioritized queue that surfaces what's actually urgent
Needs full context without chasing the requester for details
Needs clear ownership and visibility across the whole team's load
02 / Synthesis
Goals
Reduce time-to-first-response via a prioritized, filterable queue
Surface SLA-risk tickets before anyone notices they're late
Cut back-and-forth caused by missing information, via type-specific fields
Give leadership real-time visibility into support health
Scope
Creation, triage, resolution flows for all 3 ticket types; role-based permissions; analytics dashboard; design system; desktop + mobile
Out of scope (v2): automated routing logic, AI-assisted triage, customer self-service knowledge base
Ticket lifecycle
Role & permission model
Role
Can do
Creator
Submit tickets, view own tickets, comment, close own resolved tickets
Processor
View assigned/team queue, triage, update status, request info, resolve
Program Manager
All Processor permissions + reassign across team, view team-wide dashboard
Approver
Review and approve/reject Change Requests requiring business approval
Task flows mapped end-to-end
SCENARIO 1 — CREATOR — "I want to log an issue with a business application"
Login
→
Ticket Overview
→
Create Ticket
→
Enter Details
→
Submit
SCENARIO 2 — CREATOR — "I want to check the status of my ticket"
Login
→
Ticket Overview
→
View Ticket
→
Check Details
Close Ticket
SCENARIO 3 — PROCESSOR — "I want to analyze and export the ticket report"
Login
→
Dashboard
→
Apply Filter
→
View & Export
→
Close
04 / Design Process & Key Decisions
List view over kanban for the ticket queue
Processors handle 1,500+ tickets at a time — density and fast scanning matter more than visual board navigation at this volume.
Why: A sortable table with status chips supports keyboard-driven, high-throughput triage in a way a kanban board can't once volume passes a few hundred open items.
One adaptive ticket detail panel, not three separate UIs
A consistent shell — Conversation, Attachments, Timeline — with a collapsible Properties panel whose secondary fields adapt by ticket type.
Why: Processors handle all three ticket types daily. Three separate UIs would mean relearning the interface per type; one adaptive shell keeps the mental model constant.
Tabs for ticket scope: "for me," "by me," "assigned by me"
Persistent tabs rather than one filtered list, directly reflecting how Creators and Processors think about ownership differently.
Why: Research showed "my tickets" means three different things depending on whether you created, own, or assigned the work.
Color-coded status, priority, and impact — consistent everywhere
The same red/amber/blue logic for "Critical" appears in the list view, the detail view, and the dashboard's aging table.
Why: Directly answers Insight 01 — once a processor learns what red means once, that knowledge transfers across every screen.
05 / Key Screen Walkthroughs
Where the system does its heaviest lifting
Ticket Detail — the screen processors live in
Conversation thread on the left with inline attachments. Status, priority, and impact badges sit directly under the title for instant triage. The right-hand panel adapts its fields to ticket type — shown here with Change Request fields.
Analytics Dashboard — built for Program Managers and leadership
Aging metrics cross-tabbed against business impact, root cause breakdown, and CSAT tracking — visibility that simply didn't exist in the email/spreadsheet process.
Create Ticket — adaptive form with inline file upload
Fields adapt by ticket type. Drag-and-drop file upload is built into the form directly, since most tickets in research arrived with supporting screenshots processors previously had to chase down separately.
SIGNAL BLUE
#1B5FE0
CRITICAL RED
#E8543A
PENDING AMBER
#D98E2A
RESOLVED GREEN
#16A37D
Status and priority color logic is consistent system-wide — "Critical" in the dashboard's aging table uses the same red as priority flags in the list view and badges in ticket detail, so a processor's mental model transfers across every screen.
Modal
Accordion
Pagination
Avatar
Table
Badge
Tabs
Breadcrumb
Toaster
Button
Toggle
Checkbox
Tooltip
Chips
Date/Time Picker
Drawer
Empty State
File Upload
07 / Outcomes & Impact
What this system is designed to change
Triage speed — status, priority, and impact visible at a glance, replacing full-text reading to gauge urgency
Designed outcome
SLA-risk visibility — aging metrics surface at-risk tickets before breach, where none existed before
Designed outcome
Reduced back-and-forth — type-adaptive fields capture the right info upfront, fewer chase-up cycles
Designed outcome
Leadership visibility — root cause and CSAT tracking where no aggregate view existed
Designed outcome
Honest framing
This system was designed but is not yet measured in live production. The outcomes above describe intended design impact tied directly to research insights — not measured results. Post-launch, I'd want to track: average time-to-first-response, % resolved within SLA by ticket type, ticket reopen rate, and CSAT trend over the first two quarters.
What worked
Running the same affinity-mapping process consistently across every stakeholder — rather than synthesizing once — surfaced role-specific needs, like the Change Request approval gap, that a single-pass synthesis would likely have generalized away.
Next steps
Automated routing based on historical assignment patterns, AI-assisted triage suggestions, and a self-service knowledge base to deflect routine Service Requests before they become tickets.
What I'd change
I'd build in a formal usability testing round with real Creators and Processors before finalizing hi-fi screens, rather than relying solely on stakeholder review — feedback from stakeholders isn't a substitute for watching someone attempt a task unprompted.
One real learning
Designing one adaptive shell for three structurally different ticket types was harder upfront — it required mapping every field across every type before touching a screen — but kept the system learnable for processors handling all three daily. I'd reach for this pattern again for any system handling multiple related-but-distinct entity types.
Happy to walk through the FigJam research artifacts, the Figma file, or the design system in more depth.
Back to top ↑
Get in touch →