You’ve got a clear purpose for your document, and you know who your audience is. Now, it’s time to gather the information that will make your documentation both useful and accurate. This is where the Research Phase comes in—a crucial step that shapes everything you write.
In this blog, we’ll dive into how to collect the right information, why it’s important to get insights from developers and users, and how to interview subject matter experts (SMEs) to create clear and practical documentation.
Why the Research Phase Matters
At its core, the Research Phase is about taking information from the heads of the creators—like developers or product managers—and translating it into something users can actually understand and use.
Good documentation doesn’t just come from what you know—it comes from what your audience needs to know. This phase ensures that you’re building your content on a strong foundation of accurate, relevant information. Without it, your document will miss key details or get too technical, leaving users confused.
Here are some essential ways to gather information:
1. Interview Subject Matter Experts (SMEs)
The first and most obvious place to start is with the people who know the product or service best: the subject matter experts. Whether it’s developers, product managers, or support staff, SMEs have the deep knowledge that your document needs. But how do you extract that knowledge?
Here are some tips for effective interviews:
- Prepare your questions: Don’t just ask, “What does this do?” Break things down into specific use cases, problems, and scenarios.
- Ask "Why?": Understanding the reasoning behind features or processes helps you explain them clearly.
- Get into the details: Don’t be afraid to dive deep into technical explanations, even if they seem complex. You can simplify these later for your audience.
The goal here is to understand the ins and outs of the product or service, and capture that knowledge in a way that’s easy to communicate.
2. Review Existing Documentation
Before reinventing the wheel, take a look at what’s already been documented. Review any existing guides, release notes, FAQs, or internal documents. You might find that some information is already available, which can save time and effort. Plus, you can see what’s working and what’s not.
Here are a few things to keep in mind while reviewing existing docs:
- Consistency: Make sure the voice, tone, and style align with what you want for your document.
- Gaps: Identify missing or outdated information that your new document can fill in.
- User feedback: Look at any comments, support tickets, or forums where users have expressed confusion or asked questions about existing docs. This can give you clues on what needs more clarification.
3. Use and Test the Software (or Tool)
Nothing beats hands-on experience. If possible, try out the software or tool you’re documenting. Testing it yourself will help you understand the user experience, spot potential issues, and find out what works well and what doesn’t.
- Follow real user workflows: Put yourself in the shoes of the end user. Go through the process from start to finish as they would. This helps you see the product from their perspective.
- Take notes: While testing, jot down things that confuse you, areas where you get stuck, or features that could use more explanation. These insights will be crucial for making your documentation clearer and more effective.
- Talk to users: If you can, get feedback from actual users about their experience with the product. Their pain points and questions will give you a clear direction for your document.
4. Research Competitor or Similar Documentation
It’s also helpful to look at how others have tackled similar documentation. How do other companies or products explain features that are similar to yours? What works well in their documentation? What could be improved?
Here are some things to look for when reviewing competitors’ docs:
- Clear Structure: How is the information organized? Is it easy to follow?
- Tone and Voice: Is it professional, friendly, or casual? Does it fit the audience?
- Examples and Visuals: Do they include helpful screenshots, diagrams, or videos? These can make documentation much more understandable.
Don’t copy—learn from their best practices and adapt them to fit your needs.
5. Involve Developers Early
While interviewing SMEs is essential, it’s also important to keep developers in the loop. In the process of research, you’ll likely uncover questions or ideas that need technical clarification. Keeping developers involved early ensures that the technical details are accurate and easy to explain.
Here’s how to make the most of working with developers during research:
- Have them review your drafts: Once you’ve gathered your information, have a developer review your content to ensure accuracy.
- Collaborate on difficult topics: Some topics may be tricky to explain in simple terms. Work with developers to find ways to simplify complex explanations without losing meaning.
Tips for Effective Research
Here are a few bonus tips to keep in mind during the research phase:
- Stay Organized: With so much information coming from different sources, it’s easy to get overwhelmed. Keep your notes, interviews, and documents organized for quick reference.
- Keep the Audience in Mind: Throughout your research, always ask yourself, “How does this help the user?” Remember, you’re translating technical knowledge into usable content for your audience.
- Ask Follow-Up Questions: Don’t be afraid to go back to SMEs or developers with new questions if something doesn’t make sense. The more you understand, the better your documentation will be.
Wrapping Up
The Research Phase is your chance to gather all the details and insights that will shape your documentation. It’s where you dig deep into the product, talk to the people who know it best, and make sure your content will actually help users.
In the next blog, we’ll dive into the Write Phase, where you’ll start turning all your research and planning into clear, usable documentation.
What’s Your Research Process?
How do you gather information for your documentation? Do you have any tips for interviewing SMEs or testing the software? Share your thoughts in the comments—I’d love to hear how you approach this critical phase!
Top comments (0)