How Do I Actually Review a Wireframe?

Wireframes are critical to the design or redesign process. Learn how to create a wireframe review process that saves time and resources and helps avoid unnecessary development costs.

Originally shared at The Good.

We get it. Wireframes are boring. Everyone wants to see bright colors, fancy fonts, and fun animations, but the harsh lines and gray boxes of wireframes are, well, unexciting.

In fact, wireframes are supposed to be boring. If you find them stimulating, your designer has probably gone too far, as UX veteran Darren Hood explains.

Nevertheless, a wireframe is a critical part of the design or redesign process. Think of it like a prototype of your site or app, stark and bare-bones but easy to manipulate and change until we have the perfect blueprint.

So, when a designer shows you a wireframe of your project, it’s important to review it carefully and provide actionable feedback that moves the project toward your goals.

Admittedly, that’s harder than it sounds, which is why we’ve put together a simple process to help our clients understand the wireframes we provide, how the wireframes serve their mission, and how to give great feedback.

What is a Wireframe?

We dive deeper into this subject in our guide on wireframe design, but here’s a quick primer.

A wireframe is an illustration of a website page or element. It’s also used for app screens. Wireframes are simple visualizations, usually without color, typography, or graphics.

Wireframes are early blueprints that designers use to conceptually “build” the site or app in order to validate user needs and business goals. This is where we establish the form and function of a site or app before worrying about the aesthetics.

We consider wireframes to be low-fidelity or mid-fidelity prototypes. A high-fidelity prototype would be a full-color mockup that depicts the site/app in its final form.

Some stakeholders like to skip the wireframing stage of the design process, but it’s absolutely critical. Reviewing and iterating on a wireframe isn’t an extra step. It can actually save time and resources before moving on to a high-fidelity prototype like a full-color mockup.

The Wireframe Review Process

Now that you have the wireframe from your design team, your job is to review it and provide feedback. In our experience, this process should involve a few other documents.

Strategy Brief

First, you’ll need the original strategy brief. This document includes the foundational information your designers need to build your website or app.

Most importantly, it should include your Minimum Experience Standards, which refer to the non-negotiable qualities that must be present in your site/app.

Here’s a blank version of the document we use at The Good.

And here is what that looks like filled out:

Design Brief

Along with your wireframe, the designer should also include a design brief on the current iteration. This document outlines what changed and why. Here’s an example of the document we use.

The “Key Changes” section documents what changed. This is important because the updates aren’t always easy to spot. The “Rationale” explains why those changes occurred. In many cases, the rationale for a change is related to your Minimum Experience Standards.

(If you’re using a collaborative design tool, this brief may not be necessary. You can simply comment on the changes with the rationale for it.)

The designer will also include questions, if any. This is often where hidden constraints pop up that no one thought about previously.

Feedback Brief

Once you’ve reviewed the strategy and design brief and explored the wireframe, your job is to provide some feedback on the current iteration. Here is the document we ask our clients to complete.

Primarily, we’re looking to learn whether the proposed wireframe is feasible (will it actually work on the client’s existing system), whether it meets our Minimum Experience Standards, and if the client has any questions about it.

You’ll notice we are not looking for feedback on visual design. That is deliberately absent from this document because it comes later in the process when we start looking at higher-fidelity mockups.

We don’t necessarily want our clients to write their responses in this document, but we find the framework helps them organize their thoughts, which we will then discuss on a call.

6 Tips for Reviewing Wireframe Designs

Now that you understand the wireframe review process let’s cover some tips to make it a positive experience for your team and the design team.

1. Reset Expectations on Wireframes

Your first step is to manage your expectations. A wireframe is not a high-fidelity mockup. It won’t look like your website or app. It won’t have pretty colors or graphics. Those elements are an important part of your brand but come later.

Furthermore, a static wireframe isn’t interactive, so you’ll have to use your imagination a bit. If an element has multiple states (like an accordion tab that expands), your designer should show both states.

Finally, keep in mind that while this step may feel like unnecessary planning, it actually saves time and money. Building your site/app is expensive and time-consuming, so it’s best to only do it once and properly, which comes from careful planning.

2. Realign Your Project Goals

The wireframe review is a good time to review your project goals: the Minimum Experience Standards. You’ll find these in the initial strategy document.

As you review the wireframe, ask yourself if each page, transition, form, and other elements serve your goals. Does the wireframe represent an experience that meets your user needs and business objectives?

3. Review Functionality and User Flow

When you review wireframes, your job is to focus on form and functionality. While color, typography, and fancy animations can affect the user experience, nothing is as impactful as the site/app’s functionality, so that’s what we settle on first.

Here are some questions to ask yourself as you explore the wireframe.

• Does the site/app have all of the necessary elements?
• Is it structured in a meaningful way for your users?
• Will it function as your users expect?
• Is there a reasonable path through the site/app (the flow)?
• Have we introduced any roadblocks that would cause friction?

Your wireframe document should indicate how pages are connected. If you don’t understand where a link or button leads, make sure to ask the design team.

4. Consider Constraints and Feasibility

It’s likely that the designer included elements or flows that you haven’t discussed yet, so some of the wireframe elements may not be feasible. Your job is to identify these constraints and educate the designer so they can provide an alternative.

For instance, suppose your wireframe includes a content block that’s meant to house a specific piece of product copy, but your content management system (CMS) doesn’t have this bit of text. This means you would have to task a copywriter to generate something for every product, but this may not be feasible if you have thousands of products.

In the case of a past client, their CMS required shoppers to choose a product size before they could choose a color. The product configurer had to be adjusted so this was obvious to users.

The challenge here is that only you – and your team – understand your constraints. The designer often doesn’t have a material understanding of your CMS, internal systems, staffing, and merchandising abilities.

Fortunately, there’s always something we can do to manage constraints, but it’s important that we know about them as early as possible.

5. Provide Constructive Feedback

Non-creatives tend to struggle with providing constructive feedback. Comments like, “It doesn’t feel right,” “There’s something wrong,” or “I just don’t like” are unhelpful. They are neither specific about the problem nor suggestive of a solution.

We don’t blame non-creatives, of course. Providing good feedback is hard, especially when you don’t have a feel for what makes creative work “good.”

Remember that at the wireframe stage, we aren’t worried about colors, typography, imagery, or specific UI elements. We focus on the form, and so should your feedback.

We need feedback on how the wireframe addresses the specific goals of the project. Review the Minimum Experience Standards that were defined earlier in the project. If the design doesn’t meet those standards, we need to know why.

What does good feedback look like? A great example is a past client that wanted to prioritize letting shoppers customize their products.

The initial design included a standard color selector, but the client felt that using the simple menu didn’t feel like customization. It felt like buying any T-shirt on Amazon. We replaced it with a large row of selectable color swatches, each labeled with its name. This educated shoppers about their color choices and made the experience more interactive.

It’s perfectly fine if you don’t have the right vocabulary to offer great feedback. We (and any designer you work with) can walk you through it as long as your comments are as descriptive and actionable as possible.

6. Identify Open Questions and Next Steps

As you review your wireframes, you’ll undoubtedly have some questions. That’s great! It’s important to pass them along to the design team for two reasons:

1. To help you gain a better understanding of the design. This improves your future feedback so we can all iterate faster.
2. To pass hidden feedback to the designer. There are often tidbits of information that the designer can glean from your questions. For instance, if you were to ask, “What kinds of products will fill this ‘People Also Bought’ section?”, it might prompt the designer to ask if your CMS is capable of such a component.

It’s also a good idea to document your own next steps. What action items will you take away from the review? This way, you and the design team are absolutely clear on what you will provide. Your next steps might include;

• Consult with a developer about the feasibility of an element.
• Instruct copywriters to provide certain bits of text.
• Identify a solution to a particular constraint.
• Verify an element is legally/regulatorily compliant.
• Get other stakeholders to sign off the wireframe.

Avoid Unnecessary Development Costs with Wireframes

We recognize that to some, wireframes are a less exciting part of the website/app design or redesign process. They don’t always feel like a real interface, so it’s hard to treat them as such.

But just like we draft blueprints before erecting skyscrapers, we must plan the form of our sites and apps before writing code. Iterating at the wireframe stage (where changes are quick and easy) saves time and resources you would spend updating a high-fidelity mockup or a live site.

At The Good, we try to make this process simple using the three briefs outlined above. We find that they help stakeholders understand the wireframes we present and focus their feedback in a way that helps us iterate on the perfect design for their needs.

If you need help designing a new digital property or redesigning an existing one, contact us right away.