What is an effective way to present wireframes and other IA deliverables to client?

Question

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?

Answer 1

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:

• Foundation from Zurb
• Bootstrap from Twitter

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

Answer 2

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

c

Answer 3

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.

Answer 4

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:)

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.