Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.
In her book 'Content Design', Sarah Richards explains the process that content designers work through to create user-centred content. What struck me about it is how similar it is to the technical writing process, although there are a few key differences.
Since reading Content Design, I've changed my own approach to technical writing, slightly. So hopefully this post (and the ones that follow on from it) will be useful to new technical writers who are looking for tips. It might be helpful to more experienced writers too, especially if you feel you're getting a bit stale in your practices.
Note: For the content design process, I'm going to be leaning heavily on Sarah's book (available on Amazon). I also used 'The Elements of Content Strategy' by Erin Kissane, a blog post by Nic Evans (https://gathercontent.com/blog/www-content-production-process), and several online discussions.
The first step involves identifying the needs of the audience and the organisation. Sarah calls this 'Discovery', so let's go with that.
It's difficult to create effective content if you don't know who you are writing for. You also need to know what needs to be covered, and what is expected. So at the start of every project, there should be a discovery stage that focuses on finding out:
But how do you get this information? By having a 'Discovery' meeting.
Sarah recommends a meeting where you get all of the people with useful input, such as those with sign-off responsibilities, user researchers, and experts, into a room. There, you discuss the requirements and get an overall idea of the customers, based on the perceptions of different stakeholders. You also get useful anecdotal data from people in customer-facing roles.
Note that at this stage, the information is a mix of opinions and information about actual interaction with customers (or the audience). If there is a user researcher, they will be able to provide lots of great information based on actual research and interviews with customers. But not every organisation is going to have dedicated user researchers (I've never encountered one...I wish I had!).
I can see that there are lots of benefits to this approach:
All of that information is a great starting point for any writer, no matter what type of content they are working on.
Every documentation project I've ever worked on has started with a meeting that is similar to a discovery meeting. But the meeting has always been with a select few members of staff, not everyone with an interest in the documentation. For example, I've never had a 'discovery' meeting where sales staff or training staff are involved (but by God they have opinions on the documentation, all right.)
Speaking to other technical writers, it seems they have experienced the same thing. It tends to be a smaller meeting at the start, and then we go and liaise with different departments on our own. At that stage, we can create drafts and perhaps a wider range of stakeholders will be involved in meetings once the draft content is available.
"In my experience of the bigger companies in general, it's been a few 1-2 hour sessions with the stakeholders for engagement, knowledge sharing, and progress, followed by closed questions and a series of reviews exchanged over email. I usually asked for some form of email confirmation on final draft, so there's some incentive for stakeholders to make sure they're read through what they're putting their name to." - Tess Walpole, Technical Writer
It's hard to argue with the logic of a discovery meeting that involves everyone who is relevant to a documentation project. It makes a lot of sense. So why don't we do it?
I think there's a few reasons why discovery meetings are not the norm on tech comm projects.
1. Commitment and Attitude to Documentation
People understand the importance of a great website. It can attract leads and generate business. When I've been involved in marketing meetings, getting senior staff involved hasn't been a problem at all - they have strong opinions on what the website needs to be.I cannot say the same for documentation. Too often it is seen as a post-sales product, and is regarded as a support cost. Everyone recognises it is needed, but they don't really care about how it is put together ... unless customers are complaining or support costs are too high.
The attitude from others is more 'You're the expert, go and do it,' rather than a more collaborative 'This is what our department would like to see.'
"You're usually led by the existing company culture, the content format, and the communication tools available as to how you engage with stakeholders and how they engage with you. Some are very active throughout the process and some honestly don't care until the final draft is ready (and sometimes even then, they're not that interested)." - Tess Walpole, Technical Writer
Getting people to commit to a discovery meeting for documentation and actually contribute in it could be tricky. It's just not seen as important enough (at the start anyway ... people soon pipe up when the user guides and online help is at draft stage or live).
2. Logistics.
This must be the same for content designers, but getting everybody in the same place at the same time can be nigh on impossible. Especially if you have remote workers or people who work in different countries and time zones. Couple that with the attitudes towards documentation and you might just have to make do with the product manager and perhaps an expert or two.
3. Timing
This seems to be an important difference between the work of content designers and technical writers. Content designers try to get involved at the start of the website design process, so they can contribute ideas and information right from the earliest development stages. Technical writers tend to be brought into the project when prototypes are available, much closer to the actual release. At that stage, it might be a real backs-to-the-wall effort to even get close to meeting the deadlines, so there just isn't time to do discovery properly. The best we can do is to get web analytics and anecdotal data from in-house staff.
"The key difference, I think, is that we like to get involved right at the start of the project - I'm there throughout user research, discovery and everything else from there on. We try to avoid the situation in which someone comes to us and says: here's a product, can you please put the content in. We shape the product." - Dean Hanley, Content Designer.
Would it be better to get tech writers involved at an earlier stage? Yes, definitely. For a start, we can give a more realistic suggestion of how long it will take to create the documentation. We can also help with UX content and identify usability issues. That'd be much better than being told 'Here's the software that has taken 10 developers 3 years to create. You have 3 months to document it all, that's plenty of time isn't it?'
Do technical writers help to shape the product? Yes, of course. We do an element of testing as part of our work and can report bugs, suggest improvements in workflows, UI labelling etc. But because we often join the project at a late stage, our input may come too late and it is two or three releases down the line before our suggestions become a reality. That can be frustrating, especially if it means we have to document a process that is a bit clunky!
Technical writers need the information that a discovery meeting provides. If you can't arrange one, do what you can to meet with the right people - anyone with sign-off on your work or who has direct contact with customers.
It's also worth championing our cause to try and raise the profile of our work. Good documentation can be a strong selling point for a product or service and it can help to reduce support costs too. We need to remind people that it adds value and isn't just a cost.
Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.
_new_hue.svg.png)
Registered Number: 08029184
Straygoat logo design by Bristol graphic designer, Nik Jones.
© Straygoat Writing Services Ltd.