One measurement of how well we’re helping customers answer their questions is tracking our self-service score. It’s a simple ratio of users in our Support Center versus the number of users in support tickets. For example, a self-service score of 3:1 means that for every three people engaging with our documentation, one opens a support ticket.

This score becomes important as LexBlog opens more parts of our platform to more of our customers. We’re giving users more control over settings such as their sidebar widgets and design colors. We’re also rolling out a self-service website model where users can create, design, and launch their own sites.

As people use these new tools, however, they’re going to have questions. And research shows that most customers would rather find answers to their questions before contacting support channels. For example, American Express reports that “48% of customers prefer to speak with a customer service rep when dealing with complex issues, but only 16% prefer the same contact for simple issues.”

Ideally, as we grow, the number of users finding help through our documentation will increase faster than the number of users submitting support requests. Ideally.

 

Our self-service score over time

Chart showing LexBlog's self-service rate increasing over time.
This chart shows LexBlog’s self-service rate from June 2016 to July 2018. The dark blue line shows the rate for each month. The light blue line is the trendline.

 

The chart above tracks our self-service rate starting in July 2016. That’s when we finalized the transition from the old documentation platform, Reach, to Zendesk’s Guide software. The good news is our self-service rate is increasing over time.

 

How do we boost the self-service rate?

To be clear: self-service isn’t about discouraging customers from contacting us when they do have trouble. Sometimes when things go wrong you just need to hear a human voice. Our support team is dang good at answering questions and putting out fires.

For me, increasing our self-service score means fewer people get to the point where they can’t figure out something.

And while the increase in LexBlog’s self-service rate is good news, I think it can get better. Here are some ways I want to help our customers through better documentation:

  • Continue monitoring search query results reports to see what our users are searching for.
  • Deleting content that users don’t read. Unread articles clutter up search results and make it harder for customers to find what they really need.
  • Create a smoother onboarding process for new users. This includes guides written for brand-new bloggers.
  • Analyzing the path of users through help content. This will tell us where they’re getting stuck.
  • Let the robots help. We just implemented Answer Bot, an AI tool that suggests help articles when customers reach out to our support team.
  • Getting direct feedback from customers. Future projects may involve getting our customers to provide ideas for our support docs. In fact, if you have any feedback — good, bad, or ugly — on our Support Center, please leave a comment on this post!

OK, now that we’ve completed the Support Center redesign, it’s time for some fun. (Look, a blog named “Donuts” can’t be too serious all the time.)

I spend a lot of time thinking about how users work with our products. Sure, I know the layout and organization of our software, but some of our users don’t. When writing support articles or revising the microcopy in our user interface (UI), I put myself in the mindset of users who don’t spend as much time in the software as we LexBloggers do.

But I recently applied that thinking to another kind of user: the rogues and scoundrels who show up to my occasional game nights.

 

Different game, same rules

Every month or so I throw a game night (house favorites: Jackbox Party Pack and Cards Against Humanity) or bad movie night (past screenings: The Room and Miami Connection).

Sure, I know the layout and organization of my apartment, but some guests don’t. When people come over, I try to set things up to make the evening enjoyable and relaxing. Recently, this involves labeling the unique aspects of my home that a visitor wouldn’t understand without an explanation.

Many of the concepts that go into creating a good web UI can also apply to creating a seamless game night. Here are some of the UI rules that I’ve applied to my apartment:

 

Anticipate user needs

When showing up at the front door, some people will (politely) knock and then wait for an inebriated guest inside to yell, “It’s open!” With a note on the door (“Come In”), visitors can skip the unnecessary wait and walk right in.

 

Explain stuff new users won’t understand

Fitting with Seattle’s mandatory Socialist, Communist, Anarchist-vegan values, household waste gets sorted into recycling, compost, and landfill. My identical landfill and recycling bins sit side-by-side, so guests would often ask which is which. With a simple label placed on each bin, they know where to chuck the empty bottles of organic locally crafted gluten-free IPAs.

Confession: I stole an idea from an ex. The (L)andfill bin sits on the left. (R)ecycling is on the right.

 

Don’t make users search for stuff

“Where are the glasses?”

“Where are the plates?”

“Where are the titanium sporks?”

This grew out of a problem I faced when standing in other people’s kitchens: I don’t know where the hell anything is. And I don’t like rummaging through other people’s cabinets while they’re still in the house. So I often have to ask where every utensil or dish lives.

At my game nights, everything you need for enjoying tasty snacks sits out on the counters.

Pro tip: coffee mugs make great drink containers because they’re harder to spill than wine or pint glasses.

 

Put tools where people need them

If organic locally crafted gluten-free IPAs go in the fridge, bottle openers should be really close to that fridge.

 

Be lazy

OK, being lazy isn’t a rule for crafting user interfaces. But it gets to an idea that’s lost on many organizations: If you manually answer the same question over and over and over again, you’re doing something wrong.

Take this common game night scenario: at some point one or more guests will ask for the WiFi credentials. So I would have to walk over to the router and read off the key. Sometimes this would happen more than once a night.

The solution: notes with the WiFi information sitting on the game table.

 

Less thinking, more playing

OK, yes, some of these ideas are silly. But I’m a nerd who overthinks how people interact with stuff. And in the AirBnB age, labeling your home for guests does make some sense.

On game night, hopefully my guests spend less time figuring out how my apartment works, and more time eating tasty snacks, playing games, or sharing the best music videos.

Like web UIs, the goal here is the same. Less thinking, more playing.

A long time ago in a galaxy far far away, LexBlog used Get Satisfaction to manage our knowledge base and community portal (then named “Reach”). The implementation was clunky, requiring users to create dual user profiles on their sites and inside this other application. Moreover, there were no ties between the content in the knowledge base and the people that were helping clients find answers to questions, so there was little incentive as an employee to know or contribute to the content.

As I’ve mentioned in my past few posts, a huge reason LexBlog moved to using Zendesk’s suite of products was the consolidation of systems and processes. Instead of having three products from different companies that don’t talk to each other to manage one thing (support and project management) we now have a variety of integrated tools. A benefit to being in the Zendesk ecosystem is that these tools are fairly technically advanced, allowing us to tie a WordPress user to a Zendesk profile and supporting single sign-on into LexBlog’s support center where you can see all of your submitted tickets and interactions with our team since we’ve been using Zendesk’s ticketing system. For our support team this also means that all of the content from support center is at their fingertips each time they answer a question from a customer, and a new question can easily turn into a support center article.

While this has significantly streamlined our support processes from the Get Satisfaction days to today, we took things a step further when redesigning the support center. While the content has been available to anyone with a link to the support center for several years now, we had not allowed search engines to index anything. As a part of continuing to open LexBlog’s doors to all legal bloggers, we thought it was about time to take that step so that now anyone can search for the content on the web and find their way to the LexBlog support center. Community posts, profiles, and other private information will remain that way, but all articles written by LexBlog will be indexed by search engines from here on out.

A lot of the content now is there to aid in making our customers successful in using our software, but as we expand that content to include more information on blogging and social media, others that are starting up a legal blog may find it a useful resource. A key challenge for LexBlog (one among many!) is helping to raise the level of discourse on the web for lawyers and law firms – regardless of whether or not you publish with LexBlog – and this is one small step of many in doing just that.

Maintaining a network of over 1,000 blogs can sometimes feel a bit like digital farming. Much of my time is spent identifying bugs to squash in various repositories, managing projects along to completion, and reviewing platform statistics in preparation for the next round of customer interviews (the “weeding”, “shepherding”, and “flock tending” of product management). Every so often, however, harvest comes and there is some revelry in the launch of a major update.

Yesterday was one such day as the new design of LexBlog’s support center was launched early in the morning; the culmination of several weeks of work between Ted Cox, Brian Biddle, and myself. The old design (pictured below) was a fast bit of work, with the primary focus on moving a rather large body of content from Get Satisfaction to Zendesk’s Guide product without losing anything in that migration.

 

 

 

While the move was a positive one, and the updated design better than the one implemented in Get Satisfaction’s ecosystem, there was still a lot of room for improvement. As with any design, the longer it was up, the more obvious it became that something was off. The three “call to action” boxes seen in the image above, seemed arbitrarily placed, the search form’s placement moved around depending on what page template you were on, if you scrolled lower you saw a list of categories without any explanation of what the contents of those categories were; the list of UX and UI flaws goes on and on.

With Ted moving from his role as a Technical Support Specialist to LexBlog’s full time Technical Writer, the time seemed ripe for a major overhaul of not just the design, but the organization and focus of the support center. Ted spent days reorganizing content, and more time reviewing everything to make sure that things were as up to date as could be expected, all while adding a series of documents on new (and old) LexBlog platform features. While that happened, Brian worked on building out a design that was both more in line with LexBlog’s design standards, and focused on the paths that a customer may take as they looked for content.

The result was a fully responsive (the last version had a mobile version) work of art that everyone at the company is (more) proud to stand behind.

 

 

There’s greater consistency throughout the design, and the list of popular articles at the top of the homepage is managed by Ted and reflects the most viewed pieces of documentation within the support center. The interior pages are where I think the design really shines, with each article containing clear navigation to other articles in the same section of documentation, making it easy to follow from article to article and find what you need:

 

 

Overall a pretty fun project to work on, and a good crop to harvest.

As Jared wrote earlier, we employ several tools to make support documentation easily available to our users. In addition to those tools making our software easier to use, the content and structure of each article should help users quickly complete a task or understand a concept. How a piece of text contributes to a reader’s comprehension is what technical writers refer to as readability.

After joining LexBlog in 2016, I quickly focused on how we write, organize, and share customer-facing help articles. One particular task has taken me a year and counting: structuring all of our docs for readers who don’t have time to read.

 

Some points about our users

When I write or edit articles, I have to remember these points about our users:

  • On the web, people don’t read. They scan. User eyes are very good at skipping to the content they need.
  • Our users are busy. When looking at a help article, they need to find relevant content quickly. Nobody has time to read four pages about, well, anything.
  • Our users are diverse. Some of our users are seasoned web developers. Others have never logged into a blog in their life. Some may use accessibility software to help them read text on a page. Others may not speak English as their first language, so translation software helps them with the text.
  • Users get frustrated. Often a user doesn’t look at documentation until something goes wrong. The person reading a help article may already be confused, frustrated, or lost.

 

Structuring and writing support articles

It may sound like a contradiction — writing for people who don’t read everything on the page — but a few simple techniques improve an article’s readability. These are the general rules I follow when writing or editing help articles:

  • Keep it consistent. Our docs should follow the same, predictable format. New users who need more details can read more of the document. Experienced users who just need a refresher can skip straight to the parts they need.
  • Put important information up top. User eyes spend more time at the top of a webpage. So we put important messages higher in the docs. It’s a good idea to tell a baker to preheat the oven before they mix the batter.
  • Keep it short. Articles are brief and focused. Short, descriptive titles should tell you what the article is about. We limit sentences to 25 words, while paragraphs are generally limited to four sentences. If a concept requires more explanation, we may link to another source.
  • Use headers and lists. Clear, useful headers help a reader’s eyes skip to the information they need. Lists group together similar ideas or instruct users on how to perform a task. Using both of these elements can help break up a wall of text.
  • Use simple words. Technical writing is delightfully boring. We avoid jargon and pretension.

 

Learn more about readability

As I mentioned, restructuring our support articles is an ongoing task. Users like fixing their own problems, and clear, readable documentation can help them do so.

Here are some of the sources I regularly consult about writing for readers on the web:

When I moved to Seattle and began working at LexBlog as a full-time Account Manager in the summer of 2013, one of the first things I began doing was organizing my inbox in a way that would let me easily find a certain class of questions  and answers. This was primarily because at that time, LexBlog had no central repository of documentation for publishers using our platform. In this world, questions were a dime a dozen, but answers were in short supply or trapped in the brains of long-time LexBlog employees. Fortunately, the same or similar questions would come up time and time again, and each new question would get tagged and organized in a way that let me find it and other similar questions so that the next time it came up, the answer was just a few clicks away.

This might seem like a product piece for Gmail (it’s not, but Gmail sure is swell!), but far from it. This was an onerous, time-consuming process for all parties involved. On my end, my inbox was a mess, with emails from dozens of customers every day asking me how to do something when just the day before a colleague of theirs at the firm had asked the same question. Meanwhile, our customers were wondering how to do something and, finding no resources at their disposal, would email yours truly and wait patiently for a reply. When an employee at a firm would leave, someone new would take on the responsibility of managing the site and have to relearn everything on the fly.

We made it through those days through the power of fantastic employees who were truly dedicated to answering questions thoroughly and with a smile on their face. LexBlog is a company that prides itself on providing top-notch service and support, and it was (and still is) a necessity to be quick, nimble, and thoughtful, but things have gotten considerably better over the years. Those same great employees still exist, but our systems and knowledge management tools are considerably different.

Continue Reading A New Set of Tools for LexBlog’s Support Center