Help Content Delivery

I lead the UX engagement with the technical writing team to determine how best to deliver contextual help to end users. 

Objective:

Currently, desk users have a hard time navigating the technical support ticketing and knowledge base article systems. These are stand-alone applications that require users interrupt their workflow in order to access. This project was a first step in identifying how users are currently interacting with tech support and the KB article repository, as well as the most intuitive way to access these resources within the applications they use. 

Methods: 

In a collaborative effort with the technical writing team, we created design concepts that would test two ways of delivering contextual content. I digitized these design concepts, and we invited 6 users of varying tenure lengths and locations to provide feedback during usability sessions. One session was in person, and the rest were remote due to time constraints. 

Option 1

This design was meant to test how useful and meaningful it would be for users to have help delivered via a pop-up modal window. the screen behind the modal is a mockup of a current screen. 

This screen would be accessed by the orange question mark at the bottom, and would deliver information on recent changes to the system, links to various forms of help content (step-by-step instructions, videos/animated GIF instructions, printable instructions), and troubleshooting suggestions that are based on the screen the user is on. 

Option 2

This design showed the same help content as Option 1, but instead of a pop-up modal window, this would open a new tab in the application which the user could either toggle with the current screen or break away to another monitor to look at both screens at once. 

This screen would be accessed by the "Help" text in the upper right corner, which is where users can currently access generalized help in the application. 

Error message

Aside from the delivery method, we also wanted to test a new way of presenting users with error messages. The current error message has the name of the error in a pop-up window with a simple "OK" button to dismiss it. 

This new error message provides a link that would open the help content directly instead of forcing the user to copy the error type and open an entirely different application to access troubleshooting, technical support, or knowledge base articles. 

Outcomes:

Users overwhelmingly preferred the modal method of help delivery. They commented on the fact that the modal felt much more contextual, like it would pertain to the screen they were currently in. Other reasons included: 

• Speed of modal vs. a new tab: no need to break apart or click back and forth. 
• Ability to move around and see what's in your current screen. Not inhibiting workflow was very important. 
• Having help close to what the user was currently doing is more efficient and easier. 

Users also much preferred the new error message. When presented with the standard error message, one user exclaimed, "Oh! That's scary!" When shown the new one, we heard things like, "Oh, boom! Help me fix it. It's right there," and "Finally, some empathy!" "It's not so cold... sounds much better." 

This project was turned over to the stakeholders as they review resources and budget to see how we can incorporate this user feedback into a solution that will provide value to users by bringing them help where they are as well as what is technically feasible with their legacy applications and current tech stack.