2

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.

Screenshot of application

Vector representation of above UI

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?

2 Answers 2

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.

enter image description hereenter image description here

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.

2
  • Could you clarify what you mean by a "minor skin alteration", and perhaps provide an example? Sep 15, 2015 at 11:26
  • 1
    @Scribblemacher Sorry for the slow response ... I'm thinking of an app that might have a lot of superfluous visual treatments that don't translate well in instructional graphics (like subtle gradients, excessive shadows, etc). You might choose to downplay those effects for the sake of clarity, but you'd have to be certain it didn't significantly alter the visual hierarchy and overall impression of the UI. Sep 21, 2015 at 6:15
0

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.

3
  • 1
    yeah I think generally you'd be fine. To really serve the user best it would be nice if the representation was as close to the real thing as possible, but if it can't be then wireframes with all the items in the correct proportions and position is fine. If you think of all the instruction manuals you get for things like ikea furniture, electrical products etc they all have a simple black and white representation of the real world item.
    – Chris
    Sep 10, 2015 at 15:12
  • Could you clarify what you mean by "not receiving enough validation from the user about colors or sizes"? I'm not sure what you mean (I think I'm getting tripped up on "validation"). Sep 10, 2015 at 15:31
  • I mean to say it'll be difficult for you to know if the colors or sizes you've used for the final design could be correct or not. For example, as a Wire-frame, we are seeing black and white. But say, the final design features weird colors like yellow and orange together. This might trouble the users who are going to use this for a long period of time and might affect them psychologically. Sep 10, 2015 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.