With projects that include deep layers of information (such as websites, exhibitions, complex publications, or other information-dense projects), you’ll be doing your visual design team a huge disservice if there is no overall map of the project from a structural point of view. Working on a complex project without a big-picture overview is enough to make even the most patient designers run screaming.

A sitemap or similar flowchart outlining all project components is one of the first documents you may need, and it should be created long before visual design begins.

Basically the sitemap (or a similar overview map if you’re working on something other than a website) should give a visual outline of all the components and informational elements of the project. It’s a high-level, organized laundry list of everything that should be included in the project. Sitemaps are foundational tools of information architecture, related to the master planning documents that architects have traditionally used when designing extremely complex building projects such as hospitals or university campuses.

Sitemaps and similar flowchart overview documents can come in all shapes and sizes. You can create a simple index/listing in a word processing program. You can create a sitemap from index cards displayed on a board. You can sketch one on a napkin. You can draw it using an illustration program or using an interactive flowchart app. Sitemaps can be simple black and white, or full color and animated. Your project content and the needs of your team should guide you.

Like many maps and diagrams, a good sitemap needs to have a key that explains the meaning of each element. The final, approved site map needs to guide the team on how to prepare and track all content elements throughout the life of the project. This chapter provides samples of some typical and not-so-typical sitemaps to give you an idea of how you might apply this type of document to your project.

While the sitemap or structural overview provides a bird’s-eye view, wireframes flesh out the finer details of a complex information design project. They help answer questions: How much content will we need to consider as we create the design? What kinds of specific information do we need to design around? Do we need headers and subheaders for the content? How much main text is there? Are there pieces of related content that live alongside the main content but in a separate area of the layout? What other types of information does the design need to accommodate, and how should we display that information? Will we need lists? Diagrams? Charts? Illustrations? Few, if any, of these issues can be planned properly on a structural overview diagram like a sitemap. There’s simply not enough detail in that kind of overview document. Wireframe sketches allow you to envision all these details.

“Information is the beginning of meaning. Information is data put into context, with thought given to its organization and presentation.” —Nathan Shedroff

A wireframe is, in a sense, a sketch that allows the design team and client to see a detailed view of how the content will be organized on just a few given pages or sections of your project. For websites, you might choose a series of representative site pages (often called page types) for your set of wireframe sketches. For instance, for a website, you might start with the home page and a few drill-down pages. Book or magazine content sketches might show rough templates for how the typical feature or department content will be organized into headers, introduction text, body text, and sidebars.

Without wireframes, you can spend a lot of time and budget creating highly detailed design deliverables only to find that not all of the project parameters have been thought through. If you’re designing a website home page based on three spotlight areas for content, and suddenly the client wants five spotlights, it’s much easier to revise and update a simple wireframe sketch than to rework a fully realized layout.

Wireframes help ensure your design planning is thorough and deliberate. By the time your team is ready to begin visual design, you’ll have thought of most, if not all, of the issues related to the organization and display of the information you need to include in your project.

Wireframe documents tend to look like their moniker: plain, wirelike drawings with basic text labels. Nothing too fancy. Nevertheless, there are no hard-and-fast rules for creating wireframes. You can draw them using a variety of tools and methods, depending on project content and goals. The main goal is to catalog all the information in layout form but without spending time and thought applying any specific visual design elements.

Wireframes don’t have to be ugly (why should anything you create be ugly?), but it doesn’t make sense to spend an inordinate amount of time making them beautiful. For one thing, people might wrongly assume your gorgeously nuanced wireframes are reflective of the final look and feel for the piece. Wireframes should be sketches that are clear, thorough, and free from extraneous graphic elements and details.

Some information designers use color in their wireframes sketches. If you use color, limit your palette to one or two colors that you use to emphasize certain information. By primarily sticking to black and white or grayscale, you won’t run the risk of confusing your clients into thinking they’re looking at visual design deliverables. And you won’t be inadvertently starting or pre-empting the visual design process before that phase has begun.

Most of the time, wireframes will look absolutely nothing like the final design. And, ideally, during the next phase of the project when you present the visual design options, you will have diverse visual solutions that look radically different from each other, all based on the same set of wireframes.

Make It Just Real Enough. Wireframes should look enough like the final piece so a layperson can understand, with a little explanation, what they’re looking at. As we’ve discussed, you don’t have to come close to a final design at this stage. But, for example, if you’re creating a website wireframe, you’ll want to make the document look enough like a website so that the person gets the gist. You probably want to use the same dimensions as a typical web screen and use some detailing to clarify navigational elements. If you’re creating wireframes for signage, it helps to give the diagram a few recognizable visual cues, like a signpost or sign frame, to help viewers instantly understand that the sketch represents a sign.

Wireframes give you a way to map out the piece in advance and to reach team consensus regarding the form and content of your final design. The wireframe stage of a complex information design project can go through many, many iterations. Once you have team and client approval, the design team will then use the wireframe sketches as a detailed reference guide as they begin to address the visual design.

Continued Research with Wireframes. It’s a good idea to test key elements of your information design at the wireframe sketch stage with target audience members. Even before you’ve spent time and effort on the detailed visual aspects of the design, you can test your thinking. The client and design team may be making assumptions that you can avoid if you ask end users for their feedback at this stage in the process.

By showing the wireframe sketches, you can ask users if they understand how the information in your project is categorized, organized, and named. You can find out if you’ve inadvertently made choices that cause confusion for users. Wireframes can allow you to find out quite a bit about how audiences will react to the information design piece even before you and your team have spent the time and budget on look and feel.

Isn’t testing expensive and time consuming? These are two assumptions clients—and designers themselves—often make when deciding not to test. Sometimes a design team falls into the trap of thinking they’ll convince the client to test after the project is well underway (or at the very end of the project, when many design decisions have already been made). At that point, however, introducing a testing phase will probably be seen as an unnecessary expense. The client has invested a lot of time and money in you as a design expert. So why not rely on your expertise? Everyone on the team has invested a great deal of time and energy in the current design solution. Testing for the very first time so late in the game seems like a chore. Worse yet, what if all that creativity and energy have been focused in the wrong direction? If there are problems, sometimes we just don’t want to know.

Testing—especially informal testing—needn’t have a huge impact on your overall timeframe for the project, if you build iterative testing into your process. You can (and should) also conduct more formal user testing at the end of the project, but by that time you’ll be testing a design that has already been through a process of refinement based on real user feedback.

Testing Saves Money. The value proposition of testing is that if you do it from the beginning, the project may cost a bit more, but it will end up saving money in the long run. The likelihood of getting it right in version 1.0 of your project will go up exponentially when you do research testing.

“Information is only useful if it can be understood.”
—Muriel Cooper, Information Designer

Human-centered design is a problem-solving process grounded in empathy and iteration. Anything can be prototyped—from programs and services, to spaces and events, from print communications to digital tools and products. By mimicking what the final product will be like to use, prototypes are the best way to gather evidence instead of opinions. Greater Good Studio

Testing Isn’t Make-Work. The best approach is to stop thinking of testing as an extra option, and present it as a necessary, integrated part of the process, one that will help you and the client ensure that the project is successful for the client’s audience.

Testing and Politics. “Testing takes some of the politics out of the decision-making process during projects,” explains Kathryn Campbell, U.S. research and consumer insights specialist. Is there something that you think isn’t a good idea, that perhaps the client insists on integrating into the project despite your protests? Don’t argue, test! Is there an innovative solution you’d like to try, something that you think will be helpful for users that perhaps goes against what has come to be considered standard practice? Don’t guess and don’t think you have to design based on the strictest rules; you can test your ideas. The results may surprise you.

Make It Standard Practice. The best approach is to build testing into your project plan from the very beginning. Clients are likely to be more receptive if you explain that testing is simply part of your regular production process.

“The world in which we live has become a cultural smorgasbord, and we all live permanently on the verge of indigestion. We have to have some help in sifting through the endless choices.” —Joe Jackson, Musician

Test Iteratively. Test early and often. Iterative testing means you don’t wait to test until you’ve spent weeks or months on the project. At project inception, find a selection of representative users and set up a regular testing schedule. Set aside a couple of hours each week for a simple, informal test. Don’t try to test everything at once. With dense information, there are often too many elements that you’re still in the process of trying to figure out. Test individual segments of your design. Test whatever is ready at the time. If you’re working on a website, test just the navigation titles one week. The next week test a set of icons. The next week you could test just the on/off states of the buttons, and so on.

Simple Paper Prototypes. Testing tools don’t have to be fancy. Especially during the early stages of the project, test with paper prototypes. You don’t need to videotape the test (although if you have the resources, you can). The most important thing is to get user feedback during the design process. Take good notes and/or perhaps record audio to catalog their responses. Have the design team spend time discussing the feedback. Then make some decisions on how the feedback will impact the next iteration of the design.

Advanced Prototypes. Once you’ve mapped out a good portion of the user experience of the information design, you can conduct more elaborate testing. If you’re testing a website, you might test an entire path leading from the home page to subpages and a particular interactive tool. Even during advanced testing with interactive prototypes, it’s best to keep things relatively simple for each user-testing scenario by testing one path or one piece of functionality at a time.

How Finished Should Your Prototypes Be? Testing a prototype that is still in a very abstract stage of design (for instance, website wireframes without any design elements) can be a real challenge for end users. “Those of us who have ended up in design careers,” says Campbell, “tend to vastly overestimate how conceptual most people are. Most people are, cognitively, fairly literal. It doesn’t mean they’re unintelligent. Think about how hard it is to convey to the client that a wireframe isn’t really design. You have to make things look like the real thing or people get confused.”

However, if you’re in the early stages of a project at a point where most design issues have not been resolved and you decide to create a prototype that looks very “finished,” you run the risk of testers, clients, and even designers confusing your testing materials with actual methodical, strategic visual design. People can get attached to the look that was quickly thrown together for the sake of a test. Plus, when something looks like it could be the final design, you run the risk of having clients and users focus and give feedback on the visual elements you’re not even testing, instead of on the information design issues for which you need feedback.

Bottom line: Make your testing prototypes look enough like the final product so it’s clear to users that it’s a website or even a subway map. Just don’t spend so much time on making the testing prototype look so complete as an artifact that users mistake it for a design that is further along in the process than it actually is.

Campbell says, “I like to have the very last prototype that I test look darn final. But that’s the very last test.”

First you’ll need to know your main audience types. (See Defining Audiences in Chapter 2 for more information about determining audience types.)

Typically your client should be able to provide you with a list of customers or appropriate users from their database. You can also get help gathering your test subjects by hiring a recruiting agency. These agencies contact potential testers, offer incentives, and even set up the test in a testing lab. Online experiences can be tested with a variety of online testing platforms. (See Online Testing Tools.)

“Design is the intermediary between information and understanding.” —Hans Hoffman

How Many Testers Do You Need? For the Allergan pharmaceuticals site, What’s Next Interactive tested a site on three specific user types identified as the most important in terms of site traffic: doctors, patients, and job seekers. How many users participated in the testing? Approximately six people from each user group. “Because of my background in traditional market research, I wasn’t poised to believe this,” says Campbell. “But you really only need to test your design on a few people. After about six interviews with a particular set of users, you find out about all the big issues for that user type.”

When you want to test your design but don’t have access to live testers or want a broader range of opinions, a survey may be an effective course. There are some basic tools that help you create and distribute surveys online. Or you can keep it really simple and email PDF or JPEG images of alternative designs to a wide sampling of users, asking for their preference.

On the other hand, if you want to know something specific, such as which button users will most likely push, which information they see as most important, or whether they understand a set of icons, it’s probably best to test one on one with a smaller sampling of representative users.

“You can only understand something new relative to something you already understand, whether visually, verbally, or numerically.” —Richard Saul Wurman

Dozens of online platforms now allow teams to conduct real-time user testing. Panels of real users, sorted by type, can quickly provide detailed behavioral insights.

“Testing takes some of the politics out of the decison-making process during projects.” —Kathyrn Campbell

For instance, with A/B/n testing, multiple versions of a webpage can be compared to see how consumers respond. In addition to websites, these tools can be used to test and validate mobile apps and email marketing.

Design teams can run “click testing” with wireframes early in the process. Later teams can run split tests with the finished design to test minute variations. Detailed feedback allows teams to evaluate information architecture, user interface, messages, and design choices at every stage of the process, with test results carefully segmented by audience type.

This highly respected U.S.-based environmental organization regularly tests the way it communicates online. In addition to testing its overall messaging, it tests the way it engages donors.

The variation on the bottom right increased donations by 400 percent over two years, using graphic clues and enhanced messaging to highlight the call to action.