4 Tips for Help Center Teams Looking to Take on UX Writing

Illustrations by Lizzie Burns

A year ago, our Help Center team got the opportunity to take on UX writing. As writers of documentation, the words in the product were always top of mind for us, and we were eager to start helping customers before they even need help — in the product itself. With 5 years of managing help content under our belt, it felt like the right time to increase our scope and rebrand as the Content Strategy team.

But most importantly, we were already prepared to say yes. There are 4 steps we took on our team that helped us smoothly transition into UX writing when the opportunity arrived. If you’re on a help center team with big dreams of influencing the words in the product, listen up! (I’ve chatted with a few of you at Confab, so I know you’re out there!)

1. Connect your content experiences

We had already designed our self-service content strategy with the UX in mind, so it felt like a natural extension of the work we’d already been doing.

A good self-service content strategy focuses on giving users the info they need in the right place at the right time throughout the entire product experience. By strategically connecting UX writing and help content, you set yourself up to maintain a healthy content ecosystem that drives self-service at every touchpoint.

The self-service funnel: UX writing, tips, help articles, and support emails

Here’s how it all connects:

• UX writing is the content that all your customers see, so it gets the highest visibility. For the best user experience, do your best to include all the essential information they need to use your product right there where they are.
• Tips connect users with a relevant help article if they do need more information. Users can hover over a tip icon, read some helpful context, and click through to learn more in the help center. Giving users a clear, contextually relevant path to help articles is key to connecting your product and help experiences.
• Help articles break down bigger tasks or use cases into step-by-step instructions. They teach you everything you need to know about a feature. The help center is also a great place to cover edge cases that most users don’t need to know about in the UX.
• Support emails happen when a user hasn’t gotten all the info they need at the other levels in the funnel, so they email support to get help. While it can be a bummer that your user got stuck using your product, support emails are a great opportunity for your team to wow customers during one-on-one interactions. And common support questions are a goldmine of ideas for making meaningful improvements to your product.

2. Build strong relationships

I’ve always believed you need to have solid working relationships to be a successful content strategist. When I first joined SurveyMonkey, my teammate and I added “collaborate and build a strong reputation” to our team goals. We created documentation for people to learn about us, our strategy, and what we were working on. We responded as soon as possible to emails and content requests with next steps. We jumped at opportunities to give feedback to the product and product design teams on what they were building. We shared our help content with product managers and designers. And we went above and beyond to explain the reasoning behind content decisions so people could trust our expertise and strategy.

Over time, people came to know us as excellent writers, product experts, customer advocates, and strategic thinkers. So when the opportunity to own UX writing came up, all our hard work paid off — the teams we invested time into building relationships with supported us fully.

Here are 3 easy ways you can start working with other teams:

• Get to know UX writers. You can offer to peer-review their copy and lend your expertise in product functionality and support trends. In turn, ask them to review your help articles. Building a collaborative writing culture opens the doors to you being more involved in UX writing.
• Attend product syncs and review designs. You need product and launch details to prep help articles in time for release, but you can use those meetings to familiarize yourself with how products are built and where UX writing fits in. To contribute to meetings, share your plan to support upcoming releases in the help center, and dive into related support trends to share with the group.
• Offer valuable feedback to product. We all know that when you have to explain how something works, you usually uncover gaps or opportunities for improvement. Information architecture and terminology issues in the product make it tough to write about. When you notice how things could be better, don’t be scared to share your ideas with your product team.

The view from my desk at work

3. Document clear content workflows

I love creating documentation to show what my team is up to and how to work with us. It’s not just about making a page and throwing words on it — the thought process behind what information you’re choosing to share and how you position your team is an essential strategy exercise.

We already had long-established processes for writing help content, so our coworkers already had consistent and reliable experiences working with our team.

As soon as we agreed to take on UX writing, all we had to do was tack onto our existing workflows. We outlined the process of how to request copy from us and presented it to the people we’d be working with the most — designers, engineers, product managers, and localization specialists. This helped us set clear expectations, gave us an opportunity to outline what need from various teams before we can start our work, and where essential handoffs take place. And with everything documented in our intranet, I always have a link handy to answer common questions we get from teams who partner from us.

In any content workflow, be sure to include:

• How to request content from your team. We ask people to file tickets for us in JIRA so we can loop in stakeholders for content reviews and track our work. It’s too easy for content requests to get lost in emails or message threads.
• When to loop you in. Designers schedule a kickoff meeting with us when they’re about to get started on designs to discuss design options and information needs, and we assign a copy review date within the next 2–4 weeks.
• A visual timeline. Showing people what your process looks like in a nice flowchart goes a long way. Outline the process from kickoff to final copy, and include the various people, roles, and handoffs so people know where they fit within your process and the best time to give feedback.
• What you’ll deliver. We create a copy doc for each assignment. Copy docs make your team a consistent presence in the product development cycle. It’s easy for any stakeholder in the company to review and leave comments — and having copy all in one place ensures consistency in terminology decisions, and shows off your team’s great work.

4. Make room for the right opportunities

One challenge we encountered when taking on UX writing was that we wouldn’t be able to hire any new people for about a year — so we needed to be creative and shuffle around some existing resources on our team.

First, we took a look at where we were spending our time. Since we track our work in JIRA, pulling a list of tickets for all our assignments was a snap. For each JIRA ticket, we noted the size of the content deliverable, the monthly page views of the content, the priority of the project, and how much time it took to track down product details and write.

Then we looked into tickets that took a lot of time, had low page views, or were a low priority compared to the size of the content deliverable. We found nearly a full headcount in these ways:

• By owning both UX writing and help content, it’s easier to share information — now UX writers on our team pass essential product info directly to help writers, which saves a lot of time that was being spent tracking down details to prep help content.
• The time help writers were spending downstream giving feedback on designs and copy is now spent working with designers early on in the process to write UX copy.
• API docs are written for a more tech-savvy audience and aren’t as commonly used as our core product and help center, so we transferred ownership of API docs to the technical support team.
• We identified repeatable tasks and processes on our team and created contributor programs for customer support to give people a chance to gain content management experience. One program focuses on internal workflow documentation and another on reviewing customer emails for top trends to add to the help center.

Being the team who writes about all our features in the help center, we come equipped with a solid understanding of the entire product experience. Being able to apply that knowledge to the product design through UX writing brings a lot of value. It’s also created new career paths within our team and made it easier to manage help updates.

As we grow and expand to offer more and more features, the words we choose become even more important. It’s easy to add new copy in one small section of the product. But if you lose sight of existing terms, naming conventions, and features across the entire product — you’ll write yourself into a hole.

So that’s where we come in! We’re here to make sure that copy continues to make sense in relation to the existing content ecosystem and to create help experiences for our users that are simple, clear, and human.