paper & pencil

6 Ways to Fix a Confused Information Architecture

In his latest column, Jakob Nielsen writes on the 6 Ways to Fix a Confused Information Architecture. Using the example from a recent usability tests where users confused two sections of content the 6 possible solutions include:

1. Merge the two sections
2. Rename the two existing sections
3. Explain the two choices
4. Restructure the site
5. Add cross-reference links

As always, it depends on the context — your users, your content, etc. — and each has its own set of pros and cons. Choosing the best solution or combination of solutions is best determined through additional testing.

Design To Effect Change

Business Week takes A Look at Mau's Massive Change — Bruce Mau's exhibit which opened this month at the Museum of Contemporary Art in Chicago.

The show presents design as a method of creative problem-solving that can be applied to large social problems such as hunger, housing shortages, or energy for the Third World. "We have to liberate design from fixating on the visual," says Mau. "Instead we wanted to think about design as the capacity to effect change."

Real Wireframes Get Real Results

Stephen Turbek writes on the need to make wireframes more "real" in the B&A article: Real Wireframes Get Real Results.

Real people don’t understand wireframes
Usability tests are done to get early feedback on content and functionality decisions from people outside the project team. These participants, unfortunately, are not sure how to respond to a wireframe. It is not intuitively clear what they should be doing, which site they are looking at (public site, intranet, client site)—it may not even be clear that they are looking at a web page. This lack of information and context adds a bit of cognitive friction to each step in the process. This level of confusion results in less confident answers and fewer opinions.

The comments that follow the article are more useful in that it provides a good set of pros and cons for testing with low-fi and high-fi wireframes and prototypes. For example, with a high-fi prototype testers may expect the functionality of the prototype to work but on the other hand users don't have as much context available to them when testing with low-fi wireframes. All seem to agree that you need to manage the test participant's expectations and provide context. Use of real text and making links and buttons looks clickable is a must for all types of wireframes and prototypes.