Recollections of an information architecture class focusing on user experience brought out the importance of understanding context. One site overhaul project revealed internal problems rising from contrasting views of the stakeholders. The project served as a lesson about choices in site content and structure made by information architects to support end user information needs and organizational goals, rather than showcasing creative designs and personal preferences. Information architects should ask themselves how their choices differ when working with an organization that is clear about its goals for supporting knowledge, not simply presenting data without meaning or purpose.

information architecture
web content management
contextual information
task analysis
end users
user experience

Bulletin, February/March 2011


IA Column
 

Challenges with Context

by Thom Haller

I recently met with former students at the conclusion of our information architecture/user experience class. Our conversation turned to a real-life project our class had explored – supporting a Federal organization in rethinking its architecture to better support the needs of site visitors. 

The project had intrigued us. We faced a “2003, I want my site back” architecture. (The visual presentation seemed awkward and site content was tremendously siloed, creating challenges for individuals trying to accomplish tasks.) But more than that, we faced a challenge with context: the organization experienced internal conflicts about how it wanted to present itself. Some leaders valued their place in history and their work in national security. Others chose to downplay the organization’s role and remain invisible.

As we discussed the difficulties we faced developing a site architecture and good user experience in the face of these conflicts, one student commented, “Understanding context is ultra-important. It will make or break a project.” 

I agree. As someone who stepped into the business of information architecture because of my belief that we can make the complex clear, I’ve always framed context as a central element in the structural choices we make. 

Our conversation reminded me of five questions I often ask to help students think more deeply about context, focusing on how our content and structure choices differ:

  1. When are businesses motivated by the desire to “just get something up there” as opposed to the challenge of enabling people who read content to get their jobs done?
  2. When are bosses and organizations motivated by preference (“Let’s develop a cool site”) as opposed to creating an online environment that supports audiences and meets organizational mission?
  3. When do organizational goals require a “perfect” site that solves a host of problems as opposed to “progressive success”?
  4. When do organizations think of themselves as experts (“the company that wrote the book on repair parts”) as opposed to thinking of themselves as client-focused civil servants (providers of communication products that enable people to make many choices themselves)?
  5. When do our own perceptions of document design and construction come from “intuitive models” (as writers, we are gifted with the ability to present information in clever ways which will get the attention of our peers) as opposed to coming from a systematic understanding of our audience and a reliance on feedback models to better understand users?
    Following our most recent class experience, I’ll add a new contextual question:
  6. How do our content and structure choices differ when our client organization is unsure about how it wants to present itself to its audiences as opposed to those who realize that, without focus, they only present meaningless data that ultimately serves no purpose?

I challenge you to think about context in the products you build. You may be surprised by what you learn.


Thom Haller, the Bulletin’s associate editor for information architecture, is a speaker, writer, user advocate and teacher of principles of performance-based information architecture and usability. Since 1998, Thom has taught classes on architecting usable web/Intranet sites. As a teacher, Thom enables students to structure information so people can find it, use it and appreciate the experience. He can be reached at thom<at>thomhaller.com; thomhaller<at>twittercom