Solving IT ticket overload
with Design Thinking.
HP's IT support teams were drowning in tickets. I designed and facilitated a cross-functional Design Thinking workshop that produced measurable results — 30% fewer tickets in 3 months.
Too many tickets.
Not enough clarity on why.
HP's IT support teams were overwhelmed with a high volume of tickets — repetitive requests, incorrect submissions, confusing workflows. The cost was real: slow resolution times, frustrated employees, and IT teams spending time on issues that shouldn't have reached them.
Employees didn't know how to self-serve, submitted tickets incorrectly, and repeated the same requests. IT had no self-service layer and no structured intake. The result: high volume, high cost, low satisfaction on both sides.
Designed and facilitated the full Design Thinking workshop end-to-end — from problem framing through prototyping. Applied JTBD methodology, led cross-functional participants through research, ideation, and solution validation in an online environment.
"How might we increase employee productivity through incident reduction to reduce costs for the company?"
What was actually
breaking the system.
Before designing solutions, we needed to understand the real causes of ticket volume — not just the symptoms. These patterns emerged from the discovery phase.
A significant share of tickets were for issues employees could resolve themselves — if they had the right guidance and self-service tools available.
The ticketing interface gave employees too many options with too little guidance, leading to incorrect categorization and routing — adding manual rework for IT teams.
Employees defaulted to tickets because there was no accessible, trust-worthy knowledge base or guided troubleshooting — even for simple, well-documented issues.
Tickets filed under the wrong category were routed to the wrong team, causing delays, handoffs, and frustration on both employee and IT side.
Four phases.
One coherent process.
The workshop was structured across four phases, each building on the previous. Every method was chosen to generate real insights — not just fill a workshop agenda.
Starting from empathy, not assumptions
Opened with a collaborative discussion to surface diverse perspectives. Ran an empathy mapping exercise to see the experience from the user's point of view — their needs, frustrations, and workarounds.
Used the "How Might We" technique to reframe problems as opportunity spaces. Closed the phase with a shared problem statement and agreed success criteria — so every subsequent decision had a reference point.
User interviews + customer journey mapping
Conducted structured 1:1 interviews with employees. Defined objectives upfront, used open-ended questions, created a safe environment for honest feedback. Facilitated group analysis to identify patterns and pain points.
Followed with customer journey mapping — identifying every touchpoint from when an issue occurs to resolution, mapping emotional responses at each stage, and flagging the highest-friction moments as priority opportunity areas.
Brain Writing + Brainstorming through Association
Used Brain Writing to enable parallel idea generation — avoiding the groupthink that comes from verbal-only brainstorming. Each participant contributed independently before ideas were shared and built upon.
Followed with Brainstorming through Association to push beyond obvious solutions. Closed with Idea Clustering and dot voting to surface the highest-potential concepts for prototyping — balancing impact against feasibility.
JTBD-grounded rapid prototyping
Applied the Jobs-To-Be-Done framework to anchor prototypes in what users actually need to accomplish — not what they say they want. Built clear job statements and user scenarios before sketching any solution.
Teams created low-fidelity prototypes, presented them for peer feedback, and iterated in real time. Validated through direct user testing — observing how well solutions addressed the identified jobs, refining based on findings.
The toolkit that
made it work.
Every method was selected for a specific reason — to surface the right insight at the right moment in the process.
Facilitation is a
design problem too.
Running a workshop that produces real outcomes — not just sticky notes — requires the same rigor as designing a product. These are the lessons that shaped how I work.
Structure creates psychological safety. Participants shared more honestly when the process gave them a clear container — they knew what was expected, in what order, and that every input had a defined purpose.
JTBD is a better prototyping anchor than personas. Personas describe who someone is. Jobs describe what they're trying to do. The latter produces more focused, testable solutions — especially in enterprise contexts where one "persona" covers dozens of actual use cases.
Online facilitation requires more design, not less. In a physical room, energy is visible. Online, you have to engineer the conditions for participation — smaller groups, shorter exercises, more explicit prompts, and tighter timekeeping.
The right question is worth more than any solution. The "How Might We" framing shifted the workshop from complaint-mode to opportunity-mode in minutes. Getting problem framing right upstream saved significant time in ideation and prototyping.
Measurable outcomes require defined success criteria upfront. The 30% ticket reduction was trackable because we agreed on what success looked like in Phase 1 — before anyone proposed a single solution.
Fewer tickets.
Faster resolutions. Better experience.
Measurable outcomes within 3 months of implementation — driven by solutions grounded in real user needs, not best guesses.
Beyond the numbers: participants left with applicable Design Thinking skills — the workshop wasn't just a one-off fix, it built internal capability for user-centric problem solving across teams.
Need a workshop that
actually moves things?
I design and facilitate sessions that produce real decisions, not just post-its. From problem framing to validated prototypes.