Improving the Help Functionality on WordPress.com

Help Functionality

About this project

Thousands of WordPress.com sites are created each day. As a result of the product growing even bigger than it already is, it has also become more complex, with users oftentimes having difficulty in finding certain sections and functionality.

When a user accesses the Help functionality via the Help FAB (Floating Action Button) and types in a query, in addition to Help articles populated in the results, quick links to pages and sections within the product have been added. The goal here is to ease the user’s navigational path.

Role

  • Flow mapping
  • Wireframing
  • UI and visual design
  • Research and user testing
  • UX auditing

About this project

Thousands of WordPress.com sites are created each day. As a result of the product growing even bigger than it already is, it has also become more complex, with users oftentimes having difficulty in finding certain sections and functionality.

When a user accesses the Help functionality via the Help FAB (Floating Action Button) and types in a query, in addition to Help articles populated in the results, quick links to pages and sections within the product have been added. The goal here is to ease the user’s navigational path.

Role

  • Flow mapping
  • Wireframing
  • UI and visual design
  • Research and user testing
  • UX auditing

What are the problems with this approach?

  • The user is unable to understand the difference between the 2 sets of search results (Help Articles and Quick Links). After clicking around, they may eventually figure this out, but as Steve Krug’s book says it, “Don’t make me think!”
  • Icons precede each Quick Link in an attempt to denote that they are strictly navigational, but they don’t add any value. The icons don’t mean anything; the user will not be able to remotely make a connection.
  • Most importantly, Help Articles and Quick Links are “one and the same.” What does that mean? When a user searches for a query, we don’t know what their intent is – either they want to learn more about something, or they want us to show them where something can be done. While the original design attempts to cater to both intents, the way the results are separated only facilitates confusion. The hierarchy of how they are ordered suggests that one is more important than the other.

But wait, there’s more (problems)!

When a user clicks on a Support article link, before taking them to the full article, they would have to click through an interstitial screen that acts like a “teaser” before being served the full article. These are absolutely unnecessary.

With all of these said, I’m be happy to be proven wrong so I conducted some user research.

User testing

Through user testing, I was able to validate my hypothesis – users were having a hard time understanding the difference between the two result groups.

General feedback from users resulted in a common theme:

“I don’t believe there should be any difference as both the “Support Articles” and “Quick Links” can offer the same kind of advise.”

“Show me where to” is lost, I didn’t really see it.”

“I have no idea what I have to do – this is way too complicated.”

Collaborating with Support Teams

To further validate my hypothesis, I reached out to Happiness Engineering (WordPress.com’s Customer Support Team).

“We still get an average of 230 tickets per week from users who need help setting their Primary Domain. This looks to be something simple to do, but users still have trouble finding this setting.”

However, we hit a roadblock…

In order to provide the most optimal solution to the problem, our Help Documentation will also need to be updated. Our support documentation pages are severely outdated – old screenshots that don’t reflect the current state of the UI, inconsistent formatting, mentions of sections that no longer exist, amongst other things.

Each support document that mentions a section or page within the product should include its corresponding navigational path that will then take users to the appropriate location; and all of these should be written in uniform format so they are easily distinguishable from all other types of links – i.e., the user will know what to click on if they want to head over directly to a certain page or section within the product.

Good content is good UX.

…but we’re in luck!

This wasn’t going to be an easy feat. Our Support Documentation is massive, and this requires collaboration across multiple teams.

But luck was on my side! I was informed that just a few days back, the company has decided to form a “Docs Guild.” These are Happiness Engineers that will be tasked to update our existing Support Documentation. Previously, no team was assigned ownership of it; anyone in the company would just update it whenever they had the time. This explains its outdatedness.

With the newly-formed Docs Guild, we were able to move forward with my ideas. This couldn’t have come at a better time!

Low to High-fidelity Wireframes

I typically start with low fidelity wireframes. This way, I can come up with several different options faster without getting too hung up on the colors and styling. It can also be shared quickly with stakeholders and members of the team for quick feedback.

Once I had something a bit more concrete, I moved on to create high-fidelity designs, and build clickable prototypes from there.

Proposed solution and Prototype

  • I decided to split the 2 different search results into tabs. This way, they are clearly distinct from each other rather than relying on section headings to create visual separation.
  • Clicking on the links under Support Articles will display the full version within the popover, with the interstitial screen and modal removed.
  • I worked with the Docs Guild to make sure the navigational links are in a consistent format so users know what to look for if they wish to be taken to the page or section they’re looking for.

    Takeaways

    Look beyond the scope

    Sometimes, if time permits, you have to try to look beyond the scope of the project. If the ideas you’re proposing are strong enough, stakeholders may decide it’s worth accommodating. If they decide otherwise, that’s perfectly fine. This will allow you to find the best possible solution before narrowing down to the next best thing.

    Tip: It helps to create clickable prototypes for stakeholders to see rather than just verbally stating an idea; these support and strengthen the ideas you are pitching.

    Talk to your Customer Support teams

    I have learned so much from talking to our company’s Customer Support teams, and I cannot stress enough how important this is with any project. As front-liners for product design teams, they are the best people to know the problems our users encounter.

    A lot of times, product teams are given project specifications, and we spend the entire time designing for the most optimal experience, but we don’t get the opportunity to see how users are using the product in the real world outside of moderated or unmoderated testing.

    The thousands of emails, tickets, Live Chat transcripts coming in from Customer Support are packed with real user insights.

    UX designers need to start having less conversations with each other and interact with more people from different industries and backgrounds. After all, any industry can benefit from the introduction and implementation of sound UX principles.

    William Frazier, UX Collective