Using Wireframes to Communicate Information Architecture

Kathy's note: This is the eighth installment in a 12-part series by Theresa Putkey that discusses the intersection of content strategy and user-centred design. Read all posts by Theresa.
___________________________________________________________________

What are wireframes?
As mentioned in my previous Site Maps post, wireframes are akin to a blueprint for a house. For each major page on a website, a wireframe tells you which box should go where, what content should go in the box. You can easily find examples of wireframes by searching for “wireframes images.”

What are they good for?

Since an information architect (normally) has a deep understanding of how users are trying to find information, a wireframe can show others how the information should be laid out so users can best access this information. There are a number of benefits of wireframes, including:

• Showing layout: for the major pages on the site, a wireframe can act as a template for how the information, images, videos, and forms should be organized on a page. It can also show you how the global and local navigation will appear and behave on a site.
• Verifying persona needs: With your personas in hand, you can make sure the wireframes represent the most important information needs of the users. For example, a user might need to see a daily financial update announcement instead of the weather. You can ensure this update is in the appropriate wireframe.
• Fulfilling user scenarios: Scenarios represent what people are doing in “real life” and how the site helps them fulfill their “real life” needs. Wireframes can make sure all the scenarios are satisified. Although the whole scenario doesn’t need to be represented in the wireframes, you can represent the whole scenario or you can represent the more complex parts of the scenario. Ultimate, the wireframe helps you discuss the scenario and see if anything is missing in your design.
• Verifying requirements: While creating the wireframes, you can refer to the requirements list, then clarify the meaning of any requirements. In the wireframes themselves, you can note which box fulfills which requirement.

How many do you need?
With a site, you don’t need to represent every page in the site map. You only represent the major pages that are significantly different from each other. For example, you might have a content page, a home page, a secondary landing page. If you have any forms or workflows, you can represent these as well. How many you need depends on how many significantly different pages you have and any processes that need to be represented.

What are some challenges?
While wireframes do help communicate the information layout, I’ve run into several challenges with them:

• Requirements elicitation: Invariably, wireframes always generate more ideas. Instead of being a confirmation of the existing requirements, once people see things on the screen or page, they think of more ideas. This is often called “scope creep.” Often, people don’t have a clear understanding of how detailed the requirements, personas and scenarios need to be and end up fleshing out this detail in the wireframes phase. It happens in every project - I haven’t found a way to avoid it. There should be room for creativity and interpretation in wireframes, but new ideas always elicit a response!
• More abstract, less concrete: Unlike visual design, wireframes are more abstract. While I use Axure for wireframes and can make them somewhat interactive, people relate to visual design more than they do to the wireframes. Visual design not only adds colour to a design, but it also pulls the eye to certain aspects of the page, gives a better “feel” for the page, and evokes a response based on colour. People respond so much better to visual design, sorry to say. They can agree to a wireframe’s functionality, but once they see the visual design, they get excited. I like to think that the wireframe’s work allows the visual designer to make splendid design.

Conclusion
Wireframes help communicate the information layout for a site. They help the visual designer produce a great design and they speed the development process. While there are some downfalls to them, such as being more abstract and sometimes being used too heavily for requirements elicitation, they do help with agreement on site layout and design.

___________________________________________________________________

About the Author 
 
Theresa Putkey is an information architect consultant living in Vancouver, BC. With a Bachelor of Arts degree from the University of California, Davis,    she focuses on integrating user needs into website and software design projects. She's currently doing her online Masters of Library and Information Science at San Jose State University. You can find out more about Theresa at www.keypointe.ca, or follow her on twitter @tputkey. Read all posts by Theresa.