Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this 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. –  DA01 May 3 '12 at 1:44
add comment

9 Answers

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.

share|improve this answer
    
Prototypes are definitely what should be preferred as a client deliverable over wireframes. Bonus points for them being HTML already. –  DA01 May 3 '12 at 1:45
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '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 Emrys May 2 '12 at 19:49
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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? –  fitzgeraldsteele May 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. –  DA01 May 2 '12 at 18:57
    
@fitzgeraldsteele Though...'never' is perhaps too harsh. I'll edit to clarify! –  DA01 May 2 '12 at 18:59
    
all right, people. If you downvote, please explain. –  DA01 May 3 '12 at 15:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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