Helping employees track their orders and incidents
Wider context
Client: Public service organisation (name can’t be disclosed)
In 2019, our team was tasked with the creation of an employee portal MVP which had a clear business goal: to increase employee self-service.
The presented case study shows the journey we’ve embarked on in order to develop only one out of 8 features our team worked to deliver as part of this MVP: tracking and raising incidents.
MY ROLE
Senior UX Designer
OTHER TEAM MEMBERS
Design Lead
User Researcher
Lead BA
Product Owner
Only got two minutes?
Problem
User problem:
People did not feel equipped with the right information to solve their own technical problems nor did they feel empowered to do so. As a result, they raised a lot of incidents for what was categorised as “advice and guidance“, overwhelming incident engineers with requests.
The average SLA for an incident to be resolved was 12 days.
Business problem:
A large number of incidents raised, requests made and calls were costing the organisaition too much for it to be sustainable.
38% of all incidents were raised via the phone, which come to an average of 10,000 calls per month.
PROCESS
Understanding the engineers solving employee incidents
Before jumping into understanding our users, we wanted to first gain some organisational context. This was to ensure we’re taking everything into account and we’re not proposing solutions that would be completely unreachable for the organisation.
We led a workshop to understand the full lifecycle of an incident - from the moment it gets raised, to the moment it is resolved. The below journey describes each step, the people involved and their pain points.
The Incident Process
written together with our user researcher and Lead BA, based on interviews with incident engineers
Understanding our users
Heavy users needed to see updates on behalf of others
Many offices had a ‘designated IT person’, who raised incidents and orders for their colleagues. For this reason, they needed to be able to raise, track, update and close incidents on behalf of their colleagues, so they could continue supporting their IT needs.
A large group of users had limited technical understanding
We needed to make sure that the information we provided was clear and simple to understand for all users. This included people with low digital literacy, who needed to understand the status of their orders and incidents at a glance.
Employees always interacted with the incident team out of necessity
“I just want to get back to work“
This is what we heard from our users over and over again. You likely know this from personal experience - IT support isn’t someone you want to interact with. It’s an interaction made based on necessity. And an interaction we wanted to go smoothly.
As a result of this research “I just want to get back to work” become something we constantly used when making design decisions.
If having to choose between options or struggling to make a decision, we would always ask “Would this allow the user to get back to work quickly?”. If the answer was no, we knew we had to move on.
Designing the solution
Quick overview
The employee portal homepage
What if users could know the state of their orders and incidents the moment they landed on the employee portal?
Our research showed that raising and tracking orders and incidents was one of the main reasons why users were using the current portal.
As a result, in our redesign it made sense for us to make it easy for people to do both.
Known incident widget
If users were experiencing a wider, known issue (e.g. Skype was down company-wide) all they had to do was add themselves to the incident.
This made it a 1-click job for the user, while incident engineers could spend their time solving other issues.
Orders and incident summary
Instead of having to go to another page, users could see right away what state their incident is in and if they need to take any action.
User feedback: “That’s a good idea, a summary of incidents there, at the moment you have to click into something to do it”
Employee portal homepage -
where users could see their open incidents at a glance
Your orders and incidents page
Surfacing only the most important information in easy to scan tables
Allowing ‘superusers’ to filter the data based on who the incidents were raised for
In our initial iteration, we made the assumption that people would only need to filter the orders and incidents based on state. But super users mentioned that it would be hard to find the incident they raised for themselves when looking through hundreds of them.
We therefore added the “Raised for” filter to support them. This in itself was a design compromise. We wanted to have this filter option below the first, but were told that would be difficult to implement within the timelines. Therefore, we added it above, which happily was not a problem for our users.
‘Your orders and incidents’ page
Previous iterations
of the ‘Your orders and incidents’ page
1st iteration
2nd iteration
3rd iteration
Final iteration
The incident page
Making it easy to interact with those solving incidents and tracking incident progress
We knew the incident/order state was what users were most interested in when on this page. Therefore, we featured it at the top, using the same label as the one on the homepage, so it’s easy to recognise.
However the other reasons why users would land on this page would be to
Close their incident
Provide a progress update
We made these actions visible above the fold, an improvement from the old designs where users had to scroll all the way to the bottom to perform these actions.
Incident page
Previous iterations
of the incident page
1st iteration
2nd iteration
Final iteration
Constraints
Limiting out of the box functionality
Our product needed to be built in ServiceNow's Service Portal, mainly using out of the box widgets and limited functionality.
This heavily affected our design options, and we tried to provide the best UX with the limitations at hand.
Lack of scope around prevention
We once wanted to try a pilot for putting a larger poster near the printer with clearer instructions with how to connect to it. Our hypothesis was that calls related to this issue would go down if people had better information at hand.
However prevention was not in scope, so we continued focusing on the incident journey.
What I learnt
Well-crafted content design is a non-negotiable part of design
While I always do my best to make things clear, easy to understand and easy to read, working with a content designer for the first time re-iterated to me the importance of content design as part of UX.
Some technical constraints just need to be worked around
Being passionate about helping our users, I want to make sure that things work how they expect them to.
However, this project exposed me very limiting technical constraints, that I simply had to work around. That unfortunately meant UX compromises at times, but I often reminded myself that we still are making a positive change when we see how much more usable our designs are compared to previous ones.
Results & next steps
I had to move to another project before the portal went live, however user research and testing conducted during the design attracted positive feedback from our users.
Notes from the user research reports:
People like to be able to easily locate what they’re looking for, new design allows them to do this without scanning through lots of pages, words and boxes
The clear & easy to understand layout made people feel better about themselves, because now they could find things easily
Most users identified the status of an incident ithout us (user researchers) needing to ask them about it. In initial research of the old design, users were really struggling to find incident updates.
The platform has now gone live to 1000 users, however I am not allowed to access or know the data related to the launch, since I am no longer part of the project team.