3 Obstacles When Presenting Wireframes

Based on my past experience with presenting wireframes to stakeholders, I believe many designers and UX specialists run into the same issues related to persuasion, understanding and collaboration. Here are some ways to mitigate some of the challenges of these wireframe review meetings.

Some content originally posted on Design Festival by Emily Smith

Wireframes are intended to lay the groundwork for design open up dialogue, establish direction, refine scope, and create a sense that progress is being made on a project.
In order to do these things it demands the right preparation. Here are issues to be aware of for your next presentation.
  1. The Problem of Abstraction

  2. Some people are abstraction geniuses, but for the rest of us it’s mental gymnastics. For example, I used to work with a product designer who made high end tools that looked like they came from outer space.During his paper sketching phases, it would be impossible for me to get a feel for the final product. The 3-​​d renderings were easier to digest, but nothing compared to holding the final product. It was always interesting to see where I was off on my assumptions about how the tool would work, feel, weigh, and look.

    A rendering of a paint sprayer and a photo of the final product
    One of his renderings vs. the final product, used with permission

    Similarly, as soon as any type of mockup or sketch of your web site is presented, each person who sees it begins constructing a different vision in their head of how the final product should look and feel. Assumptions and heuristics allow us all to function with efficiency in life. You, your clients, and team members are all employing these mental tools during the project. This is perfectly reasonable behavior, but it creates risk for unmet expectations. We have the ability to lessen this burden, though, and I’m going to flesh out specific ways to do this in my upcoming posts.

  3. The Power of Suggestion

  4. A means of persuasion. Your wireframes and the way you present them are a powerful tool of influence that steers the whole project. If your solution is slightly under-​​baked but you’re a great salesperson, you may be able to push through to approval (possibly against the best interests of the project). On the other hand, you might have a great solution but be unskilled at selling it with confidence and enthusiasm and so it isn’t as well received. Thankfully, we have a way to help minimize this problem.

    Information as an antidote. The least stressful documents to make and present are based on careful and thorough information-​​gathering. This won’t be statistically significant but it will lead to insights that can be shared with everyone and will take the conversation beyond personal opinion. That way, even when you are highly trusted by your clients (and most persuasive), they will be equipped to ask critical questions. If wireframe meetings are characterized by agreement without discussion, or conversely if you feel like you’re working too hard to sell them, then problems are likely to pop up down the road.

    Wireframe example

  5. The Difficulty with Feedback

Clients get a bad rap for offering unhelpful or heavy-​​handed feedback. While that’s true in some cases, I’ve found it’s often a lack of guidance and leadership from us that leaves clients scrambling to offer useful critique. Each client personality and skill set is unique but here are some general purpose questions to help guide feedback next time you are getting ready to present wireframes:

  • Does your client/​team know why you’re having this meeting? Starting a meeting out with this simple recap does wonders.
  • Have you explained what a wireframe is to this client before?
  • Do they know what a wireframe is not meant to be? Are they expecting to see visual design? If you’re not sure, it’s helpful to show them a past example of a wireframe next to a screenshot of the final product.
  • Have you given them specific examples of what kind of feedback is appropriate and what isn’t? e.g. “The XYZ program is gaining importance and should probably have more emphasis” focuses on the goals of the site and is appropriate. “Can we make the XYZ tab bold and purple so it stands out more?” focuses on the mechanics of the visual design and is not appropriate.
  • Have you explained to them what role their feedback will play?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.