Making complex service desk configuration easier to manage

The product & context

The product is an AI-assisted service desk platform built to support IT agents during calls. It brings together information about the caller, their devices, and existing tickets, while providing real-time knowledge-base suggestions and an AI chat to help resolve issues.

Behind all of that is an administration panel. It’s where authorized users manage integrations, client-specific settings, and the configuration of different platform features.

I worked on a wider redesign of the product alongside another designer. My responsibilities covered low-fidelity designs for the entire administration panel, high-fidelity designs for selected admin screens and the chat module, and a completely new agent-monitoring experience.

For this case study, I’m focusing on ITSM Management — the part of the admin panel responsible for service requests, ticket field configuration, and related settings.

It was one of the more complicated areas to work on, mainly because there was a lot of functionality to understand before I could even start reorganizing it.

The challenge

The old admin panel had a little bit of everything — and almost none of it was where you’d expect to find it.

Some fields were no longer used but were still sitting in the interface. Others had technical labels that weren’t particularly helpful unless you already understood how the system worked. Configuration options were grouped together in ways that weren’t always logical, so finding something specific could involve a lot of expanding, scrolling, and checking the wrong places.

Even the developers working on the product sometimes struggled to explain how certain parts were organized.

I couldn’t solve that by rearranging a few fields or making the forms look nicer. First, I needed to understand what was actually there, how the different configurations were connected, and which parts of the existing structure were causing problems.

There was also the question of what would happen later. New configuration options would inevitably be added, so whatever structure I came up with needed to make sense beyond the current set of features.

Legacy / field configurations

1. 01Long accordion lists: every field was collapsed by default, so users had to open rows just to identify them.
2. 02Repeated labels and technical API names sat next to each other, with little hierarchy to explain the difference.
3. 03Field order was represented as a number inside each row, rather than as a sequence people could see and manipulate.

My role & approach

Getting to grips with the existing system

My first task was understanding the legacy ITSM functionality.

I went through the existing screens, read the available documentation, and spoke with developers and QA testers to fill in the gaps. Some behaviors were straightforward once someone explained them. Others needed quite a bit of digging.

I also used AI to help organize the collected requirements into a structured list of functionalities. That gave me something more manageable to work through and helped me keep track of the settings I still needed to account for.

At this stage, I was looking at individual configurations, but also trying to understand how they fitted together. I didn’t want to redesign one workflow only to realize later that it introduced a completely different interaction pattern from the rest of the panel.

Working through the designs

I started in low fidelity, working through the structure and behavior of the different configuration areas before worrying about the final UI.

The first concepts went through reviews with developers, testers, and the other designer. We discussed the proposed workflows, checked technical constraints, and identified things that needed changing.

I revised the designs and brought them back for another round of feedback before moving to high fidelity.

The high-fidelity screens were based on the shared design system maintained by my fellow designer. Some of the new workflows needed components and interaction patterns that weren’t covered by the existing library, so those requirements also had to be addressed.

Exploration / low fidelity

Working without direct access to end users

One limitation was that I didn’t have access to the administrators who would eventually use these settings.

Most of the feedback came from people who knew the system from a development or testing perspective. Their input was valuable, especially when it came to understanding technical behavior and identifying potential problems.

It also meant that some UX decisions would still need to be checked with actual administrators once that became possible.

The decisions that mattered

Giving every setting a place to belong

The first big decision was how to divide up all the functionality.

The original ITSM Management area had very little meaningful separation between different types of settings. I wanted people to be able to find the right configuration based on what they were trying to do, rather than having to remember where someone had originally put it.

I ended up dividing the area into five categories: General, Requests, Ticket Field Configuration, Templates, and Language Mapping.

Each category had a clearer purpose, with more detailed sections where needed. It also gave us a structure that could accommodate new functionality without having to rethink the entire layout every time.

Before

• Configuration

  One loosely organised area with very little meaningful separation.

• Expandable field lists

  Technical settings hidden inside long accordions.

• Expandable request lists

  Request configuration mixed with the rest of the panel.

After

• General

  Global and system-wide ITSM settings.

• Requests

  Browsing, adding, and editing requests.

• Ticket Field Configuration

  Managing ticket fields and their display order.

• Templates

  Dedicated template configuration.

• Language Mapping

  Dedicated language-mapping configuration.

There was one thing I wasn’t entirely comfortable with: the number of navigation levels.

The product already had its main navigation and a separate sidebar for the administration panel. Adding tabs within ITSM Management, and sometimes another level inside those tabs, made the hierarchy deeper.

I discussed this with the other designer. We looked at the alternative, which would have kept more settings together but made the individual views considerably more crowded.

We decided the extra depth was worth it if it meant that each section had a clear purpose.

The same approach was later used to organize other areas of the administration panel.

Additional navigation depth in exchange for clearer functional grouping. The structure has not yet been validated with target administrators.

Making configurations easier to find

One of the recurring problems in the old interface was how configuration items were displayed.

They lived inside long expandable lists, and you often had to open an item just to figure out whether it was the one you needed.

I replaced these lists with tables, giving each configuration its own row and displaying the most useful information directly in the columns.

The tables also included searching, sorting, and filtering, so users wouldn’t have to work their way through the entire list manually.

Choosing what to show in each column took some discussion with developers and QA testers. I wanted to understand which attributes were shared across configurations and which ones would actually help someone identify a record.

I also introduced Last modified and Last modified by columns.

These turned out to be particularly useful in a system where multiple people may be making configuration changes. Being able to see when something was updated and by whom gives people useful context before they start editing.

Before / expandable records

After / searchable table

Making the forms less of a chore

The forms were another area that needed attention.

There were plenty of fields, but not much to help people understand how they related to one another. Some labels were unclear, and the overall structure made configuration tasks feel more complicated than they needed to be.

I reviewed how the fields were grouped, which controls made sense for different inputs, and where additional descriptions or clearer labels would help.

I also worked on making the create and edit workflows more consistent across the panel.

For editing existing configurations, I used a dedicated panel so users could make changes while keeping the surrounding list in context.

Some forms were still going to be complex. They had to support fairly technical configuration options, and removing that complexity wasn’t always possible. But there was no reason the interface had to make those tasks harder.

Low fidelity / edit request

High fidelity / edit request

Reordering fields without the guesswork

The redesign of ticket field ordering is a good example of how much an interaction can change without the underlying functionality changing at all.

Previously, if someone wanted to change the order of fields in a ticket form, they had to enter a position number manually in a text field while editing the configuration.

There was no convenient way to rearrange the whole sequence visually. Getting to the correct configuration context was unnecessarily complicated, too.

I redesigned the flow around a dedicated Ticket Field Configuration area.

Once the relevant ticket form context was selected, the available fields appeared in a table, along with information such as their names, types, and whether they were required.

From there, users could switch to Reorder fields mode and drag rows into the order they wanted.

They could see the sequence change as they worked, then save the new order or discard the changes.

I liked this solution because it made the task much more direct. If someone wants to rearrange fields, they should be able to rearrange fields — not work out which numbers to enter.

1. 01

   Select the ticket form context: user, incident, update, and status.

2. 02

   Inspect the available fields, their types, and whether they are required.

3. 03

   Enter Reorder fields mode and drag rows into the desired sequence.

4. 04

   Save the new order or discard the changes without leaving the context.

Before / numeric entry

The old way: find the field, then type a position number.

Low fidelity / reorder mode

The new interaction made the sequence visible and editable.

High fidelity / reorder mode

The final pass kept field properties visible while the order changed.

What happened next

After the design reviews and high-fidelity handoff, the development team implemented the redesigned ITSM Management area in development and testing environments.

The updated experience is now gradually being rolled out to client environments.

The feedback I’ve received from developers and QA testers has been positive, particularly around navigation and working with configuration lists.

They’ve found it easier to locate functionality and understand how different settings are organized. The new tables have also made it easier to browse requests and ticket fields without opening each item individually.

The additional columns showing when a configuration was last modified and by whom were highlighted as helpful for tracking changes.

It was good to see that changes we’d spent time discussing during the design process were also proving useful once the interface was implemented.

There’s still more to learn as the rollout continues, especially from the administrators who will use these workflows regularly.

What I’d validate next

One thing that stands out to me about this project is just how much time went into understanding the existing functionality before the new designs started taking shape.

There were a lot of small details and dependencies to account for. Once I’d worked through those, it became much easier to decide what belonged together and where the existing workflows could be simplified.

The navigation structure was probably the most interesting decision. I knew I was adding another layer to an already fairly complex interface, but the alternatives came with their own problems.

I’d still like to see how that decision works in practice for administrators.

If I had the opportunity to follow up with usability testing, I’d focus on a few everyday tasks: finding a specific configuration, editing a request, and changing the order of ticket fields.

I’d be especially interested in where people hesitate, which labels they find confusing, and whether the navigation structure matches how they expect the settings to be organized.

That would help me understand which decisions are working well and which parts still need another look.