My name is Peter David Gustafson. I’ve been writing technical documentation since 2001 for technology companies of all sizes. Learn more about me.
Your technical writing or API documentation project requires working with a proven expert who can bridge the gap between complex data and readability.
I’m passionate about helping companies and programmers cut through the clutter managing the following types of projects:
- Internal documentation architecture design
- Authoring system design
- UI/UX design and testing
- Software user guides
- API documentation
- White papers and digital marketing
Your company has likely built a dynamic software product or App. However, when it comes to building API documentation, too many technical writers lack the necessary programming skills and software expertise to manage your project.
Around 2010, many technical writers fell asleep at the wheel. As UI design and software documentation went into hyperdrive, these writers were forever left behind lacking the necessary skills to keep up with the industry. Specifically in programming skills. Great API writers (such as myself) are experts at the mission-critical elements of:
- Working with the command line
- Collaborating with programmers
- Implementing single-source documentation architecture
- Creating HTTP help documentation
- Building logical graphics and tables
- Producing video instructional documentation
- Writing for all types of users
Your API documentation project deserves a technical writer with vast expertise in website design, file management and single-source architecture formatting to take advantage of a streamlined work flow. Having been involved with many API documentation projects, I assure you I’m your best candidate to manage your entire project.
Writing for all users while understanding their skill sets is critical. The following Stripe developer API screenshot gives you an idea of the types of content programmers desire along with code examples:
Do you know your target documentation user? Often I find speaking with programmers can be valuable. However, remember that documentation is aimed to teach. Therefore, I like to evaluate your core target users and research their learning needs.
Translating what a ten year programmer knows about your software needs to be reduced to the lowest common denominator of user knowledge. Successful technical writing and documentation is about helping users find solutions quickly. Fully understanding your user learning challenges is mission-critical to solving their problems.
Traditionally, technical writing required developing documentation for many output formats and devices (i.e. desktop, smartphone, tablet, Word, PDF etc.) by creating separate projects for each type. Not anymore.
With the robust functionality of MadCap Flare, we can approach your project in a single source format.
Write once. Publish everywhere.
Doing so streamlines production allowing multiple outputs of documentation from a single source of content rather than separate sources for each type of output.
Another benefit is you can import native file formats into Flare from other sources such as Word, FrameMaker, HTML and other types of help authoring tools.
Doing so capitalizes on your current documentation file formats without the need to start from scratch.
Granted, Flare may not be right for every organization’s server stack.
Integration requirements are always blockers. In these cases, I like to work with developers to find solutions that fit their technology rather than forcing authoring products which don’t play nicely with their backend.
Online content (excluding API documentation) can easily be managed within a CMS. But beware. Going bonkers with heavy content management systems isn’t always smart.
Often heavy and slow requiring the pinging of databases, CMS reliance can be detrimental to website speed. Don’t forget customizing your CSS to match your company branding will requirement management. When these struggles arise, I usually suggest a static file structure for help documentation.
There’s a few good options.
- One is MKDocs
- Another is Hugo
Although promoted as help documentation solutions, they do require using a lightweight CMS.
A third option, my favorite, is building lightning fast static pages minus the weight of a CMS. There’s some commercial products on the market. However, thinking out of the box shouldn’t include buying a box of software.
Building static help systems isn’t complex. Well, you do need resources to host the .md files but any developer with a few years experience can manage it.
There’s a fabulous open source solution offered by a good friend of mine who worked at both Stripe and Tripit.
Check our Rob’s GitHub project: https://github.com/lord/slate
Project managers are busy people. As a technical writer, my job is to not only manage entire documentation networks but also identify and fix broken links and missing content. It’s not brain surgery if you have the right tools.
What’s my secret weapon? Analytics.
As your documentation grows, one thing is certain: it will become scattered. It’s the nature of the business.
But not if you’re hard-wired with the right tool. From 10 to 10,000,000 documents, MadCap Analyze pinpoints broken links, missing data and provides rich data on user engagement (or lack thereof).
Hmmm…a technical writer proposing the use of analytics? Yes. In this day and age, gleaning enormous amounts of data is easy and beneficial to your documentation users.
The bonus is you can capitalize on data trends of user engagement in your marketing of new prospects.
Are you tired of spending time and manpower on usability testing? Who isn’t?
MadCap Analyzer is like employing a large scale documentation team (minus the steep payroll and excessive snacks) to scan and report compliancy issues as well as dozens of other content gaps such as:
- Documentation identify issues for improved quality
- Elimination of duplicate or unused elements
- Identify ways to improve how content is developed and maintained
Technical Writing Visuals
Recently I had a client who contracted me to write a complex user guide. The problem was they outsourced graphics and imagery to an overseas designer.
Despite my best efforts to collaborate with their graphic designer about visual needs, the project was delayed for months.
It was because of the segmentation of skill sets. By relying on a freelance designers, they were handcuffed to his schedule which was far from timely.
Too many technical writers lack graphic design expertise (unlike myself). Graphic designers aren’t writers. The result was my client created a communications gap. There’s nothing worse than waiting on graphic designers to supply deliverables.
My approach is far different than other technical writers..
- I possess more than a decade of expertise in graphic design (Photoshop, Gimp).
- Visuals (i.e. graphics, charts and photographs) need to be developed in conjunction with the text.
- Task scheduling should be self-contained rather than outsourced to multiple contractors.
Are text-based documents outdated due to the evolution of online video? Hardly. At the root of every user guide, tutorial and software API document is one goal: educate people in clean, easy-to-understand steps.
However, you have an alternative with video. Not always (especially if local language translations are required).
I’ve worked with many clients who understand the benefits of converting help documentation into video demonstrations. In these types of projects, you need to evaluate the following considerations:
- User video access: public vs. private
- Public: YouTube is ideal and can be used as a marketing tool
- Private: Wisita.com is the gold standard for privacy protection
- Content: scripting, voiceover and screen footage
- Production: video development, formatting and cost
Is video documentation right for your company? Perhaps. However, you want to avoid outsourcing your video production. The cost can be staggeringly expensive. My suggestion is to work with me since I’ve been developing video for many clients since 2007.
Whether you’re in need of help documentation or user guide development, I recommend using progressive elaboration. Doing so breaks down your documentation into iterations. Each iteration results in:
- Defined steps.
- New incremental iterations.
- Builds upon greater functionality of previous iterations.
- Supports refinement of complex instructions.
My Background & Skills
For nearly a decade I was a senior account executive for a national advertising agency. By 2007, I witnessed the explosive demand of IT documentation and chose to branch out on my own. Read my full bio and resume here.
In 2008 I realized speaking with engineers and software developers about technical writing projects required me to be adept at specific programming languages. My tools of the trade…