Onboard Yourself 2: Understand the Area
Become an expert in the content.
While the first step was all about getting familiar with the people you’ll work with, the second is about getting acquainted with the content. People often dive into the content first, but I’ve put it as step two because building strong relationships with people is crucial and can take a long time. I recommend starting with the people and trusting that your craft skills will support you when you get to the content. You can also use the people you’ve met in step one to help you understand the content you’ll work on.
I don’t expect these to come as a surprise, but look to:
- Audits
- Existing research
- Interviews with the users
And don’t forget to take great notes.
For the audit, I recommend doing both an inventory and an analysis. Use your best judgment for how detailed to go with the audit, but I try to timebox it to two or three days per site, then another day to review the notes.
A good audit will tell you how much you’re working with, the quality, and show some opportunities. A color-coded audit spreadsheet is also an excellent output that usually impresses people. I highly recommend bringing this along to any demos to give visibility into your work.
Next, look for any existing research people have done. This might come from a whole research team or just be a Google form someone sent around once. Any insight into the users will help you going forward. You can also look for feedback tickets raised against the documentation.
Interviewing users yourself is optional, but I highly recommend it. It helps you sympathize with their needs, and you can use that to write more informed content. If you do this after looking at existing research, you can focus your questions on gaps or the parts that interested you.
I worked on internal documentation for engineers in a previous role, so when I started, I interviewed engineers with different tenures at the company, different work experiences, and different specialties.
Finally and most importantly: you need to take notes. There can be a lot to absorb in the moment, so having notes helps you spot patterns when you reflect on them later.
Observations
After doing an audit and looking through the existing research, you can use the notes to write some observations. Don’t overthink these and write essays. Use simple sentences with optional explanations.
These are some examples based on actual observations I’ve made when starting a new role:
- Users are presented with many options, but there’s no content to explain the benefits of each.
- People are looking for guidance on how to use inclusive language in their work.
- It’s not clear where information should go.
- A remote workforce has increased the importance of documentation.
- Page titles are more fun than clear.
- Technical writing is not well understood.
- The documentation lifecycle is not clear.
- It’s hard to tell how content is performing.
Pain points
As well as observations, you can record some user pain points. While the observations come from the audit, the pain points come from the user interviews.
Here are some examples of pain points:
- The documentation is split across too many locations.
- It’s hard to contribute to the documentation.
- I’m uncertain the documentation will stay up to date.
- I spend too much time repeating the same explanations.
When you’re presenting these, include some verbatim quotes from the interviews. The quotes add credibility to the problems.
Next step
This is part of a series of posts explaining an approach to onboarding yourself in a new role. After understanding the area, the next step is to Embrace feedback. If you want an overview, see Onboard yourself.
Michael Belton is a Technical Writer at Carted, a software company seeking to empower the future of eCommerce. He’s interested in helping people through content, explaining complex things simply, and making good food. Find him on his Twitter, @mykale37.
