Newsletter of the Society for Technical Communication, San Francisco Chapter
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:
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.