Technical writing software is the primary tool that a product department uses to document everything related to that product. I think that the creation of technical documentation is one of the most underappreciated business functions in the modern-day enterprise. Somehow, we realize that the product is essential, but all information related to the product is disposable.
That’s why many documentation teams are stuck using text editors instead of robust technical writing software.
Technical writing software is important, but the requirements are equally complex. Much of this is because there are so many different routes to follow.
Do you want an integrated authoring system and content management system or separate options?
What outputs do you want to publish to?
If you do want an integrated content management system, do you want a single-source system or just a repository?
We can’t answer those questions for you, but we can help you figure out how to pick a system that aligns with those priorities.We’ve broken the process down into eight primary steps:
- Information Architecture
- Consider the Users
- Define Requirements vs. Wants
- Do Research and Ask Questions
- Make Your Shortlist
- Get Demos
- Make a Selection and Run a Pilot Project
- Meet as a Team to Review
Start It Right: Information Architecture
Where do you start the search? With Information Architecture (IA). I know… it’s the boring, nerdy answer but it’s also the right answer.
You cannot make an informed decision about your system if you don’t even know what your content structure is going to look like.
We wrote an overview that you can use to evaluate and compare the different technical documentation standards.
Before you select a tool, do the hard work:
- Develop a strategy for your content
- Select a content model
- Develop a taxonomy
- Identify the requirements of your information architecture
Consider the Users
If you are thinking about the short term, the answer is probably just your technical writers. But, with a new tool comes new opportunities to expand the influence and capabilities of your department within the organization.
It starts with technical, but it’s not uncommon for our customers to start seeing the user base expand to product, then to learning and training, as well as other departments like customer support and sales.
When you consider the users, don’t forget about future users as well.
Define Requirements vs. Wants
At this point, you should have an idea of things that you want from your next technical writing software. The tricky part is organizing that list around things that you really need versus what you just want. Don’t get me wrong, wants are an important consideration, but ultimately you need to identify the deal-breakers.
So, create two lists:
- We want
- We need
Make sure that you keep the requirements to true must-have items. The last thing you want to do is dilute the value of your “we need” by filling it up with your wish list. This is paying for rent versus paying for Netflix. Prioritization is the hallmark of a functioning adult (and a functioning documentation team).
A quick note about lists. Now, I know I just said to make a list. But, what you actually want to create is a series of stories, not just a checklist. By this, I mean that you want to craft a scenario in which the capability is required. For instance, don’t say “export to PDF”, rather, say “we want to export our 300-page product manual to PDF without any manual formatting.”
See the difference?
When you use stories instead of checklists, you create scenarios that need to be fulfilled. They’re tangible.
Do Research, Ask Questions
Ok, this part should come as no surprise, but you should start doing your research and finding the software that will fulfill your requirement stories. Look for technical documentation software that prioritizes what is important to you.
The easiest way to get started with your research is by living on Google. You’ll likely find yourself inundated with every company claiming to deliver all of your wildest dreams. Make sure you also ask other professionals within your industry. Maybe even within your own team. Writers will often come from other companies with established toolsets.
Make Your Shortlist
Let’s say you found fifty technical documentation software tools. Now that we’ve applied our requirements stories, you might be down to ten or so. At this point, you get to leverage your list of wants. Now, you should be left with a much more manageable shortlist.
Get Demos
You created requirement stories, you chose the tools that appeal to you and your content strategy, now comes the fun part. It’s time to see those stories come to life.
Put your vendors in order, contact each one, and request a demo and a trial.
If possible, supply the vendor with some of your own sample content. Find out what it looks like within the system and how it looks upon output.
Do. Not. Rush.
Once you’re at this stage, it can be easy to get excited with one option and jump the gun, but this is a big decision. Training and setup take a lot of time and realizing you made a mistake six months down the line is not a fun feeling.
When you set up the demos, don’t just let the vendor control the direction of the demo. Ask questions, challenge assumptions, and don’t be afraid of getting specific. You’re looking for a solution that will withstand the rigor of your situation.
Make a Selection and Run a Pilot Project
You got the demo, now it’s time to get your hands dirty. Well, dirtier. Ensure that you get access to a trial in order to complete a pilot project without any long term commitment. Make sure that this project follows a real-life-project like from your requirements stories.
Before you begin the project, establish a few things, namely:
- Success criteria
- KPIs to measure that success
As you go about your project, pay attention to the roadblocks. Which struggles are a result of insufficient training and which struggles are due to unforeseen shortcomings of the technical documentation software? Make sure to note the difference.
Meet As a Team to Review
After each pilot project, make sure you actually take the time to talk as a team. Talk it out and reflect on how the project went. Make sure that everyone has an opportunity to express excitement as well as concerns.
Evaluate the outcomes and determine if you should continue with the current system or if you should move on to the next vendor on the list.
No matter what, remember to keep your head up and enjoy the process. This is an exciting moment for potential growth, don’t let it pass you by. Best of luck!
