Today, we officially launched a whole new Help Center experience here at Designlab!
We wanted to share some insight into the internal design sprint that led up to this launch, and in this post you'll learn about the steps we followed to make this project happen over the past couple of months. We'll also share 5 key lessons that we took away from the experience. This is a chance to see some of our behind-the-scenes work, and maybe get some pointers for your next helpdesk design project!
You might think updating a website’s Help Center is straightforward, but if there’s one takeaway here, it’s that the project was surprisingly wide-ranging. In fact, it required collaboration from literally every member of the Designlab team—and brought in design thinking, copywriting, visual design, UX design, customer experience/service design, dev/engineering work, content marketing, and more.
Austin Basallo, Ops Associate at Designlab, led this project. Read on for his take—which is a case study in how a solid process can allow both business and customer needs to be met more effectively and efficiently, ultimately working to everyone’s benefit. You can also check out the main announcement here.
Step one: identifying and understanding the problem
At Designlab, we’re design educators, so we’re used to seeing things through a problem-solving lens. But we’re also a company, run by a relatively small, tight-knit team. And when the focus is on day-to-day running of the business, it’s easy to miss problems that are hiding in plain sight.
When I joined the company a couple of months ago, in August 2018, I was hired to help improve some of Designlab’s internal operations. In all honesty, I didn’t expect to discover a “quick win” quite as quickly as I did—but it was immediately clear to me exactly how big a problem we faced with our existing Help Center.
This wasn’t about the Designlab support team, who are fantastic—their work gets impressive customer feedback across the board. Instead, this was about how our systems were failing to give our support team the backup they needed.
When trying to understand a problem, I find the first step is often identifying and understanding the symptoms of a problem. In this case, we were faced with two particularly painful ones for our support team: unsustainable support case volume, which in turn led to slow ticket response time.
Our support team was inundated daily with support tickets requesting basic information, and because our support staff was having to field way more inquiries than they should, our response time across the board was poor.
The problem that these symptoms were indicating actually resided elsewhere, in a little-known corner of the Designlab website called the Help Center.
From my experience with other sites, I knew that many brands make their Help Center a priority, both in terms of its visibility on the site, and in terms of the information it offers. Why? Because it’s the first line of defense against an overloaded email support system (see above) and—more importantly—because it connects users to the information they need more quickly and efficiently.
Our Help Center was in poor condition. First, the content simply wasn’t comprehensive enough, and therefore wasn’t capable of answering customers’ common questions. On top of that, the information that was there was often outdated, it was hard to find the right article, and—to put a cherry on top—its visual design and user experience were also rough.
Identifying and understanding the problem was the first step. Next, we needed to devise and deliver a solution. We also needed to do it quickly, since each month with the existing system meant a suboptimal support experience for customers.
Step two: problem-solving from a content perspective
So we embarked on a kind of design-and-content sprint to address this problem. The high-level objective was clear: to make the Help Center the go-to resource and first port of call for people with questions at any stage of their Designlab experience.
The next step was to make sure that we understood who the Help Center was really for. In our day-to-day conversations within the team, we tend to talk about “students” in general terms, because they are who our business exists to serve. But in reality, Designlab has a number of different user groups with distinct needs. These groups include:
- Current students
- Prospective students
- Alumni (Graduated students)
- Mentors
- Career Coaches
- Prospective mentors
- Internal staff
I connected with every person on the Designlab team who answers support tickets from members of these user groups. I wanted to find out what kind of tickets they saw most often, and what specific questions they found themselves answering repeatedly. I had learned that the team had developed a library of macros and other copy-paste or rote memorization coping mechanisms in an attempt to maximize efficiency. This readily provided a basis for new Help Center articles.
Developing a new icon set for content categories
The first task was a massive content update to ensure that the most important questions to these user groups were properly answered.
In some cases, the knowledge lived in a team member’s head. Sandy, our Mentorship lead, went out of her way to write an incredible 13 page document addressing every single mentor concern she could think of. Gina also created a “Knowledge Base Backlog” where she primarily began recording all tickets that came in that should have an article; in this way we could have a targeted approach as time passed.
While other team members were putting these contributions together, I set to work reviewing all old content, updating and editing it for relevance and accuracy, and creating a tracking sheet to make sure that we wouldn’t lose control of those articles again in future.
Step three: problem-solving from a developer perspective
We knew that, towards the end of the process, the new Help Center content and design would be handed off to our dev team to implement on the site.
In preparation for this, I had a call with CJ (our awesome software engineer) to understand the constraints of our existing integration with Zendesk. CJ wanted to understand whether our aspirations on the content and design front could be met by Zendesk’s API, and how viable some of the feature requests would or would not be to build.
The upshot of that conversation was that most of what we had in mind would be possible within the current configuration—the only real change would be to the top-level categories. There was a limit to how “deep” the category breakdown could go. Specifically, this was three levels: Main category, sub-category, sub-sub-category.
These initial wireframes helped us think through content structure
Our draft content already went way deeper than this, so my main takeaway from the call with CJ was to reorganize and flatten out our working content structure.
To accommodate this constraint, we devised a new system that would stick with our existing “Prospective students” and “Current students” idea, but would also introduce the course type at the top level to reduce the number of levels. Therefore, there would be a top-level category for “Prospective short course students” and “Prospective UX Academy students”, etc.
On top of that, it became obvious that Mentors and Career Coaches should be able to access Help Center support through dedicated top-level content categories.
Step four: problem-solving from a visual and UX design perspective
From a business point of view, the point of this project was to increase people’s usage of the Help Center, allowing them to get quicker answers and reduce the creation of email support tickets. So it stands to reason that we needed to create a design for the Help Center experience that would be visually engaging, highly usable, and ultimately inviting. Ideally, it should be an experience that people were positively attracted to and would want to repeat.
I was asked to kick off the design process by drawing some wireframes for what I intuitively felt the Help Center experience should look like (see GIF above). I’m not a trained designer, and I know it’s relatively unusual for someone not on a design team to get involved with wireframing.
But in this case, it made sense both because we were trying to get the project moving quickly, and also because I was able to bring in some usability expertise from my experience of other sites. For my wireframes, I drew heavily on other Help Centers that I knew did a very good job—for example, Asana and Airbnb.
I handed these wireframes over to Patrick, our lead designer, and he worked with our design team to create high-fidelity mockups and iterate on the design through several versions. I worked with Patrick, Harish, Andrew, Madi, and Annie to develop these further.
Working through iterations of the Help Center homepage
Combined with those dev constraints just discussed, tackling the visual design also made me realize that we would need to take firm decisions on categorization for all Help Center content. Madi, Gina, and I conferred and put together a doc that helped us decide where each article would belong in that three-level category structure.
This thinking was an important step, because our decisions here would be responsible for guiding the user to the information they needed.
Rightly, the design process here ended up being quite involved, and we went through multiple designs trying to find the right visual solution. We ultimately settled for splitting the top level of categories into resources for prospective students, current students, and mentors.
Ultimately, we ended up with what I believe to be a pretty slick design that represents our abilities as a company. The bite has to match the bark!
Step five: launching, and letting people know
Here’s a video of the Help Center experience, accessed from the Designlab homepage. Why not check out some of the articles yourself? We curated some interesting ones over in the main announcement!
Of course, there would be no point in us doing all this work on improving the Help Center if we didn’t also let people know that it had happened—which is why you’re reading this blog post. Towards the end of the project I reached out to WIll, our growth lead, and Andrew, our content editor, to see how we could go about publicizing this shift in how Designlab handles support—and to communicate the increased value and usability of the help resources we now offer.
This turned into a mini design process in its own right. We identified a key user group—consisting mainly of students already enrolled in courses—who had already learned an email-based way of accessing support. We could alert that user group directly through the course platform, or through our in-course emails.
Then came the wider community of Designlab subscribers. The main use case for this group would be finding out information about courses prior to enrolling. We could reach them by tweaking the content in our existing email series, and emailing out an announcement.
Then came people who are not currently engaged with Designlab but might arrive at our website and have questions. For this group, our priorities were to ensure that the Help Center was more visible and accessible within the site itself, and also to create some public-facing content (like these blog posts—meta) that would help to communicate the new system’s value in answering their questions.
And, of course, we finally added a “Help” button to our main nav bar! 🎉
Step six: ongoing optimization and improvement
One of the issues we noticed when analysing the old Help Center was how outdated some of the content had become. And it’s tempting, after a high-energy design sprint like the one we’ve just followed with the Help Center, to sit back after launch day and think “job done”.
In truth, though, the Help Center is only going to be an improvement on the old system if we ensure, on a daily and weekly basis, that every aspect of it continues to meet user needs. This means making sure that the content is up-to-date and reliable. It also means keeping an eye out for gaps.
There will certainly be tickets that continue to come in via email on certain themes because people can't find the information they need in the Help Center. We will need to use our internal analytics processes to make sure that these themes are identified, and that new help content is created where it’s needed.
And Finally: 5 Lessons From Our Help Center Redesign
Lesson 1: It’s only possible to start solving a problem once you’ve realized that the problem exists.
Once we identified the Help Center as a big problem for Designlab, the solution became pretty obvious. But the problem and its importance must have spent a long time not being obvious, because it spent a long time languishing without any attention while the support team struggled.
Faced with the symptoms described at the start of this post—high support case volume and slow support response time—some companies would shoot the messenger by blaming the efficiency of support agents themselves. The best defence against this kind of unfairness is surely to be constantly vigilant to potential problems and blockers that might be hiding in plain sight and silently making work difficult for your team.
Lesson 2: Don’t be afraid to say what you see–a newcomer’s outside perspective is extremely valuable.
I was able to identify this problem not because I have any special skills, but because I was a newcomer to Designlab, and seeing things for the first time. I didn’t expect to be able to tackle a quick win like this so soon, and it’s been a fun process.
Luckily, though, I’m not someone who’s afraid to speak up—and I suppose I was able to get this project off the ground by communicating to the wider team in no uncertain terms about how big of a problem I thought the Help Center was. I was still a little apprehensive about being quite so upfront about the shortcomings of my new employers’ customer support systems just a few days after joining the company. But I’m glad I spoke up, because the company listened and allowed me to run with this project (thanks, Designlab!)
This was still an important lesson, though: that the “outsider” perspective that a new member of a team brings can be a real asset if it is embraced. After being within a team for a few months or years, it’s only natural—in fact inevitable—that you’ll get an insider’s perspective and be unable to see things as an outsider does, or even as a loyal customer does. Going in search of these outsider perspectives wherever possible is surely crucial to being able to identify the real problems you’re facing, and therefore to be able to move towards solutions.
Lesson 3: “Design” is bigger than visuals
When I was asked to do those sketchy wireframes, at some level I still had a concept of “design” as “pretty stuff”. This project has, at a stroke, made me realize that design is (or should be) much bigger than that.
The true design process here wasn’t just making a beautiful layout for the help pages, but in researching the relevant user groups for this project, in mapping out their different needs and journeys, and in making sure that the eventual visual designs actually met those content needs and allowed them to find the information they needed in a user-friendly and intuitive way.
Fantastic visual design is one aspect of usability, but the real scope of the design process extends to shaping the whole customer support and brand experience.
Lesson 4: Success came from whole-team collaboration
Reading back through this post, I can see that pretty much every single member of the Designlab team has been mentioned somewhere by name.
Drawing on the strengths and knowledge of the team allowed us to gather people’s insights rapidly, divide up the work appropriately, and ensure that the solution we came up with was actually deliverable. If we hadn’t collaborated in this way—for example, by not engaging with dev team until the very end—then we might have created fantastic content and beautiful visual and UX design, but then discovered that none of it could be implemented because of technical constraints we hadn’t found out in advance.
Lesson 5: Embrace constraints
The constraints in this project came in many forms. First was a self-imposed time constraint. We put this in place because we knew that every month we were burning staff time on unnecessary support tickets. And, worse than burning staff time, we were also giving customers a sub-optimal support experience. It was therefore a priority to get this sorted out sooner rather than later, and delaying came with both real and opportunity costs. There were other constraints, of course—most obviously those technical ones of working with the Zendesk integration.
The most important constraints, though, were those that caused the project to happen in the first place: the constraint on staff time to answer support cases, and the constraint on the customer’s patience when it came to waiting for a response from us. Ultimately these resource constraints are what prompted us to build a support system that will end up serving both customer and business needs much more effectively.
Explore the new Help Center experience!
The new Help Center is now live, and we’d love you to get your feedback on how we can continue to improve.
Feel free to leave a comment below, or take this one question survey to provide feedback on the new Help Center content and overall experience.
Thanks for reading. Until next time!
.jpg)
.jpg)
