When putting screenshots of an application in technical work, 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

Wireframe of previous 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?
  • I dont think the benefits you list are true. It is as easy for me to find and relplace gui items as it is to do so in SVG. It is easy to automatically redo all screenshots. Wireframes can easily be emitted from your gui code, its just a different drawing context no need to edit them on change just replace the images.
    – joojaa
    Sep 10, 2015 at 13:43
  • I think you question might be better answered on UX stack exchange. You seem to be asking about the effect of a medium decision on user interaction / satisfaction rather than design principles. At UX Stack Exchange, they're really good at answering this kind of question.
    – J.Todd
    Sep 10, 2015 at 14:04
  • It is a "technical work" I do not think a user will be confused by that. I think you will just mention that the screenshots are not exactly as the same User Interfase. But if your market is worth it, do a specific screenshoot for non technical users.
    – Rafael
    Sep 10, 2015 at 14:04
  • 2
    The debate is moot, as people don't read instruction manuals anyways. :)
    – DA01
    Sep 10, 2015 at 14:29
  • 2
    @JonathanTodd good suggestion; I just asked this same question over on the ux.se Sep 10, 2015 at 15:00

3 Answers 3


If the screen shots are there to assist a user in using the app, then they should be literal screen shots. Making them wireframes just adds another layer of translation the user has to do.

  • What if the software uses native OS dialogs and thus looks different on many operating systems?
    – joojaa
    Sep 10, 2015 at 18:04
  • @joojaa then I'd suggest picking one or the other.
    – DA01
    Sep 10, 2015 at 18:27
  • Ultimately it was the "unnecessary visual translation" argument that convinced me. There are contexts where a wireframe-like image would be appropriate (ex. for physical products or products that have so much UI variation that picking one would not be practical), but for software this is the exception, not the rule. Sep 15, 2015 at 14:45

Wireframes are used for the purpose of illustrating user flow, storyline and basic foundation of each page i.e. image placeholders, text placeholders, etc.... It gives an initial foundation and shape to the project...it captures basic elements of the project ahead...what the basic layout of each page, how many clicks it takes a user to perform a task. From personal experience I used to do screen shots but as you have mentioned yourself its tedious, unnecessary work of making a screenshot fit a specific narrative, getting rid of unnecessary portions, formatting...to me it would take twice as long than to do a wireframe from a get go. Plus screenshots usually already have a design done and it may not be the finalized design, thus creating further confusion for client, developer and anyone else involved in the process.

  • "Wireframe" might not have been the right word to use in my question, since it has a specific meaning/use among designers. In this case, the application already exists and I'm doing a wireframe of existing screens. This is similar to the drawings you might see in the instructions for putting together furniture. Sep 10, 2015 at 15:28
  • then perhaps you should do PROTOTYPING...if the application exists and all is need is instructions for "assembly" you can use existing screens to put the flow together ...try marvelapp.com ...unless I am totally misunderstanding you
    – Stanley VM
    Sep 10, 2015 at 16:40

When I am creating training materials, I use screen shots.

If I want to demonstrate flow of a page or specific interactivity, I create a prototype. I have often found that in the initial stages of a project using generic b/w wireframe using either Arial or Geneva are the best way to go. That way my client or colleague can focus on the big picture.

When all interactivity, page flow, and sitemaps have been created than I introduce color in the the medium fidelity wireframe.

Your Answer

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

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