David Forsythe, Product Documentation Manager at Mavenlink joins to discuss the importance of user navigation us in this episode of Knowledgebase Ninjas.
Connect with David and view Mavenlink’s Knowledge Base here:
Key Takeaways:
David’s journey into documentation…
Technical writing has always been a confluence of everything David loved to do at a young age: writing and making art. He self-taught himself programming languages so that he could wrap his own ASCII or create a text-based adventure game. David fell into technical writing serendipitously about 20 years ago, after finishing his college degree he was doing front end design and hawking high-end retail electronics to generate income through his second round of college.
One day the founder and CEO of a small library automation company, came into the store and started talking with David. The CEO had been writing and maintaining all of the software user manuals himself since the beginning of the businesses. As soon as he found out that David had a background in graphic design, writing, and computer science, he offered him a job on the spot. This was a dream scenario for David as he wanted to work in the software industry.
When David first joined people still used physical user manuals, he was creating documentation and technical writing through the structured framework, as the software grew so did the user manuals going from 200 to 600 pages. He found it crazy to continue to keep printing these manuals every time the software was being updated because they had a high backlog that would become outdated. Also, sending out obsolete manuals is not a great customer experience! He found that throwing these paper manuals out was wasteful and costly.
He started to research, build, and implement their first help centre to enable the business to generate and maintain documentation in a simple markup language.
Mavenlink’s documentation process…
There is no ‘one size that fits all’ to documentation, he furthers this by explaining the standard contributor process which is: interview, research, identify the audience and medium, draft, review then publish.
At Mavenlink David has tried to emphasise the importance of words around a larger more holistic team process, that encompasses the entire customer journey and product life cycle. David’s team uses the Mavenlink platform to manage the documentation requests from internal employees, so everyone outside of the product organisation can send requests, and David’s team will prioritise the request accordingly and assign it to the appropriate writers.
For most of the core product documentation (which is a high priority), they get involved in the early stage, everything starts with the product conception, where they get context for the content being developed, the stories are then written and assigned to a technical writer if a new feature needs anything from UX/UI copy, contextual help, in-app guides, API documentation, localization requirements, feature announcements etc. because of this they attend daily and weekly meetings with the engineers, designers, and product managers as the features are being developed.
David’s inclusion within that process helps the product team build more intuitive software. It’s because they approach everything through the eyes of a user, they are able to ask questions during the process that identify problems before they exist. David’s team are constantly testing the app and checking how it works during development, they are working closely with UX design on Wireframe or prototype mods, this helps them discover how much text is needed in the interface to guide the user.
As a documentation team they have a collaborative weekly review, where they share what everyone is working on and provide feedback/constructive criticism.
David’s most important factors when creating documentation…
Consistency in terminology, tone, and voice is incredibly important.
Depending on the audience Mavenlink’s writing tends to be more conversational. It’s important to consider the arrangement of text and images, be mindful to include line breaks which introduce light space.
Aim to avoid giant walls of text.
Bolden words that reference links, navigation, or labels in the interface. These things are visual anchors that allow the user to skim read and is more engaging. Screenshots are an art form, most people do them wrong, quality screenshots go a long way in helping a user navigate your product.
David’s #1 documentation related resource…
David would highly recommend a book by Steve Krug: Don’t Make Me Think. He furthers this by saying that it’s a good resource for getting started with core technical writing and documentation practices.
Subscribe To Knowledgebase Ninjas:
–