I remember the first time I wrote help content that real customers would read. Most people assume you can't really "do documentation" wrong, but I wasn't tasked with writing any old help guide. This wasn't for a standard CRM or marketing tool. The stakes were quite literally life or death.
It was my first job out of school, a three-month contract as a Technical Writer (a fancy term for "person who writes user manuals"). I thought I was prepared. How difficult could it be? "Step 1", screenshot, "Step 2", screenshot, rinse, repeat, call it a day.
The difference was I was working at an organ donation agency, writing how-to guides for a proprietary, one-of-a-kind software that matches organ donors with recipients. If you've ever wondered how someone in need of an organ transplant gets the right organ donor, it was through this software and a highly trained team of medical professionals coordinating the logistics behind the scenes.
The software ran blood checks, cross-matched antibodies, ran multi-parameter algorithms, and assigned the right organ donor to the right person, at the right time, and in the right order. It had to be perfectly programmed, and perfectly used...
The user interface looked like NASA's control center. Every screen had about 35-40 input fields and toggles, seemingly placed wherever the screen had space.
I learned the product inside and out and started writing how-to articles. A lot of them. I triple-checked my instructions, making sure everything was as clear as possible. I had screenshots for everything, with "IMPORTANT!" callouts where I thought the end-user would need to be extra careful.
When I was finally done, I remember coming home from work thinking I did an amazing job.
Until I started getting questions. A lot of them. And every time, I'd send them the relevant help guide. But I always got the same response: "Can you just come over and show me how to do it?"
So I'd have to walk through our downtown office building asking where so-and-so sat. And then I'd employ the highly specialized "hover-over-your-shoulder-and-point-at-your-screen" technique.
"Thanks so much!" the struggling user would say, always adding with a laugh: "I'll be honest, I didn't read the how-to guide."
The same thing happened again and again and again. And that's when I realized that many people (even incredibly thoughtful and intelligent people) simply hate reading instructions.
Then came another problem: every time the software developers pushed out a new release, I needed to update the help guides or create a new article from scratch, and this took forever. It was a thankless job, as no one was even reading these guides.
And it went on this way during my entire time there.
Fast-forward a few years: by now Snagit, Camtasia, and Loom were readily available as possible tools to create video tutorials instead of help articles. So I tried them all, but I encountered a whole new set of problems:
As it turns out, my colleagues saw Camtasia and immediately said: "I don't have time to use that". I didn't blame them--Camtasia is like "Adobe Premiere Pro Lite". At its heart, it's still a video editing tool, designed for a range of video styles, when all we needed was how-to videos for help content. Not only that, but you needed to be at least somewhat creative, and for some odd reason one person's Camtasia video always looked totally different from the next person's Camtasia video, because the software provides too many options in terms of timing, music, layers, and styles.
A lot of people at our company were comfortable using Loom to send each other videos back and forth, discussing bugs or internal issues with our software. And some of our customer success folks even sent Loom videos to their customers to troubleshoot specific problems.
But when I suggested to use it for how-to videos, no one wanted to use it. "It's a little too informal for training material", I'd hear. It was mainly an internal communications tool.
"I hate hearing my own voice or seeing my face on video. Plus when it comes to recording for customers, I need to get ready and look presentable!
And I need to sound cheery and upbeat in every video, even if it's one of those low-energy days.
I just want to explain how to do something clearly and easily, without needing to be the 'star' of the video."
And then the pandemic hit.
By now I was working as a Product Manager, coordinating a bunch of moving parts with a bunch of very different personalities.
After some growing pains I matured into the role. But I still felt the same problems around training. And not just for our customers, but also for our internal teams looking to learn how to use new software features.
I needed a way to train everyone--our internal teams and customers--all at once, and only once, in order to keep some semblance of sanity. There just wasn't enough time or resources to effectively create a "single source of truth" that all our audiences could use as a learning tool.
But because of COVID I was working from home, so I resigned myself to solve this problem by learning how to code.
I spent every available hour learning everything about programming, from front-end development to backend servers.
I built 2 web apps as practice, just to make sure I wouldn't waste anyone's time with a sub-par product. I used these "test products" as a way to learn UX. I recruited strangers for usability testing, and finally felt I was comfortable enough to tackle my own help content problem.
And ScreenDocs was born.
We're currently in beta mode, which means you can use ScreenDocs for free while we continue to develop it. All videos you make during beta are yours to keep, simply click our "Download video" option after you publish your video to keep the file forever, and use it however you wish!
During beta we are actively seeking feedback and insights from our users, so all feedback (good or bad) is super helpful!