The concept of uncoordination can apply not only to clumsiness but also to disorganization in information architecture. Confusing and disorderly information is widespread, but information can be structured to improve website clarity by recognizing and judiciously using patterns and components in information architecture. A pattern is a consistent and recurring feature, and components are reusable element packages or modules. Information architects can analyze and deconstruct a site design to identify its components and assemble them into a component library. Patterns and components simplify the site developer’s process and lend consistency and visual clarity for the site visitor, resulting in a better user experience. By following simple steps for identifying patterns and components across a web site, information architects can bring coordination and structure to the overall site.

information architecture
web sites
pattern recognition
information reuse
design
user experience

Bulletin, December/January 2012


Want to Improve Your Coordination? Attend to Patterns

by Thom Haller, associate editor for IA

I’m a middle-aged fellow who recently visited a massage therapist. He asked me to move my body; I apparently did it wrong, and he commented, “You sure are uncoordinated.” 

I don’t believe this arrived to me as news. I recalled that label from public school days, when those of us who were deemed “uncoordinated” were lined up against a wall and pummeled with dodge balls. Instead of reflecting on those good times, I wondered (oddly enough) how the dictionary defined uncoordination. So I looked it up. 

The thesaurus offered these synonyms: clumsy, awkward, ungainly, bungling, lumbering, inept, graceless, heavy-footed, maladroit, clodhopping, all thumbs, ungraceful and butterfingered. 

That’s uplifting, isn’t it?

And then I noticed the second group of equivalents: disorganized, confused, chaotic, disordered, muddled, jumbled, haphazard, unorganized, unsystematic and unmethodical. I read this example: “Government action has been half-hearted and uncoordinated.”

I looked at that statement and I thought “information architecture.” I’m sure I also thought “government communication,” because that’s what I often encounter as a resident of Washington, D.C. But I’m certain that colleagues in other parts of the world have also faced many examples of disorganized, confused, chaotic and disordered information and asked, “What can we do? How can we structure information to improve clarity?”

Like many of you, I’m passionate about crafting communication products that help others understand and act. I appreciate the work by writing practitioners who ask how sentence structure can support humans. I’m intrigued by the work of those of us who explore taxonomic relationships and ensure our tools bring consistency to thought. And recently I’ve become engaged by the thinking of information architects who attend to patterns and components.

Improving Coordination by Thinking in Patterns and Components
A pattern is a consistent and recurring trait or characteristic. As humans, we rely on patterns to make sense of our world. When we analyze information, we often look for patterns to identify a problem or a specific phenomenon. We often refer to patterns as indicators or models for predicting behavior.

Patterns play an important role in developing communication products. Developers refer to design patterns as general, repeatable solutions to problems. Online environments will often include design patterns, each a solution that targets a specific need. Yahoo! publishes 59 design patterns

(http://developer.yahoo.com/ypatterns/everything.html), each responding to a specific visualization need. UI Patterns identifies hundreds of patterns and provides different routes for viewing these structures (www.ui-patterns.com).

Similar to patterns are components. Like patterns, components support re-use. Unlike patterns, components are more contextual; they will relate to a specific system. If you were to identify components for your system, you would name page-level functions and relate them to specific coding and editorial specifications.

Nathan Curtis, a principal of the Washington, D.C.-area firm EightShapes, defines components in this manner:

A component consists of two or more elements that are combined to result in a structure that is standalone, reusable, design system-specific and uniquely purposeful within a page view. Such components – also known as modules, chunks, portlets, widgets, blocks or other labels, depending on the design context – are always aggregated to compose a holistic page view. Each component evolves to have an understood context and application within the design system’s page grid as well as specifications for behaviors, formats, editorial and more that’s specific to its instantiation in that system (www.nathancurtis.com/2008/02/21/pattern-library-vs-component-library-whats-the-diff/).

How Can I Envision Patterns and Components?
Nathan and his team at EightShapes help clients envision patterns and components as part of the discovery process. They will, for example, conduct workshops to help team members envision similarities (and differences) in structure. He explains it this way: 

Nothing beats the energy of getting a team together to mutually decompose an existing design system and arrive at a component library together. From information architects to visual designers, from coding technologists to site strategists, from UX leads to directors, the more you involve, the easier you gain consensus and create a baseline for adoption and practice over time. … Teams slice up screenshots with scissors, organize the multitude of variations and work on grouping, labeling, prioritizing and archiving the results. All the while, individuals work together to discuss assumptions and clarify component roles and approaches (www.nathancurtis.com/2008/03/21/creating-a-component-library-step-1-discovery/).

James Melzer (http://jamesmelzer.com/interaction-design/patterns-resources), an information architect for EightShapes (and aggregator of useful content on patterns and components), recently visited my IA/UX class and described visualization this way: “When we think in patterns and components, we typically think of rectangles or blocks. We might ask how many blocks fit into the visual space we are considering. For example, as you think about a typical web page, you may consider headers, lists, search, account information, logo, banner ads, featured content and/or recommendations as typical patterns we might see on the page. If we drew the page, we would likely create boxes for these elements.”

The advantage to the user – and to a development team – comes from consistency and visual clarity. Certainly, it improves the user experience to have a standard design system. And, if you have assembled these elements into a component library, you are one step ahead.

James suggests these steps for identifying components in your pages:

  1. Find unique page types.

    - Take screen captures of the different page types.

  2. Include stakeholders in a clipping exercise. 

    - Give everyone scissors and Sharpies and ask them to identify chunks of content that are “patterned” or repeated over and over. James says, “You end up with lots of different rectangles – you might find 60 to 100 components.”

  3. Catalog and prioritize components.

    - Organize your components into groups. Name your components. And ask yourself and team members, “What do we want to do with this?”

  4. Correlate your components with code.

Bake Coordination into Your Products
You can explore patterns and components as part of your discovery process, or you can incorporate your thinking into structured libraries. “Component libraries,” James goes on to say, “improve both user understanding and the performance of our development teams. Because the component library defines the right way to solve common problems, design teams can focus on the unique elements of each project.” He continues, “The component library becomes the forum to discuss the right way to solve new problems and the place to record each decision.” He explains how you can “bake” the personality of the organization into your products. 

It makes me wonder how well the rest of us are baking structure into our organizations. Have we taken the time to ask, “What patterns exist in our online presentation? Can we name these components and relate them to specific code provided by our developers? Can we re-introduce these components in all our products?” 

At the end of the day, you can ask, “Is my information patterned and coordinated? Or is it disorganized, confused, chaotic, disordered, muddled, jumbled, haphazard, unorganized, unsystematic and unmethodical?” You have a choice.


Thom Haller serves as the IA editor for the Bulletin and teaches principles of performance-based information architecture and user experience. In Washington, D.C., Thom teaches IA/UX classes at The Graduate School, where he launched one of the initial classes in IA (1998). A writing teacher and believer in clear writing, Thom lead the effort to reshape the plain language site in 2005. He served as director for the Center for Plain Language in 2006/2007. Thom can be reached via email at thom<at>thomhaller.com, or @thomhaller on twitter.