My agency currently includes wireframes in our project definition documents. Each key page is described along with its wireframe, basic interaction, input fields etc.

However, I'm not sure if this is an effective way to show the wireframes. The large amount of textual information between wireframes seems to break the flow and interaction between pages.

What about other deliverables such as the user journey? Should they be separated out of project management focused documents?


Thanks for the responses, but perhaps I should have worded my question better!

What I meant to ask was: if you're emailing the client a project definition document for their review and sign-off, would you include wireframes and interaction notes in it? Keeping in mind that project definition documents contain other project-related information, is it better to package wireframes separately?

  • It sounds like you're dumping a lot of documents on your client's laps. I think the question is really for your PM's and Account Exec's.
    – DA01
    May 3, 2012 at 1:44
  • Why is this question open? It's extremely opinion-based.
    – dnbrv
    Feb 12, 2015 at 18:57

12 Answers 12


An alternate visual technique is to employ comic style storyboards. You could show how a user would interact with the wireframes. Clients find these storyboards easy to understand. They are especially useful for communicating interaction, and users' emotions.

You will find free or affordable tools for creating comic strip storyboards, e.g. http://plasq.com/products/comiclife/win (a desktop tool) and http://bitstrips.com/create/comic/ (online tool).

My preferred approach, however, is to create a slideshow presentation, with each slide functioning as a frame in the story.

You don't need to have drawing skills. I have found this canned set of characters and scenes useful.


I've started to change my practice from static mockups and wireframes to doing dynamic prototypes. It gives customers a concrete visualization that they can click around and see how things move and change. You know both you and the customers are talking about the same thing, and you can have good conversations about next steps.

You can get pretty far with interactive prototyping/mockup tools like Balsamiq Mockups.

I'd challenge you to take it further...I'm continuing to change my UX toolbox to deliver HTML prototypes. The benefit here is that you can show how a design shifts and morphs on different platforms. jQuery, CSS3, and modern browsers make it fairly straightforward to get some basic prototypes up and running quickly. There are also some great responsive design rapid prototyping frameworks:

These tools include decent styles and javascript plugins that make it pretty quick and painless to throw together a responsive, interactive prototype.

  • Prototypes are definitely what should be preferred as a client deliverable over wireframes. Bonus points for them being HTML already.
    – DA01
    May 3, 2012 at 1:45

it sounds like there is more features and functionality than can be described by simple wireframes which suggests you need supporting documentation as described by my good ux exchangers above in the form of interaction notes or a functional specification.

Another approach, and one that I find works the very best, is to build a working greyscale prototype. Believe me, a working, clickable prototype does so much more to illustrate how the system and various components, IA, etc work. Maybe more work for you but much more illustrative than wireframes alone.

Of course, if you are delivering a hundred wireframes then maybe not a practical approach...in which case prototype a section of your system.

Also: prototypes communicate to development in a way i don't see with wires/functional spec....



Axure prototyping tool and http://share.axure.com/ work best for me.

It allows you to do lots of things in the desktop app and upload interactive prototypes to Axure share server (or any other), leave comments etc. Also there's lots of elements libraries, most of them are free, so prototyping becomes very fast.

E.g. this page was made in something like 15 seconds – https://skitch.com/kisasosisa/8au3g/iride-dashboard

Though there're some issues while convertin Axure .rp files to html, it's one of the best thing I've used (except for the whiteboard whic is also free:)


I have found that presenting wireframes in person is always more effective. It allows you to craft the experience, and present these as you intended them to be "seen".

If you follow the UCD process, you can tie what is in the wireframes back to users/goals, which usually helps a client tie it all together.

Try to keep annotations UX-focused, so as not to provide useless information to a client who may only be concerned about look & feel.

Don't hesitate to write companion briefs or presentations to set the stage effectively.


Do your best to fully explain a single interaction in a single view. In other words, the wireframe and the text describing it should always be visible without flipping back and forth between pages. If you are binding in book format you can use facing pages... if it's single-sided stapled, then keep descriptions to one facing page. I strongly recommend using spiral bound or binder format because a single 8.5x11 per interaction is rarely sufficient.

This may mean repeating a particular wireframe on multiple pages, perhaps focusing on a different portion each time. For a complex dialog you may separate it into regions (header, menu, tabs, form, etc), with a zoomed example of the current region you are discussing.

For processes and transitions I do an overview with all the steps shown on a single page (when possible) and a quick description, then one step per page so paging forward takes them through a single interaction.

When it comes to branching and dealing with multiple paths, I emulate choose your own adventure books. "If you select option A, turn to page 34. If you chose option B, turn to page 40." Customers usually enjoy that, and even if they don't find humor with it it remains one of the best ways to represent branching choices in a linear book format.

As far as whether project management should be separated from the presentation of the UX, I believe that is off-topic. Personally, I don't think it matters either way; mine have been separate because I was never the one creating the project management documentation.

  • That seems like a lot of overhead. Clients don't want to read about the interaction--they want to see the interaction. I'd be worried that this would actually slow down the process--both in terms of the UX team having to become document managers and the client having to interpret static documentation.
    – DA01
    May 2, 2012 at 15:18
  • If your interaction can be shown completely visually, or you will be presenting it in person, that's fine. Sometimes interactions are complex; sometimes they are not. I'm just saying that for any image that requires description, never have that description cross into a page where they can't see the image wireframe it discusses. May 2, 2012 at 19:49

I prefer to present the whole concept in a high-level sitemap. In the sitemap I visualize the main concepts of a website or application (eg. 'the shop', 'blog', 'members only' etc.). In this stage it's a kind of infographic or even a sketch with some small storyboards illustrating the most important points of conversion.

For presentations I use a html-mockup (balsamiq or azure rp) The mockup is a 'clickable wireframe' (downloadable via the project space) in greys and sometimes in a sketchy style. During the presentation it helps clarify the most important click-paths.

For the sign-off I use the document with annotations (indesign or axure rp converted to a pdf). The wireframes are really useful for designers and developers for the execution of the idea into eventual content, code and media-assets. And yes - depending on the development process - this can be a long document.


Wireframes should rarely be presented to clients. Wireframes are an important internal tool for UX to build the product, but not a useful way to communicate details with clients.

Yes, that's a broad generalization, but I find it true more often than not. There are times when you have clients that fully understand the ideation/exploration process, but all too often, wireframes are 'real' in their eyes and suddenly you're bogging down the entire process with them worried about fonts.

An analogy: An architect produces copious amounts of blueprints. And a client can interpret them to a degree, but the blueprints are really for the team building the product. What the client wants/needs is an actual prototype--be it a model, or a 3d rendering/walk-through. The point is that wireframes are really blueprints, and while some clients can envision the product based on those, most clients are best served by giving them something more tangible to digest.

  • I think that is too broad a generalization to be useful, here. I agree that you have to set customers expectations on what they're seeing from a wireframe, but I have found value in showing wireframes as a way to get feedback on a design direction. Since you don't like wireframes, what else could be done to communicate with clients? May 2, 2012 at 18:10
  • I didn't say I don't like wireframes. They are a valuable tool in the UX process. What they aren't, however, is terribly useful ways to communicate to clients what the product will be. Yes, there are exceptions, and there are ways to help facilitate that, but in general, large amounts of wireframe documentation isn't all that useful for clients. They want to see clickable interactions. For those downvoting, I'd love to hear why. I think it's a fascinating topic.
    – DA01
    May 2, 2012 at 18:57
  • 1
    Why is this answer being downvoted? I upvoted it because I think it's relevant to the question. I agree with the part about showing the client something tangible. When possible, I try to give the client a URL they can go visit. And yes, wireframes can be dangerous because some clients believe that the wireframes are THE actual, or at least almost, finished product. Feb 12, 2015 at 19:13
  • 1
    @ricardozea My only hunch is that there are UX people that feel wireframes are the only deliverable a UX team should provide. I get frustrated with those teams. It's rarely a good solution.
    – DA01
    Feb 12, 2015 at 19:18
  • 1
    @DA01 Agree, wireframes are a mere tool for layout exploration. After creating wireframes for quite some time now, I've come to the realization that wireframes are too idealistic and dangerous at the same time: they describe a single fraction in time of a layout/page when every single element is in absolute balance and harmony with the whole structure. It can't depict what happens to its elements 30 seconds later when its content is viewed in a different platform or interacted with in a specific way. Yeah, dangerous as hell if you ask me. Feb 13, 2015 at 4:46

An example I have seen recently that may help you with this problem is by using video to show the user journey. While keeping your original document with notes and context an additional video file may help, record your screen.

Other ideas? You may find it useful to provide an extra set of files of just the wireframes and suggest the client prints the document, depending on the level of functionality an number system (buttons to pages) may help guide navigation. After all a lot of UX is paper based.


My wireframing inventory consists of Balsamiq, Invision App(http://www.invisionapp.com/) and Axure RP.

We have our own servers so, sometimes we make html based mockups using Axure and host them on our servers and send client the html link. That works most of the time.

However, in the case of mobile applications, we sometimes use invision app, it gets very easy to upload the wireframes with the web application and if we have clients who want an exact interface, they can install and use it in their mobile to check the UX.


There are several great responses to this question already, but I do have one other method I don't hear very often but have found to be very effective when communicating (mostly internally--I don't deal with external clients).

Have you considered making a screencast/screen recording of you running through the mockups? Using a program like Snagit, talk through the main points you want to make sure get communicated. I'd script out or at least outline what you want to say so that the video stays targeted and doesn't wander. But do record your voice instead of using text on screen--there's good research in the info communication world showing why text + visuals in a video is a bad idea.

If you want to get really fancy, you could use something like Camtasia to add highlights, animations, etc.

I've found that a couple of minute's worth of focused video can circumvent a lot of not-quite-understandings.


I find that this page offers some good tips:


  • 1
    Welcome to UX.SE! We encourage people not only to share links but provide summaries of their content in case the site goes offline in the future.
    – dnbrv
    Feb 12, 2015 at 19:05
  • fair enough... will expand upon soon! thanks for the note! Feb 13, 2015 at 20:56

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