In-app Knowledgebase 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.
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.
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.
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.
In-app Knowledgebase 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 knowledgebase 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 Knowledgebase articles include Search, Adding Multiple tags for articles, and a Centralized repository for maintaining knowledge articles.
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, the users need to refer to multiple documents from multiple sources. At some point in time, it becomes difficult to create and maintain documents when working in a shared environment.
BizTalk360 has a basic Knowledgebase portal, where users can create and read knowledgebase articles. But the challenges in the current system are
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
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.
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.
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
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 Knowledgebase 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 Knowledgebase Article feature.
In the old application, the knowledge article can be created only in the knowledge base portal. In the proposed solution, the user can create the knowledgebase 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 its 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.
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 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.
After shipping this version, we tested the developed feature with the target audience and the in-house BizTalk experts. From the feedback received, we found that the users enjoyed the option of creating knowledgebase articles within the grid records with the auto-fill feature rather than navigating to the central repository to create and modify articles.
