A clear portal for service requests
Internal Ticketing platform for better visibility on hardware/software requests.
CASE STUDY 03 · TWO-DAY INTERNAL HACKATHON
Reimagining Enterprise Service Requests
AbbVie Request Center (ARC) is an internal IT service platform for requesting technology, software, access, and workstation support. Today, filing a request means describing it to a virtual assistant, after which it moves into a separate service-management platform and is tracked away from where it began. During a two-day internal hackathon, a team of three set out to make that experience feel connected and predictable — I led the UX design and built a working prototype in the internal React design system.
ROLE
UX Design &
Front-end prototyping
TEAM
2 other teammates
TIMELINE
Two days
BUILT WITH
Figma, then the internal
React design system
We had two days, a team of three: 2 UX designers and a UX researcher.
So the question was not “how do we fix ticketing” — it was “what is the one structural change that makes this feel different, and can we build enough of it to be believed?”
You file the request in one place,
and track it somewhere else.
Filing an internal service ticket is a disconnected experience. You describe what you need through a virtual assistant, the request lands in a separate enterprise service-management platform, and from then on you track it apart from where you filed it.
Where it breaks down
Which ticket do I fill out?
Sometimes hard to decipher what will fulfill your needs.
What is this ticket for?
Every ticket type has to be learned, and there is nowhere inside the flow to learn it.
Where is it now?
You file it through one surface and track it in another. Statuses are difficult to track.
Who do I talk to?
Reaching the person managing the ticket is a separate task and flow from where you filed it.
Hi , how can we help you?
Before — the current-state screen
After — the ARC homepage
What we heard
There was not enough time for a full study, so we gathered live comments from several people on both sides of the process — the people who file requests, and the people who receive and approve them.
FROM SOMEONE WHO APPROVES REQUESTS
“It’s hard to navigate and approve other people’s tickets.”
So we designed for the person signing off, not just the person asking: an approver review queue, and a separate admin homepage alongside the general-employee one.
FROM SOMEONE WHO FILED ONE
“My ticket sat unattended for weeks.”
So status became something visible in two places at once — a lifecycle timeline for the whole request, and its own status on every item inside it.
One ticket, many items,
each with its own status.
The existing system treats every request as an isolated ticket. Real requests arrive in bundles — a new hire needs a laptop and a monitor and three system accesses, and should not type who they are four times. So we modelled the ticket as a container for multiple requested items: requester details captured once, status trackable for the whole bundle and per item. That is a data-model decision expressed as a UX decision, and it is the reason the flow feels different rather than just looking nicer.
Your monitor can arrive while your access is still with an approver. One status for the whole ticket would be a lie.
The bundled-ticket detail view
Four steps, and only the
questions your answers require.
The conditional third step is the whole argument. The existing system asks everyone everything; here, step three is assembled from what you actually selected in step two. Showing all four steps in order makes that claim visible instead of asserted.
1 — Your info
Auto-filled
2 — What you need
Multi-select (bundle or singular)
3 — Details
Only the answers that differ among each ticket
4 — Review
One bundle and separate tickets
What we designed and built.
Four-step create-ticket wizard
Your info → multi-select → only your questions → review
Bundled-ticket detail view
With a lifecycle timeline: Open → Awaiting approval → In progress → Resolved, plus Cancelled
Per-line-item drill-down
Each item in a bundle carries its own state, independently
A “My tickets” view
All / Current / Past tabs, search, and a combined filter-and-sort control
An approver review queue
Designed for the person signing off, not only the person asking
Two homepages
One for a general employee, one for an admin
Every piece ships against the same idea: a request is a container of items, each with its own state. That single model is what lets a four-step wizard, a bundled detail view, a personal queue, and an approver’s review screen all stay consistent without special cases.
Admin Rights
The admin approval view
Approvers were a secondary user in the workflow, but their experience was essential to completing a request. We designed an approval view that grouped pending items by request, provided the context needed to make a decision, and allowed items to be approved individually so one delayed item would not block the rest of the request.
During the hackathon, our researcher helped frame the problem and ran a quick five-minute usability test with employees. We used the feedback to make immediate adjustments to the flow and interface before the final prototype.
REFLECTION
My Takeaway
Prioritize the core idea.
With only two days, the most important decision was identifying which part of the experience was worth solving first. I learned to narrow the scope early and focus the team around the highest-impact workflows.
Plan before building.
Working in plan mode and reviewing Claude Code's proposed changes before implementation helped me catch misunderstandings early and avoid unnecessary rework.
Use AI as a tool, not the decision-maker.
AI accelerated the build, but I still had to evaluate its recommendations against the design intent, user needs, and technical constraints. The final decisions remained mine.
WHAT’S NEXT
Where it goes from here.
Presented up the chain
After the hackathon, the concept was shared in several higher-level meetings beyond the original team, giving the work visibility across the organization.
Opportunity for continued development
Parts of the bundled request and onboarding concept were identified as opportunities that could be explored further in future internal projects.
THE OTHER CASE STUDIES
← BACK TO ALL WORK