SSP

Project Overview

As part of a broader product rewrite initiative, this project focused on redesigning the My Requests overview and the Incident Card within an enterprise self-service portal that is the end-user facing part of a service management tool.My RoleI led the UX design for this initiative, working closely with a product manager, engineers, and external consultants. My scope included understanding system constraints, planning and conducting user research, exploring design solutions, and supporting technical reviews and design handover.Timeline6 weeksPlatformWeb-based self-service portalUsersInternal employees managing service requests and incidentsObjectiveThe redesign aimed to improve clarity, scannability, and consistency across different system configurations, helping users better understand request status and next steps.

System mapping of statuses and SSP settings

Context & Constraints
(Understanding the System)

Before any research or design exploration, I mapped the Self-Service Portal’s underlying system and configuration constraints with an internal consultant who configures the portal for customers.

This walkthrough gave me an end-to-end view of the request and incident flows and clarified which operator-side settings shape what the UI can show, what was technically possible, which configurations customers commonly use, and where the flexibility and limits were. It grounded both my early design decisions and the framing of the research questions in real product capabilities.

Research Planning

Research ObjectiveTo understand how users find, track, and manage previously submitted requests within the Self-Service Portal, from the moment a request is sent through its resolution.Research Questions1. Post-Submission Journey
- What happens after a request is submitted, and what triggers users to revisit My Requests?
- How do motivations and expectations change over time, and when do users consider the journey successful?

2. Finding & Managing Requests
- How do users search for and identify a specific request, and what mental models do they rely on?
- Which filters and sorting options are used, expected, or missing?

3. Interacting with a Specific Request
- What actions do users expect to take, and which information do they focus on first?
- What needs or uncertainties arise at this stage?

MethodologyThe research consisted of 1:1 moderated sessions combining qualitative interviews and usability exploration.
Each session included:
- Interview component to understand the broader post-submission journey, motivations, and expectations
- Usability component focused on how users interact with My Requests and individual requests in their own environment, with screen sharing where possibleAnticipated DeliverablesThe research was expected to result in:
- A journey map highlighting key touch-points, needs, and friction points from request submission through resolution
- A research synthesis report summarizing key insights and translating them into actionable design recommendationsParticipantsThe study included 6 participants (1 internal user and 5 customers), all active users of the Self-Service Portal. Participants were selected across different business units and regions to capture a range of usage patterns and configurations.

User Research & Synthesis

Following the research sessions, I synthesized the insights into a journey map capturing the end-to-end experience of managing a request from the moment it is submitted to the final consultation by the user. The journey map helped surface key touch-points, user motivations, and shifts in expectations over time, while clearly highlighting moments of friction and uncertainty. This visual artifact made it easier to identify patterns across participants and understand how user needs evolved beyond the initial submission of a request.In parallel, I documented the findings in a research report using Condens, summarizing key insights, pain points, and opportunity areas. Each finding was translated into actionable recommendations to ensure the research directly informed design exploration.Together, these synthesis outputs provided a clear foundation for design decisions and guided the exploration of solutions for both the My Requests overview and the Incident Card.

Competitor Analysis

To ground the design exploration in established industry practices, I reviewed how other IT service management platforms present incident and request information. This analysis focused on identifying common UI patterns rather than comparing feature parity. I examined incident card and request detail screens from HaloITSM, Freshdesk, and ServiceNow, looking specifically at how these products communicate status, priority, ownership, and next steps to users.The goal of this exercise was to understand which patterns users are likely already familiar with and to identify conventions that could be adapted to the Self-Service Portal, while still accounting for the platform’s configurability and constraints. Insights from this review helped inform information hierarchy decisions and supported design choices during early exploration.

Design Explorations

To facilitate ideation, I first laid out all the problems surfaced in user research. Having every pain point visible in one place made it easier to spot connections and kept the explorations anchored to real user needs.

Research insights laid out: how and why users access the incident card, closing friction, and scrolling issues

I then ran crazy 8 exercises with other designers to generate creative solutions for each problem. As an example, here is the crazy 8 round for closing a ticket which was for exploring ways to remove the double effort of adding a closing reason when a comment was already written.

Crazy 8 exercise for closing a ticket: problem statement and eight sketched variations of the incident card

Tech Review

The strongest ideas from the crazy 8 rounds were taken from wireframes to full UI, applying the design system guidelines, and brought to the team for review and further iterations.

Alongside this, early and ongoing technical reviews with developers validated feasibility across different customer setups identifying which ideas existing configurations could support and where adjustments were needed. Their feedback informed refinements to information hierarchy, component usage, and interaction patterns, so the designs could be implemented without extra complexity or custom behavior.

User Validation

To validate some of the proposed design directions, I shared refined concepts with users to assess clarity, comprehension, and overall usability through an unmoderated user test. We used Useberry as a tool to conduct the test. Tasks that were mainly evaluated :
- Finding the original request description in the new layout
- Sharing the request with colleagues
- Closing the request

Follow up questions
1. How was the experience on an opinion scale
2. An open ended question explaining the experience

Targeted expected response
Atleast 20 participants

Success criteria
For each task a success threshold is an average rating of 5 or above
Responses will be paired with the open feedback. Feedback focused on how easily users could understand request status, identify relevant information, and anticipate next steps.

Insights from these sessions were used to fine-tune layouts, labeling, and emphasis, while confirming that the redesigned My Requests overview and Incident Card better supported users’ mental models compared to the existing experience.

Dev Handover

Final designs were prepared for handover as part of the product rewrite initiative. This included:
1. Different screen sizes
2. Edge cases/corner cases
3. All the error and empty states
4. Accessible heading structure for screen readers
5. Making sure longer texts, custom field names and translations do not ruin the design

Accessibility considerations were incorporated throughout the design process. I reviewed the designs against accessibility guidelines, with particular attention to color contrast, text hierarchy, focus order, and the use of visual cues beyond color alone. Where needed, adjustments were made to ensure that critical information such as status and alerts remained perceivable and understandable for a wide range of users, supporting inclusive use of the Self-Service Portal.

Outcome

The redesigned My Requests overview and Incident Card shipped as part of the product rewrite. Following the launch, adoption of the redesigned SSP increased by 15% over a period of 3 months. Customers actively switched to the new experience, while feedback collected through the in-product channel was overwhelmingly positive where users found it easier to understand the status of their requests and what to do next.

Reflections and Learnings

This project was a practical reminder that designing for an enterprise product means working with its constraints, not around them. Involving consultants and engineers early helped us identify what was technically feasible and avoid solutions that would not scale across different customer configurations. Looking at the full journey after submission also uncovered gaps we would have otherwise missed.

One useful experiment was building a coded prototype with Claude for user testing. Participants could filter requests, change statuses, and expand cards as they would in the product. This led to more natural interactions and exposed issues that were difficult to observe in a scripted Figma prototype. It was also quick to update between sessions as new feedback emerged.