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?

Update:

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?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

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.
–
DA01May 3 '12 at 1:44

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.

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:

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....

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.

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.
–
DA01May 2 '12 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.
–
Myrddin EmrysMay 2 '12 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?
–
fitzgeraldsteeleMay 2 '12 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.
–
DA01May 2 '12 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.
–
ricardozeaFeb 12 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.
–
DA01Feb 12 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.
–
ricardozeaFeb 13 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.

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.