Case Study

In-app Knowledge Base – Create, Read & Edit articles from anywhere within the application

Organisation: Kovai.co

Overview

In-app Knowledge Article is a feature enhancement to the existing knowledgebase portal in the BizTalk360 application. As data is the major driver, we look at case studies, experiences, customer support calls, customer reviews, feedback from the feedback portal, and pick out problems and feature requests.

The new requirements are presented with stakeholders and then proceeded with the design process. The design process includes multiple iterations within the stages of wireframing, designs, prototyping, and testing – with designs reviewed in each stage.

Role

Product Designer

Timeline

4 weeks

Platform

Web (Privately Hosted)

Tools used

Figma, Invision Freehand, GoTo Meetings

Roles & Responsibilites

I’m the first and sole product designer working for BizTalk360. I take care of the entire design lifecycle right from setting the style guide and all the way to delivering the features and post-release usability testing. My primary responsibilities include setting up the feature roadmap, UX research, creating low and high-fidelity wireframes, mocking up the user interfaces, and collaborating with product managers, developers, and product consultants. I’ve also initiated the Design Quality Assurance process to ensure the developed version matches the designed screens.

Objective

I was tasked to improve the usability of the current knowledge base feature to allow users to create and access the knowledge articles seamlessly across the application. This feature improvement is done as a part of a UI overhaul and UX clean-up of the entire platform.

Approach

I started off with the UX audit of the current platform and conducted interviews with various members of the team including the CEO as he is one of the early-stage developers of this application, to understand the thought process behind building this feature. This analysis phase helped me to understand the user goals, business goals, and various pain points faced in using this feature.

Design Process

BizTalk360 is complex and a decade-old enterprise application. There are legacy users, who will be using the application for a long time but they have only a limited understanding of the breadth of the user. They use specific ways (which might be an inefficient way) to get the task done. There are expert users, who have a deep platform knowledge and uses the system accelerators and shortcuts to complete their tasks. And, there are learners who are domain experts but they are new to the application. These types of users fear productivity loss if we tend to change something that breaks their flow in getting their tasks done. Having false assumptions about these users might end up breaking the existing patterns within the application. Adding incremental changes to a feature should not break the flow rather it should be improving the usability of the application.

Feature Brief

In-app Knowledge Article is a feature by which the BizTalk support professionals can create articles for the problems and solutions they encounter in their day-to-day BizTalk operations. With the in-app feature, users can be able to create knowledge articles right from their current screen where they encounter issues without navigating to other screens and providing additional information. The other features of In-app Knowledge articles include Search, Adding Multiple tags for articles, and a Centralized repository for maintaining knowledge articles.

Problem Statement

In the BizTalk Environment, when something is not in the expected state, it will be reflected as errors and warnings. These errors should be resolved for the smooth functioning of the BizTalk Servers and their associated applications. To resolve these errors users need to refer to multiple documents from multiple sources. At some point in time, this becomes difficult to create and maintain documents when working in a shared environment.

Pain Points

BizTalk360 has a basic Knowledgebase portal, where users can create and read knowledgebase articles. But the challenges in the current system is

Users need to navigate between different screens to create/update/view the knowledgebase articles.

It becomes difficult for the user to find the required article when there are more knowledgebase articles.

Research and Validations

To validate the feature, I’ve collaborated with the Product Support Engineers in analyzing the support tickets and listening to the support call recordings related to the Knowledgebase topics. After carefully analyzing the support cases and feedbacks received from the feedback portal, I planned for a User Interview session with the in-house BizTalk experts and BizTalk users working with large enterprises who will be using the Knowledgebase feature in their day to day workflow.

One thing to always remember while designing a product is You ≠ Users

Hypothesis

Users face difficulties in retrieving the knowledge articles

Users were unable to create articles seamlessly

Adding capabilities to create/modify articles within the feature would help users get a better sense of the feature

User Interview

For this project, I tried the semi-structured interview model. I framed the open-ended questions to allow the participants to talk and the interview continued based on the opinions from the participants. Semi-structured interviews will be suitable if we are looking to learn more about a specific issue or a feature.

No. of participants: 5

BizTalk360 users who are using the existing knowledge base feature
BizTalk360 users who are using external knowledge base solutions or other documentation medium.

Questions

How will you document the errors in the server and solutions for those errors?

What are all the difficulties you are facing in maintaining those documents?

How will you maintain the user access policies for the documents?

What are all the pain points you’re experiencing with the current feature?

User Stories

As a BizTalk Support Professional, I want to create a knowledge article with solutions for common errors and warnings.

As a BizTalk Developer, I want to access the articles right from the feature to find the solution for that particular error/warning.

Ideate

Wireframes

After having multiple interviews with the users and other stakeholders, I conceptualized the idea as a freehand sketch using the InVision Freehand tool. The wireframes are validated with the stakeholders and ended up with the following version of wireframes which are ready to be converted into High fidelity prototypes.

Old vs New version

Old Version

In the existing feature, the user needs to navigate to the knowledgebase portal and select the category to which the knowledge article to be created. After selecting the category of feature, the user needs to enter/choose all the required data like Environment name, Error Code, Application name, etc,.. and then create the article with the required solution. On the other hand BizTalk Developers or Support professionals needs to go through all the articles to find the required article

New Version

Pre-filled data:
The data from the BizTalk server will be represented in the form of grids and the grid columns are unique to each feature. To create a Knowledge Article user needs to provide details like Environment name, Error Code, Service Status, Application name, etc, But all these details are available in the grid rows. In the new implementation, to create a knowledge article users can simply click on the row and all the required details will be fetched automatically. Users can simply enter the Article name and solution for the error and they can save the article.

Centralized Repository:
A centralized Repository is a place where all the knowledge articles are stored and grouped features. Users can switch between different features using the sub-menu on the left. This is a global repository where a user can create knowledge articles in any environment or set the article as a global article common to all environments.

Improved Filters:
The centralized repository is equipped with advanced filter options to easily filter the required article specific to the environment or application or event or any other property specific to that particular feature.

Empty States:
Empty states are the occurrence with no data to display in the application. Here are some of the empty states used in the In-app Knowledge Article feature.

Reusable Components

In the old application, the knowledge article can be created only in the knowledge base portal. In the proposed solution, the user can be able to create the knowledge articles in 3 different ways.

1) Central Repo: The central repo is a place where all the knowledge articles are created and stored irrespective of feature or environment.

2) Within the feature: Every feature that supports knowledge articles will have a knowledgebase icon at the top. Clicking on that icon, opens a blade listing all the KB articles available for that particular feature for the selected environment.

3) Table/Grid records: Every feature will have multiple records in the table or grid. Clicking on that record, opens a blade with KB article specific to the error code for the selected record.

As similar operations are made in different places, the experience for those operations should also be the same so that the user flow will be seamless across the feature for creating KB articles, viewing or modifying the articles, etc. Bringing similar experiences for different use cases has it own challenges in addressing the edge cases like placing a call to actions, user access policies with permission for different users (i.e) only some users have the permission to create or modify the articles, while others have read-only permissions and there are a couple of other edge cases which are more technical based on the selected feature.

User Testing

The job doesn’t end here. Before handing off the screens to the engineers for development these screens were tested with users. After multiple iterations, the high-fidelity screens are converted into prototypes and shared with the users. Here the user testing is carried out in 2 different methods:

The prototype is shared with the user through the mail and the feedback is collected from the users after trying out the feature end-to-end.

A 1:1 meeting is scheduled with the users and in-house experts and asked them to use the prototype, just the way they use the real application to accomplish their tasks. These sessions will be recorded to understand the common patterns and challenges in the new design.

The responses from the customers are captured and added to the backlog. Once the initial set of testing is done, the feedback from the users is consolidated and the common challenges are addressed. These changes are again tested with the users. After the testing, the feature is finally handed over to the engineers for development activities.

Conclusion

After shipping this version, we user tested the developed feature with the target audience and the in-house BizTalk experts. From testing, we found that users enjoyed the option of creating knowledge articles within the grid records with the auto-fill feature rather than navigating to the central repository to create and modify articles.

Learnings & Takeaways

As mentioned earlier I’m the sole product designer working for BizTalk360 and this was a fairly big project with lots of edge cases, user flows and lots of data to be effectively architected in the UI. It felt really tough during the initial stages of the project to collaborate with different stakeholders and convincing them.

This was my first dive into the world of usability testing. Initially, I faced a lot of challenges in getting the right process, recruiting the participants and convincing the management on the ROI of the User Research and Usability testing. I managed to find some good materials to dig deeper in usability testing through nngroup.com articles and interactiondesign.org. Also, spoke with few mentors through ADPlist.org and understood the best practices of usability testing and uncover those challenges.