01 Industry Background
What is it and who is it for?
The MSP Manager is the ticketing solution for IT technicians. There you find all the information about the devices, what is the issue, and what you should do. Once you start working, you can track your time, provide the notes and then generate the invoice for your customer. You can do much more there, but this simple overview is just ok for this case study. The feature I've designed was focused on the IT technicians who are working with this product all day long.
02 Challenge
Speeding up the workflow
How can we speed up the ticket workflow? MSP technicians have to solve hundreds of tickets each month. A lot of issue types are repeating or can be very similar. Some of them can be very complex and the technician needs to cooperate on it with other IT colleagues. Then knowing what to do can be challenging and you can find yourself spending more time on finding what was done instead of solving customer issues. Of course, you have to meet the SLA so you don't have the whole day for it.
- Make it fast and reusable for everyone
- Create the ability to define ticket tasks
- Give technician more control over the process
03 Research
How do technicians work?
I've used the data from the design researchers and I've conducted interviews with the internal IT technicians who were based in the same office. They usually do the multitasking and relentlessly work their way through the ticket queue. They have two or more monitors in order to be more efficient. They are communicating with their customers over email or phone. Some of them are trying to organize and prioritize their work via Posti-ts or via a digital task list. It is used repetitively or it is also shared with colleagues.
What is the motivation? They are performance-driven. More solved tasks with high customer satisfaction in the long term mean a chance to get a promotion. So they can meet their aspiration and become the Technician manager. Their targets are billable time per week, number of closed tickets, avg time to resolution, CSAT.
04 Architecture design
Task templates
Initially, we had a vision that we will build a robust system that will cover also IT project management. But we didn't get the sponsors for this kind of project size. Therefore we changed the scope and focus only for the task list.
Based on the observation I've come up with the idea of reusable task templates. It means that the task list for a specific type of work will be created only once and then can be used many times. Or the template could be improved by more experienced colleagues. So MSP provider would be able to constantly improve the procedure, share the best practices and improve the service quality.
05 User-flow design
Create a custom list or select a template?
Initially, we had a vision that we will build a robust system that will cover also IT project management. But we didn't get the sponsors for this kind of project size. Thus we changed the scope and focus only for the task list.
Based on the observation I've come up with the idea of reusable task templates. It means that the task list for a specific type of work will be created only once and then can reused many times. Moreover experience colleagues can improve the template. So MSP would be able to constantly improve the procedures and share their best practices.
06 User interface
Task list interface
The task panel had two levels. The first level (1) was the overview. It communicated the total estimated time and the task progress. The list of actions represents the task that was done or should be done. The user could see the task that had a dependency (orange dots).
The second level (2) was the task detail. There you found out the details of the task such as the description, estimated time. You could assign the owner and user. Besides that, you could easily set up the dependency or upload the attachments.
Task list interactions
When you set task status as the done, a system created a new event in the time log. If you wanted to change ticket status as done, the system checked whether there is any remaining task and gives you a notification if that was true. You don't want to say to the customer that the issue is solved when some task hasn't been done yet. Are you more interested in details? See the mockups below.
-
01 Task template list See detail 02 Task template selection See detail -
03 Creating task template See detail 04 Task dependency See detail -
05 Creating task template See detail 06 Task detail with dependency See detail -
07 Validation See detail 08 Editing task detail See detail -
09 View of the task See detail 10 Activity timeline See detail -
11 Task interaction See detail 12 Incomplete task notification See detail -
13 Task validation See detail
06 Validation
Was that successful?
We haven't tested this solution with the customers. Long story short, we didn't have enough time and personal capacity for it. But I've done at least the guerilla testing with the same group of local IT technicians as I used for the research part. They were positively surprised that we've been thinking about the templates. People are happy when someone listening to their needs. From the testing came up one idea—visualize the task dependency as you often need to wait for someone or for something.
We used the beta user group to validate the feature before it was released to everyone. The disadvantage of this approach is that you need to develop the solution. It can happen that the proposed solution won't solve the problem, but this wasn't the case. The feedback from the beta user groups was great. The development team tweaked a few bugs and performance issues and after three months it was publicly released.
07 Conclusion
What could be better?
I didn't have a chance to conduct the deep discovery research and we didn't even have any analytics. It meant that the whole team was doing the decisions based on assumptions. Our PM had a deep knowledge of the customer needs, but it isn't an ideal practice to rely on the opinions of one person.
It isn't an ideal practice to rely on the opinions of one person
When it came to the user testing it was the same story. I didn't agree with this approach at all, but sometimes you need to adapt to be able to deliver the design for your team.
All information in the case study is my own and does not reflect the views or opinions of SolarWinds.