Skip to main content
This page explains how to identify your audience, conduct user research, and write with their needs in mind.

​
Identify your primary audience

Writing for multiple audiences leads to compromises that satisfy no one. Each piece of content should be focused on one specific user persona. Your audience might be:
  • Technical decision makers evaluating your product who want to understand higher level details like architecture overviews.
  • New users who want to start using your product for the first time.
  • Developers responsible for integrating your product who need instructions for a specific task.
Before writing any page, ask what is your reader trying to accomplish and what is their prior knowledge?

​
User research is key

Your team should agree on who your primary audience is, but don’t rely on intuition alone. The best insights come from talking directly to users. There can be a disconnect between how we think about our own products and how people actually use them. Talk to users to understand:
  • How do they describe what your product does?
  • Do they use any unexpected words or names to describe your product?
  • What do they wish they had more knowledge of?
  • What is explicitly missing from your documentation?
Talking to users directly helps ground your writing from their perspective so that you write documentation that is helpful to them and gets them closer to their goals.

​
Tips and tricks for understanding your audience

  1. Get embedded with support. You’ll see the pain points that incomplete documentation causes. Ask your support team how people think about the product and what are the most common problems people encounter.
  2. Incorporate feedback mechanisms. Whether it’s thumbs up/down or plain text fields, give users the opportunity to provide feedback as they read your documentation.
  3. Use analytics to guide you. Review feedback and insights to understand where users are struggling and where they are successful. Make updates to the documentation that people struggle with or is most connected to the key tasks for your product.
There will always be edge cases that are not covered by your documentation. Prioritize the most impactful pages to help the most people. Too much content becomes difficult to navigate and maintain, so trying to document every possible scenario can be counterproductive.
⌘I