Screenshots are an important part of user documentation for any product that has a UI. They help guide the user through their journey accurately and swiftly and improve the quality of documentation. A properly annotated screenshot can replace paragraphs of prose. It can make documentation easier to read and digest for users. It can reduce confusion by making it easier for users to identify where controls and inputs are in the application. It can make your documentation look more professional and refined.
On the other hand, a low quality, or inaccurate screenshot can hurt your documentation. It can send users down rabbit holes looking for buttons or fields that are no longer in the application. It can be zoomed out too far to read, or zoomed in too far to be useful. Low-quality screenshots in documentation can make them look unprofessional and turn off users (or worse, prospects).
The Worst Parts of Manual Screenshots
It takes a lot of time and effort for technical writers, and other content creates to create and maintain screenshots in documentation, marketing material, websites, and other places. It’s unfortunate that we still have to do this work manually
We all want an abundance of time so that we can do things right: keep documentation, marketing materials, and websites up to date. The fact is that we don’t. We’re strapped for resources and time, and we aren’t able to go through products and documentation over and over again to locate errors and inconsistencies and correct them. Remember when Engineering added that checkbox to the form? Neither do we, and chances are, it’s going to be a while before anyone does.
Taking screenshots manually almost guarantees that screenshots will lag behind product updates. It’s just part of the game.
If you create documentation, marketing materials, or websites for a software product, I’m sure you’ve:
- Opened up the application
- Configured it for your screenshot
- Opened up a form
- Filled out the form with sample data
- Positioned the scroll bar perfectly
- Expanded all of the accordions
- Clicked on the dropdown
- Took the screenshot
- Reviewed the screenshot
- Saved it away to use in your material
Only to realize the next day (when you start to write the document) that you left a typo or something snarky in one of your form fields, and you have to go back and do the whole thing again, edit the actual image to get it right, or just allow the error in the documentation.
The best parts of working for a good software company are that they release lots of nice, well-tested, well-documented features very often, and they fix lots of bugs and UI issues quickly. The downside of that is that the UI changes frequently, and your meticulously crafted screenshots are no longer accurate or relevant.
If you’re lucky or smart, you’ve figured out ways to edit your old screenshots to include UI updates. Maybe you use a layered image editor. Maybe you add your text to the forms.
For most of us, we just have to go back in and re-do the screenshot. That means doing the whole thing over again and suffering from the same mistakes and errors we did the first time.
I’m not saying it’s insanity, just including this image here.
Environments and Setup
Technical Writers and marketers don’t usually have access to the source code. They don’t usually have access to the build system. Often, we are stuck with one staging instance, or if we’re lucky, a staging instance and a test instance. Sometimes they work, and sometimes they don’t. Usually, those instances get blown away frequently, leaving us without the configurations we made previously. Before we can even get started on screenshots we have to: check status, maybe chase down an engineer, maybe move on to something else, and maybe exclude these screenshots entirely.
Even if we start with a running instance, we have to dance around Engineering and QA, reconfigure global settings, add new records and configurations for our scenario before we can go get our screenshots.
It’s funny when you start thinking about what size of screenshots to use, or what color to make your annotations and then compare it to what’s ACTUALLY in your documentation. It’s hard enough to maintain consistent image sizes and annotation colors as a lone writer, much less as a team. For large documentation sites with hundreds of articles and topics, it’s almost impossible to get it consistent every time.
Most of us are strapped for time and resources and are willing to ignore these minor inconsistencies as long as the document is shippable, so they often wind up in the final product. Inconsistency is just a part of manual screenshot collection.
Did you sign up to be a technical writer, marketer, or web developer so that you could click the same seven buttons over and over again, and hit the print screen button? Neither did I, and neither did anyone else in these positions. We got into the software industry so we could solve big problems in cool ways, craft language, technology, and art so that it speaks to our audience, to dream big, and think our way through complicated things.
None of us signed up to take the same screenshot over and over again, but the fact of the matter is, many of us have to. If you’re bored of taking manual screenshots, or manually producing videos, stay tuned at the UserDocs Blog for more information about automating media production.
If you’re interested in starting your journey to automate the production of your screenshots and videos, sign up for the Alpha release of UserDocs or chat with us. We’d love to hear from you!
Leave a Reply