Knowledge Base Articles > Tips for Presenting Your Wireframes
Now that your wireframes are done, what do you do with them?
In this article I'll describe some techniques for being prepared when the time comes to present your wireframes to clients and stakeholders.
As a designer (or temporary wearer of a designer hat), you need to jump into the mind and world of the end user. The user is the ultimate customer of your wireframes, and your job as the designer is to create something that solves their problem in a way that makes sense to them.
But the end user is not your only customer. In the vast majority of cases (unless you are a one person operation) your designs will need approval from someone else (possibly many other people) to proceed. It could be the developer who will be writing the code, the Product Manager who owns the project, or the clients who may (or may not) be buying your product.
In one form or another, you need to get "buy-in" on your designs. Many young designers often incorrectly assume that getting the go-ahead on their work is achieved by creating the best design possible. Great design should be obvious to everyone, right?
Not so fast.
Tom Greever, author of the book "Articulating Design Decisions", states:
Your ability to be thoughtful about a problem and articulate any solution is more important than your ability to design the perfect solution every time.
My experience backs this up. Read on for some tips for presenting effectively once your wireframes are done.
After working hard on an awesome set of wireframes, the last thing you want is a critique of them. But you have to learn to be ready for your "presentation" to be more like a conversation. Your design might be very good, but accepting input from others can make it even better. Being in the right mindset will make it feel less like criticism and more like consensus-building.
If you go in being open to suggestions you'll come out with a better final product.
Here are a few ways that you can lead the inevitable feedback you'll receive.
Admit your uncertainty - Just like with any presentation, being humble helps get the audience on your side. You may be presenting to subject matter experts and if you come off seeming to know absolutely everything you can sound smug or cocky. Talking about some areas of your design that you're unsure about or, better yet, inviting suggestions from the audience, can build a collaborative atmosphere. Incorporating another person's idea will give them an investment in the design and turn them into an advocate for it.
Have alternates prepared - If you expect that people might not like some part of your design, have some alternates ready to show. It's better to show that you've considered other ideas than to let people think that you threw something together casually. If you've taken your time, then you should have some alternate or abandoned ideas to show. Don't be afraid to show something incomplete (including paths you gave up on). Describing why you chose your primary design over an alternate will help justify it.
Showing this evolution — what designs died and which ones survived — helps substantiate the final result. It shows you have explored options, not just executed on the first whim.
- Todd Moy
Try making some changes live - If you've got a really lively crowd, stop the presentation and have a mini design session. Open up Balsamiq and make some edits to your wireframes directly!
In the vast majority of the cases, there is something that led up to what you're presenting. A previous version, an existing tool, or prior work on the same project. Start there before showing your designs. Give a "recap" of the project to date.
Show the audience how what you're about to present fits into the context of the project as an evolution toward a final goal (even if it's part of a much larger goal).
This can include fast-forwarding to what you'll be working on next. If you've taken the approach of building a bridge to or from your "3.0" vision, then you can even show a glimpse into the future to help show how your design brings the product closer to the end goal.
Doing this will show how what you've designed fits with the previous work, or is an improvement over it, and how it connects to the next steps or lays the foundation for them. Show your design as a stepping stone on the path that everyone wants to be on.
By doing this you are incorporating a few established UX techniques together:
Finally, be prepared for some push-back on your work. Sometimes it's because you missed something, that there was something you hadn't thought about (in which case you can ask for help from the audience, as described above), but resistance also arises because good UX challenges assumptions.
The best design is frequently not exactly what the customer asked for. If you've done your job and studied the problems that customers have, rather than only the features they ask for, you may be proposing something unexpected. In any case, be ready to defend, or at least discuss, the design decisions you made.
Returning to Tom Greever's work on articulating design decisions, he suggests a list of common explanations, or justifications, for why design decisions are made. They are:
I have found the first two in particular - "facilitates a primary use case" and "follows a common design pattern" - to be especially compelling.
You first need to get in the habit of justifying design decisions to yourself. Returning to the primary use cases (you do have these, right?) and following established UI patterns are excellent guiding principles. If you've followed these during the design phase, you should definitely mention them during the presentation. Depending on the project, product, or audience, the other explanations may be even more effective.
This short video from Nielsen Norman Group reinforces these ideas.
If you've done your design work correctly you've taken the time to step into the shoes of the end user. Presenting your wireframes is the time to step into the shoes of your intermediate customers, your presentation audience.
You may care about how it looks and how it works, but your audience may care more about how long it will take to build, whether it can be built using their tools and frameworks, or whether it can be marketed successfully.
So, once your wireframes are done, take some time to review the assumptions you've made along the way, go back to your notes from meetings before you started designing, try to anticipate how your audience might respond, and review the tips above.