Presenting a UX design

Question

Say you're responsible for the prototype cycle of of a development project. Your end result might be something like an analysis of existing related solutions, a user model, a collection of scenarios and a collection of wire frames that you've thoroughly tested on a user group.

How do you present this to the developers and project managers? You could just dump your dropbox folder in their lap and tell them to sort it out, but if you're a usability designer, that goes against your principles. You should communicate clearly, give the important ideas prominence, make the users (ie. readers) feel comfortable. You will want to communicate your design, and why it is the way it is.

Is there any literature on this? Do you have examples of particularly beautiful, effective and complete demonstrations of usability designs (both documents and presentations)? Low-fi designs (like wireframes) are great at communicating a message, but they lack impact when it comes to getting people enthusiastic about the project (and implementing your ideas).

Answer 1

You might find "Communicating the User Experience: A Practical Guide for Creating Useful UX Documentation" by Richard Caddick and "Communicating Design" by Dan Brown useful reads.

The short answer to this question is that there isn't a short answer ;-)

My personal mind-hack for approaching this issue is to treat it as a UX problem in of itself.

What's the problem you are trying to solve? Who are the users (developers? managers? PMs?) How do you solve their problem as effectively as possible.

If, for example, you're working with a co-located poly-skilled agile team you're deliverables are going to need to be very different from a highly siloed distributed team.

Apply your UX skills to the problem of communicating the design.

Answer 2

Presenting a UX design is never a single task that you do once and never do again. You goal isn't to present your design, but rather to get it implemented. Sharing your design is something that you will do over and over again throughout the development process, regardless of whether the process is agile or waterfall or some mix therein.

The way that you communicate your design depends on the needs of your audience. Your communication style needs to match theirs. If they communicate exclusively through their bug-tracking mechanism, then your design needs to be communicated there too. If they communicate via wiki, then your design needs to be wiki-fied. If there's one stakeholder who really needs to buy off on your design and everyone else will follow that person, then you need to figure out who that stakeholder is and figure out how to get them to buy off on your design. If everyone needs to come to agreement that your design is the one that they will implement, then you probably need to have one discussion with project managers and a different discussion with engineering. Each of those groups have different goals and different needs, so having a separate discussion with each of them means that you're able to address their unique goals and needs, as well as answer any questions that they might have.

You'll need to do this more than once. You'll need to track the development process and ensure that your designs are being acted upon, and communicate with the team if they're deviating from the design. It might be that they've forgotten elements of your design, or that someone new has come on board and simply isn't aware of it, or they disagree with it and so are conveniently disregarding it, or (as in every software project that has ever existed) they're having to make changes to their plan (adding features, cutting features, cutting parts of features, etc), and thus parts of your design are impacted by those changes. If they're going to make design changes or compromises, you should be a part of that discussion -- you know the design the best of anyone, and you know why you made the design decisions that you made, and you can help them make decisions and discuss the trade-offs between development time and user experience.

Remember: no-one cares about your work more than you do. For your design to be truly effective and fully implemented, you're the one who's going to have to track it and make sure that it actually happens. A beautiful design that never gets implemented is meaningless.

Answer 3

This borders a little bit on where Graphic design (presentation) and UX meet.

Since you asked about literature, you might want to go to communicatingdesign, and take a look at Dan Brown's approach.

Can you be more clear about who you are presenting to?

I'm assuming you're talking about in-house teams, but if you're in a consultant role, your deliverables need to be a bit more fleshed out, specifically including the value proposition you're design is adding to the organization that hired you. Much more of a sales job.

Even the clearest presentations need a lot of follow up through the development phase.

Your most beautiful (and clear) documents may not count for alot if you are not in regular communication with the team. That's what agile has over waterfall (as I've experienced it).

Answer 4

The solution is to talk and work with the developers to work out what is needed. Talk them through the research and results and ensure any document with information has a summary and overview to make them more digestible.

Working prototypes with visual design are great to show how things work (and also a degree of visual design leads to better user testing - I try to avoid user testing with wireframes). I find that if you have simple wireframes supported by a few designed screens with key interactions prototyped then that is enough for to get the concept across before moving to the more involved design phrase.

In an idea world you'll be working closer with the developers and communicating via things on a wall! The aim should be to minimalise the amounts of deliverables produced and ensure that everyone is aware of which is the one version of the truth in terms of agreed solution. I have done projects where the site structure lived on a white board.

So, in summary, there is no one way to create deliverables that will work for all projects. Much as we talk to users to discover the right solution for them so it is also a good solution for discovering what our team members need to enable them.

Answer 5

The answer you come to, perhaps with some advice here will be a process that you and your team arrive at together, with you diving it. In the same way that you try UX designs and test their effectiveness, try variations on the process and settle on the method that works best. There may be more than one.

Meanwhile, I can offer a process that I found works well for the projects I work on that involve presenting a pictorial presentation (images of wireframes or designs). If I want to present a concept or user flow as a user might see, I drop the images in a Google Presentation. The click through of slides matches the flow. Notes can accompany the slide. And over all it provides a smooth presentation whether some is looking at it solo or I am guiding it.

If I am delivering a specification for engineers to work off of, I use a Google Document. This way I do a text and graphical write up for engineers to follow.

The benefit with both of these is that they are shareable and viewable anywhere. They rest in a central location. The links can be pasted into ticketing systems. And people can comment and edit them if need be. They canalso be viewed solor or used as a guided presentation.

HTML prototypes are a different story but again, the link to a prototype can be put in the doc.

Try it out and see if this works for you.