Getting IA Done, Part II

In: Columns > Information Architecture for the People

By Joshua Kaufman

Published on August 22, 2005

Back in June, I presented my best advice in Getting IA Done, Part I. At the end of the article, I asked Digital Web Magazine readers to send me their favorite tips to publish in Part II. I’ve included most of the submissions in this column. A big thanks goes out to everyone who sent me ideas—you make this column Information Architecture for the People.

Tip #1: Keep Your Eyes on the Content

As information architects (IAs), we sometimes get carried away with the visual design of sites and forget about one of the most important components of our work—content. Neil Turner from London has this great bit of advice on the importance of content:

Concentrate on the content, and don’t get carried away with the presentation. This is applicable to both documents and diagrams (wireframes, site maps, personas, etc.). In my eyes, a good looking document that has poor content is worth much less than a not-so-good looking document that has good content. It seems to me that too many consultants spend an inordinate amount of time making a document look great but not enough time thinking about what actually needs to go in that document.

A good example is a lavishly produced usability testing highlights video. While this might look great, quite often it only ever gets viewed once by the client and is arguably less useful than a well-put-together executive summary of the testing findings. Put simply, you can modify a supermini all you want, but at the end of the day, it’ll never be a sports car.

Tip #2: Think, Design, Draw

Sometimes we can’t wait to start designing and our excitement gets the best of us. I know I’m guilty of it. I open up Visio, begin sketching and realize I haven’t thought the concept through. Donna Maurer of Murrumbateman, Australia says think first:

If I find myself sitting, staring at the computer screen wondering what I’m meant to do next, it is usually because I am trying to draw or create something without having done the prerequisite work. If this happens to you, go away from the computer, and follow these steps:

Think. Work through the issue or problem. Make notes, mind maps or whatever helps you to think about what you are doing. Don’t stop until you have considered as many issues as you need.

Design. Sketch approaches and alternatives on paper or a whiteboard. Think about what your work will be used for, and make sure your design communicates what it needs. Look at your sketches as a whole, not as discrete elements.

Draw. Don’t touch your drawing package until you are sure you know what you are drawing. Drawing should be a minor part of the process if you have done your thinking first.

Tip #3: We Heart Site Maps

Ah, yes, who can forget our old friend, the site map? Jonathan Baker-Bates from London shares a few words of advice on the labeling and construction of site maps:

When you start a site map, even as a paper sketch, take that opportunity to immediately start putting ID numbers on pages. Don’t wait until later. Having the IDs then gives you a baseline vocabulary to use in any subsequent docs, and you’re free to decide on “friendly” names later. It can help you avoid a lot of confusion later.

Also, don’t let site maps get too complicated. There are usually better ways of expressing structure over and above a general indication of content groupings. I’ve seen far too many IAs go up their own arses with—and spend far too long maintaining—site maps that nobody can understand.

Tip #4: Don’t Reinvent the Wheel

It’s a natural creative desire to want to be original and start from scratch. But most of the time, there are hundreds of designs very similar to the one we’re shooting for. Kevin Cheng of San Francisco reminds us not to forget to use the competition:

Designers have long used the competition as inspiration. But sometimes even the more detailed work of IAs, such as determining nomenclature, can utilize the same trick. For example, I’ve been in situations where I just know a group belongs together, but I’m having trouble pinning down the exact label that best communicates the grouping.

Look at the competition. List all the terms the competition uses that are describing similar buckets of content and decide which you like or don’t like and (most importantly) why. Based on that knowledge, it becomes much easier to find a suitable label—or at least know what labels don’t work.

Tip #5: Stay Objective

Content inventories are difficult to make exciting, but we can make them more useful. Thomas Vander Wal of Bethesda, Maryland explains how content objects can help ease the pain of transitioning content inventories to new sites.

The one tip I wish I had known years ago was when doing a content inventory is to capture the content objects used on the page. If you are doing a content inventory in a spreadsheet or database, include columns for the content object types and check them off as you add new pages.

What are content objects?

• Logo/branding
• Local navigation
• Global navigation
• Large advertisement
• Small advertisement
• Text advertisement
• Large header
• Footer
• Related links
• Featured links
• Images
• Captions
• Headers (various levels)
• Paragraphs
• Ordered lists (how many levels deep)
• Unordered lists (how many levels deep)
• Formulas
• Simple data tables
• Complex data tables
• Event dates
• Email addresses
• Multimedia objects

This will help greatly when you are building pages in wireframes and you want to know everything that should be templated. When you are either building the markup for the template and CSS or building component pages in a CMS, you will already know the content objects that need to be addressed for each page type. This makes the creation or conversion phase go very smoothly.

Tip #6: From Concept to XHTML

Thomas was the only reader to submit two tips. They’re both worthy of being shared so I’m including both. His second tip encourages XHTML/CSS wireframes:

Learn to do wireframes in XHTML and CSS. You will save time for those that follow you in the workflow. You will also get regularly brought into later stages of the development that you, as an IA, were left out of in the past. The developers will give respect as you are helping them directly and they will help you. But the primary reason is it involves the IA directly in the design and development workflow rather than offering deliverables that must be reworked by somebody else.

Keep Ideas Coming

What are the IA topics that you want to know more about? Is there an emerging IA pattern that you want to read about? What aspect of our work needs more critical attention? This is your column so please submit your thoughts via the IA for the People contact form.

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Information Architecture, User-Centered Design (UCD)