Sometimes, you need to become a technical writing pioneer. This often happens at startups or, perhaps, your company decided to terminate contracts with outsourcing help authoring companies and wants to start its own thing going. Being the first technical writer in a company has a lot of challenges. But don’t fret - as long as you have a plan, you will succeed. This article will help you stay confident through the process of building technical writing from scratch. Just keep calm and follow the guidelines :)
Learn the Software Product
Before starting anything, take your time to learn the product you’re going to document. To be able to even remotely understand the scope of work and its specifics, you need to get acquainted with the subject of your future help articles. To collect useful information, consider this list of activities:
- Talk to the development team. Ask them to set up a demo for you to showcase main product features.
- If possible, get a trial to play around with the product yourself, and test the trial workflow. This may help you understand what a real trial user is seeing, what messages they receive from the company, and what information sources are promoted in your pre-sales cycle.
- Learn the product release schedule. This is something you will need to sync with, and this will determine your work model. You can’t use the Waterfall model for software documents when the Devs are using short cycles in the Agile model.
- Consult with marketing regarding the target audience for your user guide. You need to know who you are writing for, what they know and what they don’t know, what terminology they are using, etc.
- Meet with the Technical Support team. Learn what users are often asking about, what challenges they are facing, what are the Top 5 areas of complexity for a typical new user. Having this information, you will not just create user documentation, you will significantly cut the Tech Support costs for your company and improve the product adoption rate.
Learn the Product Team’s Expectations
Figure out what the Product Team would like to see in a user manual. For example, whether help topics should contain additional elements like code samples, or videos. This will influence the tooling choice.
Ask them to give you some general ideas, too. Like, what they hope to achieve with user manuals, what’s important to cover, which features are used most often based on the usage statistics. You probably already know a part of the answers, but this conversation can become the basis for setting the documentation KPIs and find the areas of focus.
Build Processes
Before choosing the tools, you need to think about how you would like your workflow to be organized. Think about a perfect scenario. Write it down. We’re going to give you a few things you might want to ask yourself in the process:
- How many help topics will you need to create? Approximately, of course.
- How will you handle repeated content? This is crucial for the earliest stages of help writing as this factor can interfere with your maintenance efforts for the years to come. Read about single-sourcing, it is a great approach to solve the repeated content maintenance challenge.
- Where will you host online documentation?
- How many people will be involved in the writing and documentation review process (SME’s, translators, reviewers, technical support, etc.)?
- Will they need different roles and permissions?
- How will you notify them when they need some job to be done?
Now that you have a list of requirements, you can get the right tools.
Choose Tooling
Most likely, you will need more than one piece of software. Your company will have to get you the right licenses timely, so make it your priority to analyze what you require for work. Your go-to solution would be getting a help authoring tool. The rest is supplementary. Since you already have a list of requirements, you can start evaluating your options.
For our own documentation platform ClickHelp, we offer a free 30-day trial with all functions available. This will help you assess the tool against your requirements, and run a POC to present your recommendation to the stakeholders. As for the supplementary tools, they depend on specifics of your task. Some of the popular use cases may require:
- Image editor
- Video editor
- Screenshot maker
- Video recording software
- Dictionary
- Code editor
- Etc.
Things like a spellchecker are usually included in software for technical writing, so after getting the supplementary list done, check with the HAT again - it might already have some items as a feature.
Fetch a Style Guide
We recommend that you start working on a style guide for your user manual as soon as possible. This will help you stay consistent with the content you write and will make onboarding new doc team members easier in the future. Initially, you can rely on industry’s best practices, without going too deep. As soon as you start working on your docs more, the style guide will grow organically.
Write!
This section alone deserves a whole book! But if you have made it to this part, give yourself a pat on the shoulder - you have officially succeeded in becoming a technical writing pioneer! Now you can get to what you're good at - documentation writing.
Conclusion
Each journey is unique. Some technical writers will have it like a piece of cake, for others the pioneering road can get bumpy. Setbacks are expected. However, if you were presented with an opportunity to set up technical writing from scratch - take it! You will learn so much from this experience. It will definitely help you evolve as a tech commprofessional.
Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices