Tips for Presenting Your Wireframes

Now that they're done, what do you do with them?

I recently wrote an article for the Treehouse Blog called "3 Steps to Better UI Wireframes" that provides some wireframing tricks that I've learned in my career as a UX designer.

The three steps I outlined were:

  1. Get into the Wireframing Mindset
  2. Take Your Time
  3. Build a Bridge from MVP to 3.0 (or the Other Way Around)

In this post I'll be following up on those steps by describing some techniques for being prepared when the time comes to present your wireframes to clients and stakeholders.

The Other Customer

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.

ST042: Figure 15.13

Image credit: "Storytelling for User Experience", ©Rosenfeld Media

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.

1. Be Open to Changes

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!

2. Provide Context via a Timeline

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:

  1. Telling a story
  2. Answering the question: "Why are we doing this?" - what the PM or CEO cares about
  3. Clarifying that you understand the interests of everyone involved.

3. Be Ready to Talk About Your Design Choices

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:

  • Facilitates a primary use case
  • Follows a common design pattern
  • Meets a particular goal
  • Data supports it
  • Complies with a standard
  • Limited by technology
  • Draws the user’s attention
  • Creates a flow for the user
  • Establishes branding

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.

Summary

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.

Good luck!

Get the Inside Scoop

We'll send you just one email a month and share a ton of information that you'll get before everyone else. More info about the newsletter here.

We'll never share your email address or spam you.

Leave a Comment

Your email is never published nor shared.

Comments (1)

  1. Pingback: Presenting wireframes for maximum impact | Pragati Sinha