When putting screenshots of an application in technical work (such as a manual for end users), most screenshots will require editing to be usable. Extraneous UI elements may need removed, spacing may need to be altered so that the image can fit into the designated area, etc. As an application changes, screenshots need to change to, which can be tedious when all of the screenshots are raster images.
I've seen some technical publications that use "wireframes" instead of actual images of an application. These are form applications that already exist; these aren't wireframes intended for development purposes. These usually include most of the UI elements so that the user can recognize the screen, but by nature are not exact representations of what the user will see.
Below is an example. The first image is a screenshot of an application (edited already for size, etc) and a vector wireframe of the same screen.
The wireframe has a few advantages. Being an SVG file, it will look better in print. When parts of the UI change (e.g. a new feature was added to a screen), it is much easier to modify the vector instead of stitching together a new, edited screenshot. SVG graphics can also take advantage of a VCS like git. It is also possible to make interesting bulk changes to SVG graphics (e.g. using a regex to find all instances of "Login" and change it to "Sign in").
The downside is the resulting image no longer shows the actual application it is explaining. My question is is that a problems?
- Is there any evidence that a wireframe instead of a screenshot would confuse a user working with an application? (anecdotal or otherwise)
- Are there any best practices when substituting a screenshot with a wireframe?
- Besides not looking exactly like the application, are there any other pitfalls to using a wireframe instead of a true-to-life screenshot?