Early 2025
EdTech, K–12 SaaS
Project output
Highlights
The problem
Teachers and staff could explain an issue without knowing how IncidentIQ classified it. Technicians needed the request connected to the right location, device, and category before they could act.
Traditional intake asked the requester to supply much of that structure. Simplifying submission could reduce effort for the teacher, but missing information created more investigation for IT.
The question was how to make requesting support easier while improving the information entering the ticket.
IncidentIQ’s later analysis reported that approximately one in four tickets arrived as “issue not listed,” and those requests took an additional five days to resolve on average. These findings describe the broader operational problem and were published after my tenure.
My role
I led the work as Director of UX while remaining hands-on in product design. I defined the workflow architecture and designed multiple complete prototype and high-fidelity rounds with Product and Engineering.
My responsibility extended from assistant entry through troubleshooting and the transition to ticket creation. I also connected the experience to the shared design system and contributed validation planning, acceptance criteria, and delivery guidance.
Exploration and tradeoffs
The early exploration used conversation as the primary interaction. A request such as “I can’t log into my computer” established the problem without requiring a technical diagnosis.
The next decision was how to collect the remaining information. Keeping every response conversational allowed flexibility, but it required interpretation even when the answer already existed in the product.
Conversation established the request.
Structured selection connected it to known product data.
The flow needed to preserve flexibility without hiding classification behind interpretation.
In subsequent rounds, I introduced structured controls at those points. Conversation established the request; selection connected it to known product data.
This shifted the assistant from an open-ended chat into a guided support workflow that could still feel conversational while producing actionable ticket context.
Confirming context and classification
The location step represented the school and room as a card within the conversation. Category cards followed, with search available when the recommendations did not fit.
I separated the assistant’s guidance from the available responses. The prompt explained the information needed, while the cards contained the choices. A stronger border identified the selected category without changing the surrounding layout.
Location, category selection, and search provided specific answers within the assisted flow.
Search was an important alternative. A recommendation could be wrong without making the entire request unusable; users needed to find the appropriate category and continue.
Extending the shared product system
My shared Grid work had separated reusable behavior from product-specific content and workflow rules. Six module-specific implementations became one system supporting Tickets, Assets, Parts, and Rooms. Grid case study
The assistant applied the same design approach in a new context. Existing detail, selection, search, and action patterns represented product information inside the conversation. The AI-specific work concerned when to present them and how the workflow responded afterward.
This kept the system contribution concrete: familiar product elements supported a new capability without requiring a separate control set for routine actions.
Offering self-help before submission
Troubleshooting introduced a second successful path: resolving the issue without creating a ticket.
It also added effort. I made the recommendation optional so that trying a fix would not become a requirement for receiving support. Users could accept the offer or decline it. The traditional submission route remained available at entry.
Designing unsuccessful recommendations
After attempting a fix, users could confirm resolution, request another solution, or stop troubleshooting. Those choices represented different states, not interchangeable ways to dismiss the message.
The user reported whether the recommendation worked; presenting instructions did not establish resolution.
The feedback controls allowed a user to explain that the suggestions had failed. The design therefore accounted for an unsuccessful recommendation within the main workflow rather than treating it as an exceptional case.
Conversation established the need, while structured controls and optional self-help kept the workflow actionable.
Plain-language request
Unstructured input
User describes the problem in their own words.
Location / category selection
Structured choice
Known product data is selected directly.
Ticket context becomes actionable.
Self-help attempt
Optional troubleshooting
User can accept, decline, or report failure.
Resolution must be confirmed.
Validation and refinement
Internal testing raised questions about how success and drop-off were being interpreted. A user leaving before ticket creation could have abandoned the task, or could have resolved the issue through self-help.
That distinction changed what the evaluation needed to capture. Ticket creation measured successful submission, not necessarily successful support. Confirmed self-resolution needed to remain separate from unexplained exits and failed troubleshooting.
Confirmed self-resolution needed its own signal.
Unexplained exits could not automatically be counted as successful support.
Failed troubleshooting needed to remain visible in the evaluation model.
Interaction
Required distinction
Workflow meaning
Measurement note
The workflow can use the category for routing.
A recommendation can be wrong without ending the request.
The user can continue toward ticket creation.
The issue can be counted as resolved through self-help.
The team addressed the measurement model before relying on external test results. My contribution included validation planning and design refinement.
No measured improvement in AI completion or ticket deflection is claimed from testing during my tenure.
Connecting design decisions to delivery
I worked with Product and Engineering on how the assistant’s interaction states mapped to the existing support workflow. The implementation needed to distinguish user selections from recommendations and unresolved issues from confirmed resolutions.
Behavior map
The following behavior map summarizes the visible design decisions. It is a reconstruction for this case study, not a recovered historical specification.
Interaction
Required distinction
Select an issue category
A suggested category becomes a user-selected classification.
Search for another issue
The suggested options do not restrict the available categories.
Decline a quick fix
Declining assistance does not indicate resolution.
Choose “This solved it”
The user explicitly confirms the troubleshooting outcome.
Try another solution
The issue remains unresolved after the prior recommendation.
Stop troubleshooting
Assistance ends, but resolution must not be assumed.
Choose traditional ticket submission
The requester can use the established support route.
These distinctions made the designs actionable beyond the screen sequence. They described what a response meant and what the workflow could safely conclude from it.
Released product
IncidentIQ announced AI Ticket Assistant in February 2026, after my departure. The released product connects plain-language requests with structured context, classification, priority, and routing within existing iiQ workflows.
The released product also provides troubleshooting assistance. Product announcement
The release establishes continuity in the product approach, not that every early screen or component shipped unchanged.
Visual placeholder: verified production flow paired with relevant early design references.
Outcomes
The supporting Grid project consolidated six implementations into one, an 83% reduction in implementation count. That is a system outcome, not an AI-ticketing performance measure. Grid outcomes
Reported results
For the later AI product, IncidentIQ reported up to 30% faster ticket resolution and separately reported an early reduction in average resolution time from five days to one.
These are company-reported results from the subsequent product, not measurements from my tenure. Reported results
The outcome of my work was the product and workflow foundation: assisted intake, structured context collection, troubleshooting paths, and implementation guidance.
Reflection
Adding self-help changed both the workflow and the definition of success. A completed ticket was no longer the only useful outcome, and an exit was no longer sufficient evidence of failure.
The design needed explicit user responses at those points. That connected interaction design to measurement: the same choices that helped users continue also allowed the team to distinguish what had actually happened.
