louisrosenfeld.com logotype

Home > Bloug Archive

Dec 16, 2001: Selecting IA Components

Here's a longish post that starts with a statement from the Department of Dangerous Oversimplification: information architecture is basically a two-part exercise.

  1. First choose the most useful tools and techniques (e.g., card sorting, contextual inquiry) to learn about users' information needs, the characteristics of content, and organizational context and constraints.
  2. With that knowledge in hand, design an information architecture using the subset of all possible architectural components (e.g., site index, search engine) that will provide high value to users while minimizing development and maintenance costs.

Let's focus on step #2 here; once we do know something about our site's users, content, and context, how exactly do we make our component choices? I've struggled with this issue for years, alternating between trying to prod my unscientific mind into a systems approach, and, after throwing my hands up in disgust, just selecting the components that "felt right".

My current belief lies, not surprisingly, somewhere in the middle: it's good to utilize some systematic guidelines when choosing components for a site. Just don't get too hung up and forget to trust your instincts.

What would such guidelines be? Well, they really wouldn't be guidelines so much as attributes that one should consider when making a selection. What are the attributes of information architecture components? Funny you should ask; here is a start at an attribute list, grouped in my favorite way:

USER-RELATED ATTRIBUTES
  • Appeal: Is this component intended to help everyone, or just a narrow subset of your site's users? Example: while you might guess that everyone would use your site's search engine, perhaps only a few would take advantage of its Boolean search capabilities.
  • Information-Seeking Behavior: Will the component support the finding mode(s) that users are likely to prefer (searching, browsing, asking), as well as integration and iteration between them? Example: After a user searches a site, he may want to be able to search against "search zones" or subsets of that site.
  • Information Need: Will the component help users find the kind of results that match their needs (known-item, open-ended, or exhaustive)? Example: site indices are that helpful for users who know exactly what item they're looking for; site maps aren't.
CONTENT-RELATED ATTRIBUTES
  • Structure: Will the component take advantage of your content's structure (or lack thereof)? Example: some search engines recognize XML markup; some don't.
  • Granularity, Specificity, and Volume: Is the component good at providing access to little nuggets of content, whole pages, or entire sites? Example: a 15-term controlled vocabulary can describe your intranet's 200 sub-sites, but won't scale to cover your intranet's 1,000,000 pages.
  • Interactivity: Will the component support the right type of user interaction? Example: a linear, sequential wizard might be a better approach to helping a user buy a plane ticket than would a single, very long page.
  • Dynamism: Can the component keep up with quickly morphing content? Example: manually-developed components, like classification schemes, aren't so good at keeping up with a live newsfeed, while search engines and auto-classification systems can be.
  • Focus: Do we need a component to provide access to all of the site's content, or just a subset? Example: site maps and site indices typically provide views of all content, while site guides and wizards focus in on a narrower subset of the content.
CONTEXT-RELATED ATTRIBUTES
  • Distributability: Can the component function in a decentralized environment? Example: it may be impossible to get all your VPs to agree on what goes on the site's main page, while it may be easy to get their consensus on what options should be included in the site-wide navigation system.
  • Durability: How long will this component be useful? Example: a site guide can be brief and manually coded, with the intention of throwing it away once a more complex and permanent alternative is available (i.e., "disposable information architecture").
  • Availability: Can you get your hands on this component? Example: ummm... have you ever seen the price tags for products from Verity or Autonomy?
  • Development Cost: What will building this component cost in terms of time, money, and staff? Example: a full-blown thesaurus will cost you lots more to create than a simple controlled vocabulary.
  • Maintenance Cost: How much will it cost to maintain this component over time? Example: a search system can be easy to maintain; just re-index the content from time to time. A taxonomy can be downright expensive to keep tuned to the moving targets of user needs and content scope.

OK, this is a start; what attributes are missing? And what do we do with these?

Well, I imagine a table of sorts, with one axis for IA components and another for IA component attributes. And communal wisdom filling up each cell. Maybe I'll draw it in a future Bloug entry, but it's late and I'm getting a little tired right now.

But if you're interested in hashing out such a table, definitely let me know. Heck, if it ends up having any value, we might include in the next edition of the polar bear book along with an acknowledgement of your helpful brilliance.

email this entry

Comment: victor (Dec 17, 2001)

I've been thinking of something similar recently. Once you have this list of attributes, you can give each attribute a 'value' for a specific site. This list of attributes and values becomes the Information Architecture Language for that site.

To make an analogy, traditional architecture has a language to express design, like 'neo-classical', 'arch', and 'column'. The attribute is 'roof support' and the value is 'column'. Wouldn't it be nice to have a language for IA? I think your list is a good start.

I'm also inpspired by John Rheinfrank and Shelley Evenson's ideas of Design Languages (not to be confused with pattern languages) as captured in their article in Bringing Design to Software:
http://hci.stanford.edu/bds/

To create such a language (and to complete a project using your attributes) we'd have to get down to a more granular level, the stuff you mention in #2. But by wrapping it in these attributes you avoid that nasty two step process.

In my list, under 'user-related', I'd add conceptual model, because I think the IA goes a long way toward forming that. Here's another article from BDS:
http://hci.stanford.edu/bds/2-liddle.html

Comment: John Paul Fullerton (Dec 17, 2001)

Here's a view of the components and attributes.

http://www.rtis.com/nat/user/jfullerton/work/components.htm

While writing the table and thinking of the concepts, it seemed to me that a value for attribute per component is what gets written for each component/attibute location. Now, using the Information-Seeking Behavior attribute and the Guide Component (as an example), I guess that what gets written for component/attribute is how a site guide is used, maybe, browsing. It seems like it may be easier to fill out a table when browsing itself is an attribute (instead of having to think of browsing as an info-seeking behavior). Maybe instead the options could be listed with the attributes, for example, Information-Seeking Behavior (searching, browsing, asking).

How do component attributes relate to audience attributes or use attributes?

Another thought was that all of the components have to do with site navigation. Even the vocabularies have to do with search or list options so that users can find the information so noted.

That brought to mind that thinking about design or IA doesn't seem to be mainly about navigation (in my limited experience). It has to do with understanding the content and the field of the content, then how users will understand (or how to make the content more understandable). The methods of access actually contain a kind of recommended thought approach; for example, don't think of these 5,000 documents as Engineering and those 3,000 as Sales, think of them as Standards, Vendors, Strategies, Customers, Sales Trends, Products, and Invoices (for example).

Comment: John Paul Fullerton (Dec 17, 2001)

Maybe it's easier to have use attributes (instead of component attributes) leading to components. For example, Browsing (use attribute) has Index (component) checked.

Comment: Edward Vielmetti (Dec 18, 2001)

Lou -

These attributes you describe sound also quite appropriate to
any complex document that is intended for an audience that will
read it on paper. I'll try to map back to a printed book
context to see how things sound.


Appeal: Is it a thriller novel, an academic tome, or a best
selling work on information archtecture? Thrillers don't have
detailed indexes in the back, but they do have catchy covers;
academic tomes better have a complete bibliography; and best
selling works on information architecture have someone like Lou
running a blog along-side the printed book.

Information-seeking behavior: Is it a page-turner, or does the
reader dip in for a chapter here and there, or is it even a
massive hyperlinked corpus (encyclopedia, Alexander's _A Pattern
Language_). Some sense of the reader's expected experience
through the document will help.

Information need: what problem is the reader trying to solve?
Will they go back to the book time and time and time again, or
is it a one-time read? Will any pages get dog-eared or
bookmarked? Who else in their acquaintance will be told about
the work, and will they reference the whole work or just a few
pages or select quotations?

(More along this line is possible, had to stop there.)

Ed

Comment: Andrew (Dec 18, 2001)

I'm a little confused: it seemed to me that the original post was trying to find a scheme that would help evaluate where an IAs attention and time would be best spent during a large project. Everyone here seems to have taken this list of attributes as a way of evaluating an information architecture's quality, which is something totally different.

For example, if I really think my site needs a full text Verity search, which would support a high value for Information-Seeking Behavior and Information Need, but that has a low Distributability and low Availability, well, then that component probably isn't worth fighting for. Same with the printed book example: this Grisham novel is a one-time-read, so no sense in trying to increase its Appeal with that leather binding.

I agree with Victor completely that at some point we need the IA equivalent of "arch" and "collumn", but those things clearly have to be structural components themselves, not attributes of strucures, like Dynamism.

I don't think that, say, assigning a value of "High" to the Interactivity of Amazon's Page You Made component tells me much about that site's real structure, although knowing that Amazon integrates several forms of click-stream analysis into its information architecture does.

Comment: andrew (Dec 18, 2001)

(How do I add italics and bold text to posts around here?)

Comment: Liz (Dec 18, 2001)

I agree with Victorís addition of 'conceptual model,' and would add yet another attribute under User-Related Activities. Perhaps it is a subset of Information-Seeking Behavior or Information Need:

Information Access: What are the organization's goals for allowing users to access information and how does the component support this? How does the component justify differences between the usersí information needs and the organization's goals? Example: Content sites that switch to a subscription-based model for in-depth content.

Iím also very interested in what we do with these attributes once they have been explored. Is it a further set of questions that we might ask about each attribute? Under the Information Need Attribute, for example, we could think about something like:

Labeling and Nomenclature: What is a user's a priori knowledge of the content? Do the contextual cues allow users to understand how the site matches their goals? Are the labels clear and informative? Example: Rollover navigation that allows users to view further explanation in addition to the navigation labels.

Add a Comment:

Name

Email

URL (optional, but must include http://)

Required: Name, email, and comment.
Want to mention a linked URL? Include http:// before the address.
Want to include bold or italics? Sorry; just use *asterisks* instead.

DAYENU ); } else { // so comments are closed on this entry... print(<<< I_SAID_DAYENU
Comments are now closed for this entry.

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.

I_SAID_DAYENU ); } ?>