Making a better user experience for using technical documentation
A UI/UX design challenge and solution
Click here to view the prototype.
This case study is a solution I recently designed for a UI/UX challenge at the Juniper Networks interview. Nowadays, too many design challenges and case studies are about working on something already popular: a running app, a travel webpage, or a music app re-design. On the contrary, I don’t see many designers care about the user experience of technical tools, such as documentation and tech library. However, engineers deserve better-designed tech tools, just like runners deserve a better running app. More attention is needed to improve their experience.
“Users complained about information being circular and redundant in places, being poorly organized. Not being able to locate the right information again surfaced in their myriad complaints. It seems the findability problem just wouldn’t go away.”
“How can we help users find what they’re looking for in our documentation? How can we eradicate this problem once and for all so that users can locate the right information quickly and efficiently, without so much hunting, scrolling, and fruitless searching?”
Juniper Networks is a highly technology-driven company whose clients are mostly large cooperates. Most users of Juniper’s products are engineers, which explains why it cares so much about improving the experience of technical tools. While other tech companies rarely notice the importance of good tech documentation experience, Juniper has already started building a team to design a new guidance system for technical documentation. After talking to the design team at the final on-site interview, I was impressed by their goal and ambition. I believe their product is the cutting edge of the field and will be well-used in the future. And this is the reason why I love this design challenge and I’m very happy to share the solution I finally came out.
Design challenge
Introduction
Help via technical documentation is a necessity for many enterprise products. This “help” includes documents like installation and deployment guides, user manuals, solutions guide, release notes and more. While important, these documents are often difficult to use due to their length and scope.
Task and scope
Assume you have a set of technical documents for a complicated software product. Design a solution to make an access and use of these documents easy and enjoyable. You can create a website or app to show what you would do to gain user interest. Please complete this exercise in one week from the time of receiving it.
My solution
Understand the challenge: Problem
Technical documentation is important for the software engineering team. It provides an insight into the system’s architecture and a reference during maintenance and bug fixing activities. It helps new members to catch up quickly, and helps external viewers to understand the product.
But technical documents can be difficult to access and use, because of their length and scope. Sometimes users may find a document is not well named, an article is too long to scan, or the navigation leads to nowhere. Tech writers and document users may have different goals: to cover everything vs to solve one problem. They also have different knowledge of the product: very familiar vs. very first time.
Define the users: Research
I started the user research with questions like Who are they? How do they interact with technical documentation? What’s happening to them? How do they feel about it?
After researching I found the users of technical documentation could be: Internal engineer teams reviewing the system architecture, fixing bugs and making updates; New team members trying to catch up; External engineers from customers looking for a solution; Even potential customers shopping for products. To better understand them, I looked into their goals and needs.
Goals and needs
The goal is to make a better user experience for finding and using a set of documents. What makes the access and use of documents easy and enjoyable?
Users are looking for a well-organized doc system, where the documents are properly named, categorized and located. The site map should be well-structured, the interface should be nicely designed and contents should be well laid out.
They also need good navigation. The path to a certain doc shouldn’t be too long or too hard to find. The way-finding process should be quick enough so users don’t get bored and give up. Users should always know where they are and where they can go next. And of course, they can always go back by one click.
If users only have a rough idea but don’t know which document to look at, they need some help to get started. Some guides and suggestions would be extremely helpful.
Personas
Based on the research and user analysis, I identified our potential users by sketching out their demographics, goals, needs, and struggling points. The first persona represents users who don’t know which product to look at. The second persona represents users who are familiar with the product and the documentation but don’t know which document can help with their issue.
Click here to view the prototype.
Final design
Idea
I’m pretty sure that the engineering team at Juniper Networks has done a great job creating the documentation. The Juniper documentation page looks well organized and easy to navigate. I believe it’s not difficult for experienced engineers to find what they want. They’ve been diving in the docs for a while and they know their products very well.
This design is to provide a solution for users who are not familiar with our products, new to our documentation, or don’t know what document to look at. To make accessing and using documents easy and enjoyable, I provide some guidance to them by giving examples of how other companies are using our product to solve similar problems. For example, a Hulu manager may want to see what products Netflix is using to build a network; a UC Berkeley engineer may wonder how Stanford University is using a service to solve a certain problem. Instead of trying to figure out which product or service to pick, reading a peer story is much easier for our user to get started. And it’s more likely for them to find the right solution they are looking for because companies in the same industry usually share similar goals and needs.
Flow map
The user flow illustrated what happened to different users. This solution is represented by the second path (the lower half of the flow map).
Wireframes
Homepage: a quick start for first-time users
Users who are familiar with the system or already know the target product can start with “ Documentation”, located at the header. It will direct to a library of all products from A-Z. Please see the documentation page of Juniper Networks.
Client stories: find inspirations from peers
Case study page: problems, products, and solutions
Product page: a set of documents
Another guidance users may find helpful on the product documentation page is that I added some brief introduction for each section, so users can have an idea of what each section is about before they jump into individual documents. By doing this, I’ve turned an index into an article. Feedbacks are asked at the end of each session to better improve the user experience.
Style guide
To keep the coherence, I used the same font and theme colors on Juniper’s website. I've also adopted some of Google’s material design guidelines. Product information and user cases are found at Juniper Network web: https://www.juniper.net/us/en/.
Click here to view the prototype.
