IMPROVING USER FEEDBACK ON DOCS

UX DESIGN  |  APRIL - AUGUST 2017

 
 
 

My role

IBM Cloud Documentation is a technical manual for users to learn and reference information about IBM Cloud applications, infrastructure and services. The content development team uses a third party service, Usabilla, on the documentation pages to collect user feedback

My role

My role as a UX Designer was to research the current landscape for receiving feedback collaborating with the lead designer and content strategy manager to design a solution that could help both users and content teams.

 
 
Cover Copy 2.png
 
 

THE PROBLEM

WRITERS DON'T KNOW THEIR RESPONSIBILITY TO FEEDBACK

A Github issue is automatically created and assigned to a writer every time a user leaves feedback on a doc. Since writers are not a support role they don’t know who is responsible to communicate how the feedback was received to the user. This creates no accountability for writers to respond and prioritize feedback issues which created an extensive backlog of unresolved issues. 

Pain points:

  • Writers are unclear of responsibility 
  • Unresolved issues contribute to low NPS score
  • Users leaving feedback are kept out of the loop 
 
blank.png

Needs Statement

Content writers need clear direction on how to approach customer feedback while not overstepping technical support in order to learn where to take action for improving the doc and how to prioritize it. 

 
 

RESEARCH

THE NEED TO UNDERSTAND INTERNAL PAIN POINTS 

 

I wanted to understand the pain points for both users leaving feedback and writers assigned to feedback. I started by combing through responses collected during the first quarter and grouped them into categories such as dated or error. 

Goals of research:

To learn about the relationship between content writers and the users leaving feedback so I can better understand barriers and positive situations for follow up. To learn about content writer's interaction with Github so I can understand how issues are prioritized and followed up on.

 
blank.png

An interesting finding was that 43% of feedback was made by internal users. With nearly half of responses made internally, it became evident I also needed to learn more about our internal needs. I interviewed seven writers and seven internal users who left feedback. 

 
 

RESEARCH FINDINGS

CLEAR NEED FOR ACCOUNTABILITY

Users wanted to see if others were experiencing similar problems. They also genuinely wanted to understand how their input influenced content updates and changes. The need for visibility was crucial for internal users such as support because they can not effectively help customers with incorrect documentation. 

Content writing teams need specific direction on how to respond to users. Since issues are generated into an overarching docs repository, they purposely duplicate issues into their their personal team repositories which becomes problematic having multiple issues to upkeep in different spaces. 

 
 
 

IDEAS & CONCEPTS

A FOCUSED RATING SYSTEM

My lead and I used brainstorming sessions to map out pain points and define areas of opportunity that could help both internal and external user needs. 

The most promising idea was stripping the feedback form to a thumbs up or down rating system. This would provide clear direction for teams to focus and measure which doc was helpful or not helpful. 

An added component would be opening Github to a public facing repository to create further transparency for both internal and external visibility needs. It will provide all users with the ability to open issues for in-depth feedback and track its progress. 

 
 
 

CONCLUSION

STRIPPING DOWN THE FEEDBACK FORM

Based on my research and findings, my team recommended the stripped down feedback form along with a public facing Github solution. The simplified form allows content teams to get direct insights to doc articles that need attention. The anonymity of the form would encourage users to give their honest opinion. The ability to raise and track issues through Github would bridge visibility to internal teams and potentially decrease costly support tickets. 

 
 
 

NEXT STEPS

MEASURING SUCCESS

We plan to prioritize implementation with our dev team for next year. To measure the success of the design, we need to track rating trends thorough analytics to observe how users are interacting with the stripped down form. We also need to track public Github usage and observe the relationship to the amount of support tickets opened. 

Hypothesis:

I believe if we provide a way for the IBM Cloud user community to engage through open feedback, it will hold content writers more accountable allowing an increased turnaround to questions and decrease the amount of support tickets.