Rethinking Documentation

Procedures to tell the ALCF science stories.

 

< Back to Improving How Users Experience ALCF

Rethinking our User Documentation

A week-long deep-dive in UX


BACKGROUND

Our current user documentation for our supercomputers was built in 2011, long before responsive design was a standard and maximum widths were 960 pixels. It was also long before we received a 10-petaflops machine called Mira in 2013, and our 11-petaflops machine called Theta in 2017. Our documentation was built for a machine that was retired five years ago and for a facility that was half the size.


APPROACH

In 2017, I took an intensive week-long, project-based UX course. I used our user documentation as my problem to solve using UX methods. This week gave me the chance to completely separate myself from steady-state operations to focus on figuring out a new ideas and concepts based on human-centered design methods.


RESULTS

 
 
 

Reconnaissance tour of direct competitors

competitor anaLysis

I started by doing a reconnaissance tour of documentation from our direct competitors for government supercomputer funding and other smaller supercomputing facilities located at universities. At the time, I found that all organizations approached  documentation in pretty much the same way. We were all stuck in the same rut and no one had rethought their process to make the user’s needs the center of the problem.



 
 

user research and surveys

Prior to my UX course, I participated and held a series of user focus groups and user interviews. The goal was to find out how early adopters of Theta anticipated taking advantage of its features and what they needed from the ALCF to help them reach their objectives. Time and time again, we heard users pointed back to the frustrations they had with our documentation. I had transcriptions of those recordings to give me insights into real user problems from advanced, well-respected computational and computer scientists. I also had two years of data from our annual user survey.


Excerpts from audio recordings of user interviews


 
 

Feature needs and mapping user stories

feature mapping

Using the transcripts and annual survey data, I was able to map out pain points and frustrations of the users to direct which features were most necessary. A few request that came up several times were:

  • An easy guide to onboard new post-docs and project members.

  • A way to track all the steps they need to take to get their project setup (a checklist).

  • A date showing the last time the page was modified so they could figure out if the reason why something wasn’t working was due to the docs being out of date.

  • An aggregation of “house cleaning” information for Principal Investigators.

  • Video tutorials that were in digestible chunks.

 
 

user flows and wireframes

It is important for me to create patterns of behavior for our users to easily learn while moving through our navigation. Our users are programmers and system thinkers. If I can establish a simple pattern that makes sense, it will simplify the navigating through the documentations and cut down on the amount of frustration trying to find a piece of information that’s need. Our supercomputers are only as good as the documentation that we supply.



Web layouts used to create a prototype of the user support “help center”

Prototype and iteration

I appropriated ideas from help centers from popular, well-designed software to design a support center for our users. The support center provides easy entry into our documentation depending on the skill set of the user and the role of the user. It makes an advanced search front and center and solves some of the most frustrating aspects of our docs.

View the first prototype.

My project was funded and I am working with a team of computational and computer scientists and customer success staff to iterate on my prototype and initial research to build user documentation based on an understanding of our user and what our users need.