Oasis

Preface

The Help Centre is an extension of the Ecomz website project that I discussed in a previous listing. If you want to go through that project, you can find the project here.

The Ecomz website was live, but we needed to turn our attention towards the Help Centre. My job here was to make sure that the help centre was in line with the new brand experience, and more importantly: Make sure the help centre was actually useful.

I had three key focuses:

  • Get the Help Centre on-brand.
  • Provide a customer support channel for our users.
  • Allow all information to be easily accessible.

Overview

If you've been following along from the SaaS project, you'll find it comes as no surprise that I once again found myself in a situation where there were no free developers available.

The initial designs for the help centre were poorly implemented by a developer who frankly didn't have the time to go to the toilet let alone take care of the website. I place no blame on him for the final execution, but now that new website was out, there was no excuse for having a poorly executed help centre.

I once again found myself playing UX Developer, or as my colleagues have come to call me: a Unicorn.

Jobs to Be Done

In comparison to the SaaS website, this project was a lot more laid back. I had already set the foundation and design system. In other words, the hard work was complete, and it was mostly a matter of applying the system to a new user flow, and a different set of experiences.

When I first started, I outlined the following tasks that needed to be complete to consider the project complete:

  • Understand how the Zendesk platform works.
  • Design a user flow focusing on helping users find the information they need.
  • Create a fully structured HTML website.
  • Link the frontend to the backend.

Identity

Branding colours

To boost brand experience and recognition, I used the brandmark that we had initially set up for the SaaS website.

Brandmark show casing the colours forming the identity and look-and-feel of the website Brandmark show casing the colours forming the identity and look-and-feel of the website

Typography

The typography used in the Help Centre uses the same typographic scale system I set up in the SaaS website.

I set all the H1 tags in TTSuperMolot to stay in line with the brand guidelines.

The selected typeface for the main header or H1 tag is TTSuperMolot The selected typeface for the main header or H1 tag is TTSuperMolot

Similarly, I also set the rest of the Heading tags and Body text elements in Roboto.

The selected typeface for all body content is Roboto in different forms ranging from light to semibold The selected typeface for all body content is Roboto in different forms ranging from light to semibold

We've finished setting the brand guidelines and showed two live examples. It's important to note that when the company received the new brand guidelines, they only ever received two different font choices, but no identity guidelines.

I documented the Help Centre and SaaS website to enable the Marketing team to use them as brand guidelines. I daresay I did a successful job doing so as I no longer receive questions about brand guidelines, nor am I finding myself needing to forward my comments to the Marketing team.

The Design Process

The Research

Just as was the case with the SaaS website, I cannot share the research details, but I will be sharing blog posts in the future that focus on what makes a help centre useful. I'll be sure to link the posts to this section in the future. The following are some of my findings based on research and qualitative user research:

Criteria

Based on the research I conducted, I found the following criteria I needed to meet to make sure the help centre proves useful:

  • The information has to be easy to find (and accessible).
  • The information has to be structured.
  • We need to tag content with words used by our users in their search queries.
  • The search bar needs to stand out, and we need to prioritize it. The search bar is the main element that will allow users to find the answers they're seeking.
  • The FAQ is the second important element in the website. We can answer 80% of user questions through 20% of our documented answers.

The Wireframes

The criteria established above created the wireframes I needed to get started.

I would prototype my designs directly in HTML/CSS/JS and change them when I ran into problems or when informal user tests pointed towards a different direction than the one I was taking.

If you have a design system and a material library ready, your life will be much easier. In fact, for a related project for the same company, I had set aside two entire weeks to create a robust design and material library to allow future platform improvements to occur smoothly.

Site Architecture

The site architecture or plan is straight forward. I'll probably mention this a couple of times as we go through this, but it's worth repeating it: We need the site to be as simple as possible to allow users to get their answers as quickly as possible.

As a result, the site plan doesn't encourage depth or an overly complicated menu.

For the guide/manual parts of the project, you have the homepage, category pages, section pages, article pages. There's also the community forum which doesn't go deeper than three levels: The forum, the discussion board, and the post level.

I didn't include the Zendesk utility pages such as the account or profile pages since they're more-or-less a given, and I've very little control over them, past their appearance.

Component Design

Navigation Bar

The navigation bar will take on the same form as the one used in the main website to build upon the sense of familiarity. I only changed the menu items to reflect the most relevant elements to the help centre.

Footer

The footer will be the same footer used on the main website. I did not change the footer because I wanted users to have the option to navigate back to the main website.

Category Selection

The category selection builds on a design created for the original website. I wanted to test these specific elements for accessibility. The idea being, if these elements performed better on a screen reader, then I would apply the design to the main website.

Preliminary testing suggest the elements do perform better, and I'm awaiting approval to apply them to the main website itself.

Buttons

The Help Centre uses more of our button library in comparison to the main website. Each button-type has a specific function associated with it.

What's in a button? In simple words: Mental models.

We can take advantage of our familiarity with an interface element and build patterns based on that.

User experience design isn't about "hey, do you like the green button or the red button more?". What's the point of asking that question if your red button sometimes deletes an item, and at other times adds an item? You've created two contradicting mental models that double the mental effort required to recognize if the button will do what you expect it to do.

While it's useful to follow real-world mental models and use 'red' buttons to delete, but it's not nearly as important as consistently using the button. If your red button is a positive input, you should always use it in that context.

Let's take a look at the different button types utilized in the Help Centre.

Call-to-Action Buttons

You use a CTA button when you have an action you want to encourage users to use. That said, you shouldn't be spamming CTA button all over the page since it'll lose its charm. In the context of the Help Centre, the CTA button is the Search button. You could argue the Search button might also work as a primary button, but in this context, I decided I decided that the Search button needs to be prominent.

The first variant of the call to action buttons that will be used on the website along with it's various visual states The first variant of the call to action buttons that will be used on the website along with it's various visual states
Primary Buttons

You use a primary button when the action associated with it involves inputting data into a database/search field or helps users along their user journey. You might use it for commands such as "Save" or "Next".

The primary button that will be used on the website along with it's various visual and interactive states The primary button that will be used on the website along with it's various visual and interactive states
Tertiary Buttons

Use the tertiary button in situations where the action associated with it is not required to complete the user journey.

The tertiary button that will be used on the website along with it's various visual and interactive states The tertiary button that will be used on the website along with it's various visual and interactive states

There are other button types, namely the Secondary button and perhaps the Delete button. I did not need these buttons in the Help Centre, and as a result, did not include them.

Final Designs

Homepage

The homepage goes straight to business. If you're in the Help Centre, you're probably looking for, and you've guessed it, help.

Users land on the page, and the first thing they'll see is a search bar with the title "How can we help you today?". I don't want the users to spend any more time than they had to on the page, because they probably don't want to spend much time on this page either. I want them to come in, get the answers they're looking for, and get back right into their workflow.

As the users scroll down, they'll find the category selection page. This section is useful if the users know what they're looking for but can't quite articulate it in words yet.

If all else fails, the users will find the FAQ section which will more likely than not have the answers for most questions on their mind.

Let's take a look at some of the technical details here.

Category Selection

Zendesk does not typically add an icon for the category section, so I needed to do some coding magic here. In pseudo-code, we needed to assign an icon dynamically to a category.

In code, this would look like this:

              <!--Generate the icons-->
              <div class="hp-category-icon">
              {{#is id 360001443477}}<img src="{{asset '1.png'}}"/>{{/is}}
              {{#is id 360001827958}}<img src="{{asset '3.png'}}"/>{{/is}}
              {{#is id 360001827938}}<img src="{{asset '2.png'}}"/>{{/is}}
              {{#is id 360001830837}}<img src="{{asset '4.png'}}"/>{{/is}}
              {{#is id 360001828078}}<img src="{{asset '5.png'}}"/>{{/is}}
              {{#is id 360001828178}}<img src="{{asset '6.png'}}"/>{{/is}}
              {{#is id 360001830897}}<img src="{{asset '7.png'}}"/>{{/is}}
              {{#is id 360001830977}}<img src="{{asset '8.png'}}"/>{{/is}}
              {{#is id 360001454018}}<img src="{{asset '9.png'}}"/>{{/is}}
              {{#is id 360001454018}}<img src="{{asset '10.png'}}"/>{{/is}}
              </div>

              <!--Card text-->
              <div class="hp-category-text">
              <div class="icon-array-title">{{name}}</div>
              <div class="icon-array-text">{{excerpt description}}</div>
              </div>
            

So what we're doing is the following:

We structure the HTML/CSS to look the way we wanted it to, and then we assign the dynamic elements. There's no way to do this in a completely dynamic manner. We needed to allocate an icon to a section, and then let the Zendesk database take care of the rest.

We do this through this part of the code:

              {{#is id 360001443477}}<img src="{{asset '1.png'}}"/>{{/is}}
        

We're telling Zendesk: If this section is X, then add this image.

FAQ

The FAQ section doesn't come with Zendesk by default. Using a similar method as I used above, I added a condition to an article listing that only showed articles that originated from the FAQ category.

              {{#each categories}}
              // You can stop paying attention after the line below.
              // This is the line doing all the magic.
              {{#is id 360001454018}}
              <div class="row margin">
              //Give it a title connected to a dynamic content called Frequently_Askd.
              //The dynamic content changes text display depending on the selected language.
              <h2 class="h2-style center-text">{{dc "frequently_asked"}} </h2>
              <div class="faq-row">
              //We're dividing content into two columns
              <div class="faq-col">
              {{#each sections}}
              {{#each articles}}
              {{#is @../index 1}}
              <a href="{{url}}" class="faq-link">{{title}} </a>
              {{/is}}
              {{/each}}
              {{/each}}
              </div>
              <div class="faq-col">
              {{#each sections}}
              {{#each articles}}
              {{#is @../index 0}}
              <a href="{{url}}" class="faq-link">{{title}} </a>
              {{/is}}
              {{/each}}
              {{/each}}
              </div>
              </div>
              </div>
            

If you followed along with the Category section, you'll quickly figure out what element allows the magic to happen.

Category Pages

The category page is straight forward. You have a list of sections inside a category and some articles listed under them. You can either go directly to an article's page or explore more listings inside a section page.

Section Pages

The Section page lists articles that are all related to the topic at hand. The page itself is simple and straight forward, and it ought to be that way - Remember: We want users to find the answer they're looking for quickly.

The page does have a code intervention that is worth examining.

By default, Zendesk only lists article titles but doesn't include any of the interior text content. That usually would do the trick if your article titles are articulate. I wanted to err on the side of caution and give users a sneak peek into the articles so that they're confident they've chosen something relevant to them.

I'll admit it was an easy solution, but getting to the answer wasn't. In the spirit of sharing, and in case you also wanted to add an excerpt to your Zendesk article link, take a look below:

              //On Zendesk, you'll find a link such as this.
              //This links to the article's page.
              <a href="{{url}}" class="link section-title">{{title}}</a>
              //All you need to do is create and style a CSS class for the excerpt.
              <p class="section-excerpt">
              //Then add this handlebar in side a paragraph element.
              {{excerpt body characters=150}}
              </p>
            

Article Pages

The article page contains the article's content and related content.

Search Page

The search page is an important page on the Help Centre. As a result, I needed to make sure the information presented in it was easy to read and access. On the backend of things, I had communicated a strategy with the Customer Success team to structure their written content using language that users would use, and using tags that are relevant to make the search function work efficiently.

Community Forum

The community forum allows users to post questions to the community and reach out to other users and staff members. The customer support team had divided the forum into different discussion boards.

Discussion Boards

Discussion boards contain posts related to a specific subject matter.

Posts

Lessons Learnt

The Help Center was a fun project and a quick one, taking no more than three days to complete. The project allowed me to take on a purely code-driven approach towards design, and I was more than happy to do so.

If this project highlighted anything, it's the importance of design systems. Since I had already set up a material library and a design system, my workflow was smooth and fast.

Projects like this drive home the idea that it's crucial to design like an architect. What do I mean by that?

To design like an architect is to design with the whole picture in mind and the details. In other words, you need to design the forest and the trees inside the forest and understand how they work together.

In other words, when you give a design to a developer, you need to understand if what you're asking for is feasible. By understanding the micro-details on a macro level, you'll take out the guesswork.

Final Thoughts

It's crucial to understand how to design pages/apps not from a user perspective alone, but also a developer's perspective. You don't need to know how to code things yourself, but understanding how code works will allow you to be systematic about how you hand-off your designs.

In this specific situation, I was the designer and the developer. I designed knowing I would have to apply my designs, which greatly influenced how I approached design/technical problems. I was also able to fill in the gaps in terms of available developers. By getting my hands dirty with code, our developers were able to focus on the platform itself.

In many ways, your designs have two very different audiences: Your users, and your developers/executors, both of which you need to cater to differently. Your users need your elements to fit together, while your developers need to understand how things go together.

This project is an extension of the SaaS Website.

You can find the SaaS website project here.