Never stop evolving
Loading page . . .
My work Knowledge base

Complete knowledge management, fewer questions for IT team.

Giving MSPs the ability to set up one central place for the IT knowledge base. This makes easy to find answers, tips, and other important info when solving ticket. See how we done it.

  • Timeline
    7 weeks
  • 5 user
  • User
  • 3 created
1 / 4 Solution
Roles & Responsibilities
  • UX, UI, Prototyping
  • Scope refinement
  • Validation together with Researchers
  • Hand-off / Design QA
  • Sketch
  • InVision
  • Cloud app
  • B2B market
  • SMB market
  • Managed services market


I've come up with the design for a customizable and flexible system where IT technicians can manage heterogeneous information. Everything from configuration, manuals, expires, procedures, secrets, and passwords. Each knowledge article can be linked with others for quick navigation back and forth. It can be shown as the individual page in the knowledge library, as the widget on the dashboard, or as the extra information in the ticket.


Having a reliable knowledge base is important for the efficiency and quality of the work of every IT technician. This is usually managed via an external tool or in the notes. By building this feature the MSP Managers becomes more competitive on the market. Knowledge base becomes one of the main unique selling proposition. It had a positive impact not only on user adoption but also on retention. MSP companies could have these articles also visible on the customer portal. This helped them establish Self-service and decrease the number of simple issues.

  • Customer review

    “It's great that multiple people can collaborate on tickets and you have the ability to communicate directly while your customers can follow progress made from the opening to closing of the ticket.”

    Chris H.
    Chris H.
    Security Analyst · Source: Capterra
  • Customer review

    “What MSP Manager really gets to do is help us stay organized and prioritize tickets very quickly. I don’t want my team to worry about managing tickets.”

    President · Digimite technologies · Source:
  • 2 / 4 Introduction
    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.

    3 / 4 Development
    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.

    Feature Information architecture
    Feature Information architecture See detail

    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.

    Building knowledge template

    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.

    Knowledge article

    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.

    Ticket with the detail of the knowledge article

    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.

    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.

    Knowledged with secret items
    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.

    Feature highlight by badge
    Feature highlight by "NEW" badgeSee detail
    Onboarding dialog with animated video
    Onboarding dialog with animated videoSee detail
    Prepared knowledge examples
    Prepared knowledge examplesSee detail
    4 / 4 Grand finale
    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.