A Design Challenge
Supercharging a Help Center
A solution for a more integrated Help and Support community within DigitalOcean's dashboard.
An experiment in redesigning a crucial piece of an ecosystem.
Exploring the challenge.
Years ago when I started trying to learn Rails (pick a time...there's been so many), I needed more access to my server than MediaTemple's shared grid allowed. After a little debating, I settled on DigitalOcean, and immediately fell in love with the scalability of their platform. As a total n00b, I struggled through everything from installing WordPress to setting up NGINX and running my first apps. I had so much trouble with their support community, in fact, that I recorded my own help videos (if you want a laugh, you can watch them here). When the DigitalOcean team tasked me with this challenge, I felt like it was a gift. I could finally spend time trying to fix their support system!
A BRIEF LOOK
The current state of support.
HIDDEN IN PLAIN SITE
From the dashboard, you could access the help center through a modal that pops up when you clicked on the discreet question mark at the top right of your screen. The modal had some cool typeahead functionality that allowed you to quickly find articles, but in order to read the content you had to open a new tab. Not so bad, I guess, unless you're writing code. That leads to...window hell.
When I write code, I have a plethora of apps open. At any given time, I have no less than three tabs spread out across three browsers, Sketch, Coda (or Sublime, depending on what I'm writing), Codekit, Sequal Pro, Spotify, and Who-Knows-What-Else. Adding a tutorial screen into the mix just created more chaos, and often got in the way of my workflow. How could I simplify this?
Alright, so I'm working inside of my dashboard, but I bump into an issue that I can't figure out. Naturally, I would have entered DigitalOcean's support center through the modal and found a helpful article. Cool, a solution! But wait...now I'd have to copy/paste the code back into my Terminal? There's a shell within my Droplet's dashboard, and I'd already have signed in! Could we make this a little easier on me, the end user?
But first, ask.
When it comes to product design, I try to begin from a state that Marc Andreessen describes as "strong opinions, loosely held." After all, my frustration with the support community may be 100% of my own doing! Before putting pencil to paper, I created a Typeform questionnaire and trolled Twitter for volunteers.
Over the course of four hours on a Saturday, seven tweeple completed my questionnaire. I learned a couple of important things :
All seven people have at least five tools open while writing code.
Six of the seven would go out of their way to avoid the support center because of the interpretive nature of its usability.
Six of the seven felt "Very Unhappy" with the usability of the support center.
The seventh person had no opinion about the DigitalOcean support community.
Interesting! Okay...so it's not just me. I thanked my testers and told them that I'd be in touch in a couple of days with a prototype. Time to get to work...
CONTENT PLANNING AND ARCHITECTURE
Planning the integration.
At this point, there were a couple things that I knew for sure. First, I needed to find a way to make it easier to search all of the articles and tutorials housed in the support center from the Droplet's dashboard. Navigation must feel as seamless and interconnected as possible, and the platform should be more assistive to the user. So much ownership is placed in the hands of the admin that the system feels more nerve-wracking than empowering. I wanted to find a way to make that same information more indigestible.
To help guide my designs, I set in place three keywords.
Initially, I explored a crazy fly-out, side navigation. It looked cool, but I couldn't imagine this interaction being usable on mobile devices or, for that matter, accessible to a wide user base. I liked how the link to the support center was tucked out of the way, then entered the view on the z-axis, on top of the dashboard.
Instead, I moved the link to the support center to the left-hand sub-navigation. When the visitor interacts with this link, she'd be able to see context-aware support articles and tutorials on a page within the dashboard. From there, she may be able to search for and open articles without impeding her workflow. There was something to this idea.
USER FLOW AND NAVIGATION
Defining the journey.
Now that I'd paired the new support center link into the Droplet's navigation, I needed to gain a fuller understanding of the user's journey. For the sake of the design challenge, I began from the expectation that the admin is looking for assistance while working within the shell, either through the Droplet's web version or through her native app.
Okay...it felt like I was off to a good start...but for my own sanity, I needed to sketch out the implementation within the current infrastructure. Time to dig up some pencil and paper...
At the time, DigitalOcean used a "Get Help" button at the top right of the screen to open a search modal. The visitor would search for an article, then open it in a new tab. By integrating a "Find Help" link in the dashboard navigation, I hoped to better integrate the support functionality.
THE HELP PAGE
Once the visitor clicks on the new link, we can assume that she's looking for one of two things: help from a person or help from an article. Integrated articles surface first, based on her recent searches and top suggestions based on her server configuration. If she needs more specific help, she could open a support ticket by clicking on a persistent button at the top of the page.
When the visitor opens an article, she's greeted with all of the expected content, but also with an integrated console, already logged into her current Droplet. Now, she can follow along with the article while implementing her learnings. To make education a little more digestible, I included a pop-out Console Help and Dictionary button at the bottom of the integrated shell.
By this point, I was feeling pretty comfortable with my sketches and research. I'd been envisioning the UI for these flows from the start of the challenge, and I could finally dive into creating the interface for testing. I navigated to my droplet and popped open Chrome's web inspector to start replicating the DigitalOcean UI as fully as possible. In order to get the best feedback, this prototype had to FEEL like it could be a functional part of the greater ecosystem, so staying on-brand was crucial.
I created a styleguide from some of the most common UI elements in DigitalOcean's visual language. Throughout the design process, I referred to this tiny document for guidance.
AN UPDATED NAVIGATION
A NEW HOME FOR HELP
Find Help now lives in the left-hand sidebar, along with all of the other droplet-specific actions. The simple but clear language intentionally leaves "Help" ambiguous, allowing the word to spread an umbrella over the forms of content that might be found there, from discussions to tutorials, articles, and support tickets.
ACCESS TO AN INTEGRATED CONSOLE
In my experience, most of the support articles and tutorials include step-by-step instructions that require a dizzying dance between the admin's code editor, Terminal, and the page's content. With just a little beautifying of DigitalOcean's in-browser shell, the admin could implement the content within the tutorial without ever having to leave the page. If she'd rather follow a different workflow, she can simply collapse the sidebar, and hide the shell altogether.
SHELL, LEVELED UP
RUN AUTOMATED SHELL COMMANDS FROM WITHIN THE BROWSER
Many of the tutorials and articles focus on actions that follow an unchanging step-by-step workflow. From setting up new users in NGINX or Apache to installing the latest version of WordPress, the system has the opportunity to automate simple workflows at the click of a button. Not only would this eliminate user error, but it would also help the admin become more familiar with the workflows in a more educational environment.
DESIGN ROUND ONE: COMPLETE!
Test and iterate.
Four hours and almost eighteen versions later, I arrived at an iteration of the interface that I was excited about. The designs were tight and on-brand and the InVision prototype flowed smoothly. It was time to write some user experience testing questions and to schedule some demos with my questionnaire takers.
ON ASKING QUESTIONS
QUICK THOUGHTS ON UET
User testing is a crucial part of the product designer's job, but it can take a while before it feels comfortable. In my opinion, UET (User Experience Testing) is about 21% critical thinking and whatever-else-percent people skills. Oh, and 100% humility, because your assumptions are usually wrong in some capacity.
When I'm writing UET questions, I try to create uninfluenced, organic questions that encourage detailed answers. It's important to avoid leading questions or to use body language, inflection, or attitude to influence the responses of your testers. Usually, I'll plan for this by creating a script, or a pre-defined set of factual questions, to ensure that I don't steer the reviewer in any misleading direction. This data is important!
WHAT THE TESTERS SAID
Final tweaks and last words.
Collectively, the user experience testing was an overwhelming success. My three testers loved nearly everything about the implementation, though all of them commented on how confusing the icon was for opening the shell. I made a couple small tweaks to give it more prominence and sent the prototype and case study away to DigitalOcean.
A short week later, I was walking into their 6th street offices in New York for the in-person interview. After presenting my work, the team suspiciously asked if I knew what they'd been working on for months. I shook my head, and Colin, one of the designers, pulled up the staging version of their community site. To my shock, it included many of the features that I brainstormed here! We all had a good laugh about the serendipity.
Sadly, a week later, Joel Califa (Remember him? He runs the design team over there.) called to let me know that they had decided to go in another direction. They loved the work, but they were looking for someone with stronger development chops. At the time, that wasn't me. Regardless, I'm grateful to have had the incredible opportunity to brainstorm some cool ideas and meet some incredible people.