Newsletter of the Society for Technical Communication, San Francisco Chapter June/July 2010

May 2010 -- Information Architecture
Presented by Jennifer Fell and reviewed by Sherry Ashley

Jennifer started this presentation by passing out a number of socks at each table and challenged us to sort them in some way, limiting us to two drawers (after sorting into piles of two--then we might further organize them in various ways). This was the "Sock Test." Of course, the more we experienced the socks, the more ways we found to organize them. So we sorted. By use: dressy and sporty (function), by color: dark and light, by material (cotton or synthetic). . .even by texture or by holidays: that "once a year Christmas sock." Jennifer admitted that this might be a slightly gender-biased exercise, as some of the men prefer to have all the same color and type of socks in their drawer. One will never have trouble matching socks even if the dryer "eats" one--therefore no organizing needed. But most of the tables sorted by function first and then by color. This Sock Test relates to Jennifer's number one rule: If you haven't thought of seven options, you haven’t thought long enough.

According to Wikipedia definitions, information architecture is "the art of expressing a model or concept of information used in activities that require explicit details of complex systems." Jennifer agrees that it is an art, an art based on science, but an art nonetheless. There is no formula, it is an art based on the science of accessing information and how people learn. Wikipedia also refers to IA as "a coherent structure," which Jennifer likes very much.

Today's customers (end-users) request products that are easier to learn and easier to use, and information that is easier to find. As soon as there is more than one person on a project, someone is taking the role of information architect. Small companies can't afford a separate person to IA. So we have probably done some of this work in the past, and can benefit from learning how she does her job.

An Information Architect needs to learn about everything. They need to know the breadth and depth of all they are organizing. A lot of what they do is "triage," solving problems while nimbly learning new technology. After they learn it, they know how to organize it. A lot of their job, just like ours, is interviewing subject matter experts and users. She says that she can start to organize the materials when she understands about 70%. She emphasized the traits of flexibility, fearlessness in the face of new technology, listening to what is and is not being said. If she were an explorer, she would be at the head, sending back instructions as to how to proceed. As to deliverables, she provides high level information models, descriptions for the users, use cases for the information (not the product but how would someone access this information), specs on how to install a help system for an engineer, infrastructure that holds the navigation together--directories, among others.

On our projects we technical writers always do a lot of planning before we start: learn the product, learn what the users need, learn what the goals are, and then come up with a design. Guidelines for navigation, guidelines for linking, care in naming conventions (version numbers may need to come first in the name) may also need to be considered first.

Jennifer's Eight Lessons for an IA:

1. There is no right answer. If you haven't thought of seven options, you haven't thought long enough (think back to the sock sorting example).
2. Understand the users. You need to analyze the users and find out what their problems are. The user is the only one who really matters. No one wants to read the documentation. They don't want to read the doc, they want to know what's in the doc.
3. It's not about you. Try to help make the product better, so that less writing is necessary. Think more, write less; analysis, design, and testing are a part of what we do.
4. If users won't use it, then don't write it. At least 64% of the software features are never used and at least 64% of the documentation is never read by that same user. Maybe our writing could be more like a Quick Reference Guide with "learn more here. . ." links. Focus more on user goals and tasks, not product tasks, and always, think more, write less. If you are getting pushback for this always ask, "Tell me what to write in this instance."
5. If users can't find it, you might as well delete it. The information needs to be as close to the user task as possible. The goal is writing so the users aren't even aware that they are using "documentation." Be aware of the paths the user will use to obtain information. Studies have shown that we oftentimes remember the path rather than the destination.
6. Not all users are alike. They want different things at different times. Use metadata tagging, search tagging, filtering, related links, inline tips and tricks. Study eCommerce and eNews to make user-customizable features and information.
7. Share. Communication is not only important with the business stakeholders, the writers, and developers, but you should share with customers; find out what they think. Get feedback, even if it hurts.
8. Eyes front. (or Be Brave) You are responsible for bringing new ideas into your team. Innovation and change doesn't always make you popular within your team. Try to be popular with the users. We shouldn't be writing what people already know how to do. Stating the obvious undercuts the relationship between the writer/designer and the customer.

To sum up: IA is a collaborative endeavor.

We had a good time. Jennifer's presentation had humor and lots of things to think about. Also, there were plenty of resources on her handout.

| Newsletter Front Page | Newsletter Home | SF Chapter Contacts | SF Chapter Home Page | STC Home Page |