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 ok for this case study.
02 Challenge
How to always know the right information?
OH, where is my installation manual? When it comes to IT management you simply cannot have everything in your head. Why should you? There is a lot of issues, devices, security incidents, people are leaving the company and with them also their knowledge. But what if you could have the knowledge library that will be always handy when you start working on the ticket?
High-level goals- The design needs to be scalable (Template, standalone page, widget, import legacy stuff)
- Knowledge needs to be linked together for quick navigation
- Create a customizable and flexible system
I've joined this project almost in the end because the senior designer, who was leading this project, left the company. I've supposed to do only Design QA, surprisingly it wasn't like that. It is nightmare when you need to redesign a project that is already in development and you know very little about actual user needs or JTBD. Also the project manager left the company. He was the one, who had the vision and after that, the project got even more complicated.
03 Research
How do technicians work?
I've used the data from the research team 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
One widget to rules them all.
From the beginning, there was a plan that we build the template system for the Knowledge base. Same way as we did for the Task management. But when I joined the project, new requirements appeared. The team wanted to build the template system and on top of that, every knowledge should be visible in the three variations. As the standalone page, as the widget on the dashboard, and in the ticket. Does it sound like a crazy idea for the first release? yes, it was.
On the other hand, it meant that we will build just one widget, that will be responsive, but reusable in many places of the app and it will provide still the same experience.
Building the template
I've heard many times that customers want flexibility when it comes to managing IT information. Because of that, we were building customizable dashboards and this knowledge management project followed the same principle. The user could create the new section with a custom layout and use all field types like dropdowns, radio, date picker, etc and reshuffle it with drag&drop interaction. Moreover, you could also define the roles for who the template will be visible or not.
Knowledge article
Based on the template structure the user could create the knowledge article. To help users organize it even more we provided the tagging and defining whether the article will be visible for IT technicians or also for the customers and which one. Every article could be linked with another one. So you were able to jump between the knowledge back and forth and find the information you needed. Every article could be assigned with a specific device type. For example, once you opened the ticket you could see the all assigned article for this device or device type.
Ticket views
Imagine that you were assigned to the ticket, you checked the description and now you have no idea how to solve this issue. Luckily for you, someone before crated the article where is everything explained. So you can open the right sidebar with the assigned article Quite handy right? Or you could search another article via search if you needed. I wanted also to provide suggestions based on the ticket type and link devices, but this wasn't feasible at that time.
Knowledge widget
A knowledge widget was used in the dashboard. It wasn't just the place where were visualized the aggregated information. It was a workspace where you could compose your application as you wanted. In other words, you could have one or more widgets in one place that were interacting with each other based on the actions. I will describe this in another case study.
Do you want to link the knowledge with each other? Just drag and drop it to the knowledge you want to link it with. You could see one of the linked knowledge in one widget. It was open as the new tab. It is the same pattern as in the browser, it gives you the ability to have more articles opened and check them once you need them.
IT technicians usually had two or more wide monitors to see much information in one moment. To leverage this fact I've designed a quick linkage that could be done via drag& drop.
-
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
05 Advance knowledge type
Credentials and secret information
The expiry was a special type of information that had an expiration date—warranty, license. So once the item expired the user IT technician got the notification and it was highlighted in the list of expiry items.
Sometimes you need to store the access passwords, serial codes, licenses, or other secrets. Via this new knowledge management system, the user was able to use confidential information and encrypt it. Only the colleagues, who has known the secret or who were in the dedicated user group, were able to see it.
06 Feature adoption
How to get it to the user?
The development is not for free and adoption is a critical part of the digital product lifecycle. Therefore I wanted to increase our chances with the following improvements.
The first small indication in the navigation supposes to tell that there is something new. It engaged the user to see more. Once the user would go to the detailed page, the onboarding dialog would be automatically opened with the explanatory video. It could have been used also at the moment when the user opened the legacy knowledge item.
I proposed having a few templates in place as an example. The page wouldn't be empty and it would help to learn all the possibilities and adopt the best practices.
07 Conclusion
What did I learn?
This project gave me a huge lesson on how to get the project out of the chaos and what to expect after the design colleague left. If the vision is clear, the objective is set, then you should be fine even if your colleagues left. If that is not clear then you can expect problems.
Making the feature available in the production should be the beginning not the end of the team work. You should do everything that you can to make sure that users can and will adopt it. We as the team weren't focused on this type of product work.
Making the feature available in the production should be the beginning not the end.
We shouldn't work on a big project for sake of releasing something. We should have a deep understanding and everyone in the team should be sure of what are the user needs.
All information in the case study is my own and does not reflect the views or opinions of SolarWinds.