Is using a wireframe instead of a screenshot acceptable in technical work?

Question

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?

Answer 1

Don't create unnecessary visual translation.

In the case of physical product manuals (as mentioned in another example), schematics are quite common. This is true for a couple of reasons: the cost of photography, and the complexity of three dimensional visuals in information graphics. Software suffers from neither of those.

When you take something that is easily represented in two dimensions and arbitrarily alter it's style, you create a barrier for the reader (however small it may be). They now have to consider your application as a collection of content rather than relying on the visual cues that your interface designer has created for them.

Let's look at one example in your visuals. Here we see two identical areas represented with considerably different visual hierarchy. There's even a change in to the delete icon.

The fact that a screen shot and wireframe don't match perfectly is no surprise. In fact, it's expected. To reverse engineer a wireframe to keep up with the iterations of a working interface is no small effort. I would argue that it's wasted effort, in most scenarios.

Visually simplified instructional graphics

All of that said, there are cases where simplified interface visuals for instructional purposes makes sense. The best way to handle that is to apply a minor skin alteration to the app. Obviously, this is easier to do with a web app than what seems to be a Windows app in your case. But it's not impossible, if the app is built correctly.

Answer 2

Wire-frames are generally created far ahead before generating the final UI.

As long as your Wire-frame represents the app without any structural changes, you should be fine. UI Elements such as Checkboxes and Buttons will change as per platform.

Although there isn't any evidence about using a Wireframe instead of a Screenshot, you could think of product manuals of any physical product you order.

They only represent the structure of the product you've ordered and not 1:1 identical color schemes or model. Yet, they are far easier to read in the manual and understand the position of the buttons, etc.

As far as your Wire-frame goes, I think it accurately depicts the final UI, and could definitely give the User an idea of what to expect.

While substituting the screenshot with a wire-frame, make sure the structure and positioning of the elements is correct. When scaled to fill a huge screen, the position may vary with the spacing, but as long as the structure is correct and the user recollects the positioning from the Wireframe, you should be fine.

The only disadvantage I could think of is not receiving enough validation from the user about the colors or sizes of the buttons you might have used. They could be smaller or brighter which you would need to implement in maintenance later on.

P.S. If you could have interactive exercises for the Users with the Wireframes, they would recollect the design even more when they move into the final design.