Screenshots often make or break your software’s user manual. If screenshots are important for your documentation, you may want to consider creating the screenshots first and then basing the text content on the screenshots.
Do what’s important first.
My muse: test-driven development
A popular software development methodology is test-driven development (TDD). It is possible to write scripts that test software for defects after a programmer makes changes to it.
A common problem is that software testing is an extra step, and often it’s tempting to skip it. TDD dictates that you write your tests first to avoid the temptation to just skip it. In this way, you’re prioritizing the testing by doing it first.
Why not treat screenshots for your documentation the same way? Do them first.
Story-boarding with screenshots
Doing screenshots first actually makes the process flow more smoothly. You end up using the software that you’re documenting to make the screenshots, running through the process step-by-step, taking snapshots of key steps along the way. This helps you make sure that you’re describing the steps correctly and in the right order.
Actually, this procedure is similar to storyboarding, used for creating movies, videos, and animations. You lay out how the story is told with images before constructing the story with the actual content.
A bonus with this particular process is that instead of storyboarding with sketches, you’re story-boarding with the actual screenshots that you’ll be using in the final documentation. Win.
No words. Show, don’t tell.
Fill in the cracks with text
Sure, our start to the documentation doesn’t make a whole lot of sense on its own. This is where you will in the cracks with text:
Within the Files section, you can get started by clicking the New File button in the upper right:
On the New File screen, you’ll be presented with two choices:
- Upload File from Computer
- Open File from URL
To upload a file from your hard drive, click Upload File from Computer:
Next, click the Choose Files button to select 1 or many files to upload:
Et cetera, et cetera…
The end result: your text ends up pretty light, letting the visuals drive the story. The user can make sure that they see what they’re supposed to be seeing every step of the way. And using hard examples is far better in this situation than describing everything in abstraction.
Believe me, it’s usually much worse when done the other way around: heavy text with sparse usage of screenshots. Companies with thick, hard-to-understand technical documentation like Oracle and Microsoft come to mind. You don’t want to be like them, do you?