How to get the most out of your next wireframe review
Wireframes are fun. It’s when strategic thinking and planning start to come to life visually. As the team tasked with implementing wireframes into a functioning website, we’ve seen a bit too often the downside of the wireframe process: scope creep, strategic thinking thrown out the window, and projects losing focus. While some of this can be attributed to gaps in strategic thinking and misalignment of stakeholder priorities, we’ve also found that improving the mechanics of running the wireframe review sessions can make a huge difference in the success of the project.
Wireframe Review Struggles
Here are some of the typical problems you’ll encounter:
Stakeholder confusion
Stakeholders are unclear about what they are supposed to provide feedback on when reviewing the wireframes. The most common example of this is getting bogged down in wording of a durable copy element.
Feedback is tactical
Reviewers react to specific elements with tactical changes they want (e.g., the size of the element should be bigger). This is a bit of twofer that typically has two outcomes: A. The underlying problem is obscured and no individual tactical change fixes it. This leads to more time/effort to reach the solution or using a less optimal solution. B. Changes are made to the wireframes when there is no actual underlying user problem that needs to be solved, just a personal preference to be addressed. And the problem with wireframing around personal preferences is that because it has no strategic basis, it is almost impossible to address well.
Assumptions are not stated
Most wireframes are based on best practices as known by the wireframer and extrapolations of those best practices. Occasionally, decisions are evidence based. However, when going over wireframes, the presentation is given as the only option based on what is known of the audience and the expertise of the consultants. In other words, assumptions about what will be the optimal user experience is unstated and, therefore, not up for debate. This leads to rigidity in how feedback is taken and incorporated and stymies discussion about the user experience and how core problems should be solved.
Corner cases get too much time
Reviewers spend too much time solving for problems that only solves for a small subset of visitors or, in worst case scenarios, audiences that were not previously stated or were listed as being lower priority. The downstream impact of this problem can be very expensive as more complexity is built in to accommodate what is essentially a strategic shift in direction.
Wireframe Review Solutions
So how do we address these problems and run successful wireframe review sessions? Here are Capellic’s top seven (lucky!) most impactful wireframe review tips…
1. Make sure you know what sort of feedback you want
Don’t assume that your clients know what sort of feedback you want even if they are familiar with the wireframe process. Are you only interested in content prioritization? Do you want feedback on durable copy choices? Write down what you want and make sure you discuss it with the client before they see the first wireframe. Here’s an example:
2. Do a *real* internal pass before reviewing with the client
The single most important thing you can do before reviewing wireframes with a client is to do a detailed, honest internal review first. Getting rubber stamp approval doesn’t do anything for the project. Get people who will make you defend decisions and will see the wireframe in different ways than you do. A developer may flag an integration question; an account manager may see that an element may require internal assets that the client is incapable of delivering on; the list continues. At Capellic, we’ve made internal reviews standard at almost every step of the project. There has never been a scenario where internal review hasn’t resulted something important that impacts the scope of the project or the site’s usability. You’ll be better prepared and the project will be better for it.
3. Be prepared to answer “why” for every element on the page
If you can’t answer why, it doesn’t belong on the page. If the “why” is because you’ve seen it somewhere else, be prepared to defend why specifically it is relevant in this use case. By the way, this may seem really obvious, but we’ve seen some of the country’s biggest agencies not do this well.
4. Know your scope limits and make them clear
This is especially true if some requirements are contractual. Talking contracts can be awkward and annoying, but avoiding it often results in scope creep and much much worse conversations about fees and who pays for what.
5. Require feedback to be stated in form of a problem that needs to be solved and who is impacted by the issue
In addition, make it clear that tactical suggestions must be restated as problems that need to be solved. For example: Restate “Make the text bigger” as “I find that text difficult to read.” This does a few things. First, it ensures that the problem is relevant to the stated strategy and expected user experience. Second, it puts you in the position of problem solver, which is ultimately the role of the wireframing consultant. Third, it can draw attention to bigger issues.
Let’s return to the “I find that text difficult to read” to underscore why this is important. “I find the text is difficult to read” suggests a potential UX or ADA issue (even though you aren’t in design) that the designer should be explicitly informed of during design hand-off. It could also illuminate structural shortcuts that breakdown with various solutions to the problem. For example, the first solution to readability may be to adjust text size (the tactical suggestion), but this may result in a problem where the layout breaks down because the copy is likely to take up too much space – a problem that can only be solved with character restrictions (which may not be realistic for the client) or by reworking the component altogether.
Finally, if a stakeholder can’t provide feedback in the form of a problem, help them by asking clarifying questions about the root of their feedback. For example, “Why do you feel the text should be bigger?” Duh.
6. Know whether client has capacity to manage what you’re recommending
Everyone’s excited about the ambitious “one stop shop” for INSERT NAME resources. Congratulations, you’ve got wireframes for a site that will only need a staff of ten to maintain and a million dollar budget to promote!
Make sure your wireframes are grounded in maintenance reality.
7. Actively state assumptions and agreed upon decisions
When left unstated, feedback will often come back contrary to those previous decisions and assumptions. This can cause all sorts of problems and strange battles during wireframing and many other parts of the project. Worse, if you are unclear on those assumptions and decisions, then the process can lose focus and the project veers unconsciously from the strategic objectives. For example, let’s say that a homepage is designed almost exclusively to speak to new visitors. Returning visitors are a much lower priority for the homepage because, the assumption is, that returning visitors are returning directly into deeper parts of the site (e.g., a blog post) rather than the homepage. Feedback routinely comes back wondering how the homepage will speak to a specific returning audience. Chaos ensues. Or at least some general grumpiness, confusion, and dissatisfaction that could easily be dealt with if stated up front.
Bring It Home
And if you’re looking for a little extra credit to really bring it home…
- Proactively address feedback that raises or revisits strategic decisions
- Create a parking lot for good ideas or notes that are out of scope
- Think through imperfect content scenarios – you can never expect perfect content, so be prepared for how the structure will adjust gracefully
- Know where you need to provide client with content flexibility
No problem, right? Now get out there and wow your clients on your next wireframe review!