Three Things to Ask When Reviewing Wireframes

If you’re asked to review a set of wireframes by your technology team in preparation for a website redesign, unless you’re provided with proper guidance you may be left feeling a bit confused or underwhelmed. You’ll immediately notice a few things:

• The wireframes look like a website but everything is black, white and gray.

• The typography in the wireframes is Arial font and nothing else.

• There are a lot of gray boxes.

Welcome to the world of wireframes.

Below is some basic background on what the intention of a wireframe deliverable is and also a list of of three must-ask questions when reviewing a set of wireframes.

Why Create Wireframes?

The focus of a wireframe is to convey the overall layout and functionality of a web page. What does that mean exactly? We'll get into this with some visual examples. 

Your technology partner will most likely present to you one of two types of wireframes. The first type is the static wireframe. It could be delivered to you in the form of a jpeg, a PDF, a sketch on a napkin. It’s a visual representation of the layout of a web page.

Wireframe Layout

Some layout decisions that could be illustrated in the wireframe include placement of the website brand logo or name (upper left corner of the header) and the placement of a sidebar (left side of the page). Some other features could include a main menu bar and a section that's dedicated to displaying 'recent news'. The wireframe described above would basically be a picture of a website's 'news' landing page and generally how content will be organized within it.

Functional Wireframes

The second type of wireframe is the functional wireframe. A functional wireframe will be delivered to you as a web link that you can click on and open up in a browser. For all intents and purposes, it will look and behave just like a website. It will have links in the page that will allow you to navigate from page to page, it will have interactive features such as a slideshow that auto rotates and a main menu bar with dropdown items that activate on click or hover.

This type of wireframe is also a visual representation of a webpage just like the static wireframe but the benefit of a functional wireframe is that you can interact with it and you can see it within the context of a browser. This will allow you to have conversations with your technology partner in greater detail about the behavior of your website. You can for instance in the wireframing phase, fine tune the speed of the slideshow rotation and review how the website layout responds to various screen sizes if it's a responsively designed website.

An important note about wireframes: Your technology team will purposely refrain from adding any design elements onto the page including color choices and font style. Wireframes are most often a precursor to developing pixel perfect graphical designs that are directly based on the approved wireframes. You can think of wireframes as blueprints for a building, or a pencil sketch that precedes an oil painting. Keep in mind that design elements such as the background color of the image captions or button colors are best reserved for the design phase of the project. 

What Should I Look For in a Wireframe?

One of the many tasks of a functional wireframe deliverable is to bring behavior and layout specifics out of the realm of assumption and make them explicit. 

Here are three questions to guide you when reviewing wireframes for your future website.

1. Why don’t I see that cool feature on this page that I assumed would be here?

It’s difficult to mock up absolutely every detail in a wireframe (while staying on budget and on schedule). Here are the things that should absolutely be reflected in a wireframe: Layout decisions and key functionality. For example, let’s say you ask for an auto-rotating slider on the homepage under the main menu. The wireframe should reflect this feature on the homepage wireframe and should have it placed under the main menu as you specified.

Behavior should be captured in a functional wireframe, for instance - auto rotation of a slideshow and manual rotation options triggered by clicking on right or left arrow icons. Should something happen if you click on the image that’s featured in the slider? Does it take you to another page? Is there a pop up that’s activated to ask you a question before it takes you to another page? All of these behaviors should be indicated here if they are requirements for the website. If you don’t see a specific behavior or action that you feel is absolutely needed, it’s time to speak up.

Tip: If you’ve noticed an example on another website of a particular feature that you'd like to have, it’s a great idea to send your technology team a link during the requirements gathering phase. 

2. Why is that all-important page that we discussed not in the set of wireframes?

Wireframes serve two purposes: 1) Defining a unique layout. 2) Defining key functionality. A page that’s central to the website but also has the same layout and functionality of another page, may not get its own wireframe. However, a wireframe that’s meant to represent all pages that share the same layout and functionality should exist.

For user experience purposes, it’s a good thing to keep unique layouts to a minimum. Only creating unique layouts where it’s an absolute necessity is important - it cuts back on the learning curve that’s imposed upon your users as they navigate around your site. Good user experience works with your website visitor’s intuition about where to find information and how features behave based on their previous experiences browsing the internet. If users find it easy and effortless to find what they need or discover something of interest by recognizing familiar design patterns, the more satisfied they will feel. 

3. Why don’t I see our actual content mocked up in the wireframe?

The answer to this question is - you should absolutely see your actual content that you intend to use on the website in the wireframes. In fact, the best thing you can do for your project is to provide your technology team with your site’s actual content as early as possible, starting with the wireframing phase. The better your technology team is equipped with information about your content and have access to example assets, the less chance there will be for surprises later. Example below:

Let’s say the wireframes assume square images at 800px throughout the site, but you only have images that are horizontally oriented and 200px in width. Will you have time to schedule a photoshoot before the site launch to get the needed images at the right ratio to upload to the site? These content issues should be addressed as early as possible.

Another example involves assumptions made around quantity of content. Let’s say you have an ecommerce website. A wireframe of a product page featuring a t-shirt has a right sidebar showing related products like hats. The wireframe shows three related hats in the right sidebar on the t-shirt product page. If the actual content dictates that there are 15 hats associated with each t-shirt, this could change the quality of the page layout once this page goes live. The all-important information underneath the list of hats, such as the ‘purchase’ button, could be pushed way down on the page where it’s buried and never seen. This simple oversight could potentially have an impact on your business.

Here’s a list of more handy questions to think about and ask during the wireframing process:

1. Will this item appear on every page or just this page? 

2. Is this thumbnail image dynamically or manually cropped?

3. Are the boxes in this row always going to be the same size?

4. How do I change this text?

5. How does this all look on a mobile device?

6. What if I don’t have content for this section on some of the pages?

7. How do I get back to that other page from here? 

8. How will this image look on a large display (1200px and up)?

9. Will the user see a status message to confirm their action?

10. What's the minimum and maximum number of items that can fit into this section? 

You would be surprised how helpful it is to your technology partners when you ask questions during the wireframing phase. So be sure to ask away!