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.

I 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.

Timeline: 6 weeks Platform: Web-based self-service portal Users: Internal employees managing service requests and incidents

The redesign aimed to improve clarity, scannability, and consistency across different system configurations, helping users better understand request status and next steps.

Context & Constraints
(Understanding the System)

Before initiating user research or design exploration, I focused on building a clear understanding of the Self-Service Portal’s underlying system and configuration constraints.

I scheduled a working session with an internal consultant from our organization who supports customer implementations and configures the Self-Service Portal for different clients. During this walkthrough, I gained an end-to-end view of the request and incident flows and a detailed understanding of the operator-side settings that directly influence what information can be surfaced in the UI.

Mapping these settings was a critical first step. It helped clarify what was technically possible, which configurations were commonly used by customers, and where flexibility or limitations existed. This system understanding informed early design decisions and directly shaped how I framed questions for the upcoming user research, ensuring that insights gathered would be grounded in real product capabilities rather than theoretical solutions.

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 does the user journey look like after a request is submitted?
- What triggers users to revisit My Requests (e.g. concerns, updates, timelines, external influences)?
- How do users’ motivations and expectations change over time?
- What touchpoints exist beyond the portal, and how do they influence the experience?
- When do users consider their request journey successful?

2. Finding & Managing Requests
- How do users search for and identify a specific request in My Requests?
- What mental models do users rely on (status, date, category, urgency)?
- Which filters or sorting options are used, expected, or missing?
- What information helps users quickly confirm they’ve found the correct request?

3. Interacting with a Specific Request
- What actions do users expect to take on an individual request or incident page?
- Which information do users focus on first, and why?
- What needs, uncertainties, or challenges 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

Design exploration focused on translating research insights into clear, scalable solutions that could work across different system configurations. I explored multiple layout options to better express complex request information and experimented with different approaches to visual hierarchy to draw attention to the most important details, such as status, progress, and required user actions.

All concepts were built using existing design system components and guidelines to ensure consistency and feasibility within the product rewrite. I iterated on variations that addressed key user pain points identified in research, including difficulty scanning multiple requests, uncertainty about what to do next, and challenges identifying a specific request at a glance.

This was done through crazy 8 exercise with other designers, to come up with innovative solutions to address some tricky problems. As an example below you can see some sketches from this exercise on how improve the closing request feature on a card.

Throughout this phase, design decisions were continuously evaluated against user needs, system constraints, and long-term scalability, helping narrow down solutions that balanced clarity, flexibility, and technical viability.

Tech Review

Early and ongoing technical reviews were conducted in collaboration with developers in the team to validate feasibility across different customer setups. These sessions helped identify which design ideas could be supported by existing configurations and where adjustments were needed to align with technical constraints.

Feedback from these reviews informed refinements to information hierarchy, component usage, and interaction patterns, ensuring that the proposed designs could be reliably implemented without introducing additional 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

I worked closely with engineering to walk through the designs, clarify intent, and ensure a shared understanding of edge cases and system-driven behavior, helping support a smooth implementation phase.

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.

Reflections and Learnings

This project reinforced the importance of grounding design decisions in a strong understanding of system constraints, especially in highly configurable enterprise products. Early collaboration with consultants and engineers proved essential in shaping realistic and scalable solutions.

I also learned the value of framing research questions around the broader post-submission journey, which helped uncover needs beyond the immediate UI and informed more meaningful design improvements. If revisiting this project, I would further explore longitudinal validation to better understand how users’ needs evolve over the full lifecycle of a request