I’m therefore really excited to announce that EightShapes is holding its first public workshop on August 8. Nathan and I have been part of other programs, but have never hosted an event ourselves. This is a huge step for us, and we hope that the relatively low price-point of the session means that you can join us in this first of many events to come.

So, if you’ve been considering taking my intro documentation course, or wanted to double that up with some more heavy-duty thinking on wireframes, this is a fantastic opportunity.

I hope we see you there!

About 20 years ago, my sister and I wrote our own Haggadah, the book used during the Passover seder. The Haggadah tells the story of Passover, the liberation of the Israelites from Egypt, and provides an order (which is what “seder” means) for performing the holiday rituals. Lisa and I, fed up with the Brown family practice of skipping around to hit the important parts and keep things to a length suitable for my dad’s attention span, decided to put our own together. This may seem sacreligious but, frankly, telling the Exodus story in a meaningful and personal way is what Passover is all about.

The seder is filled with symbolism and Lisa and I sought to take advantage of that, by showing how the symbols of Passover are embedded in the story itself. At the time, though, we were teenagers and couldn’t appreciate the larger issues (oppression and liberation) and see how they might be translated to a variety of symbols.

One of the things that we left out of our Haggadah was the four children. (This was either an oversight or an artifact of our own interpretation of what was important.) The number four appears throughout the Passover seder (four questions, four cups of wine) and perhaps represents the four stages of liberation. Since Passover is all about teaching our children about the Jewish liberation, the seder includes descriptions of four types of children who might be present at the meal and the questions they might ask:

• The wise child wants to know about the meaning behind the story.
• The wicked child wants to know why he or she should care about the story.
• The simple child asks the most basic questions, but these should not be ignored or glossed-over.
• The one too young to ask needs to have the story told despite the apparent lack of interest.

I’m in the process of re-writing our Haggadah. With Harry nearly two years old, Sarah and I are trying to create traditions for our burgeoning family. In addition, twenty years after writing our first Haggadah, I see the world differently, Judiasm differently, and interpret the story and the symbols in a new way. In my initial research, I was reminded of the four children (really “four sons”). There are many interpretations of these children, and even a little research reveals great ambiguity in what they symbolize.

To the eyes of a user experience designer, though, these children are ancient personas.

Like personas I might create for a design project, they are abstract. They don’t describe specific children, and don’t even provide examples of these kinds of children. Their abstraction implies that we can’t correlate them to a specific person, but instead use the abstrations to categorize people who might be at the seder–curious, selfish, naive, and uninterested. Likewise, for a design exercise, I might identify categories like prospective customers, new customers, current customers, and preferred current customers. For each category, I can identify their desires and objectives and constraints.

But these personas are actually different from the seder’s four children. They’re no less fuzzy, but they do represent different objectives and different tasks. Imagine we’re designing an online banking application: the objectives and tasks for a new customer are mostly different from those of a current customer. The tasks and objectives define the personas.

This isn’t the case with the four children. The objective is set by the seder: teach your progeny about the liberation of the Israelites, no exceptions. What the built-in personas tell us is not that we have to support different objectives, but that we might have to employ different teaching styles to accommodate different kinds of learning.

Have you ever written personas like that?

These are personas that orbit a single objective and the ways in which people might accomplish that objective is defined in the personas. Writing it down now, it seems self-evident, but my personas have never been framed this way. Instead, typical personas identify user objectives and the product’s requirements must support those objectives. To apply this to a specific example, take online banking. What would objectives look like if not defined by the target audience but instead by the business?

• Help our customers keep a balanced checkbook.
• Help our customers track their spending.
• Help our customers see the benefits of upgrading their accounts.

If these are among the product’s core objectives, we might cast the personas as people who have different styles in their banking: the nit-picker, the worrier, the procrastinator, etc. We need to tell the same story to all these people, but we need to accomodate their individual styles.

One way to interpret the four children is that they represent different aspects of humanity. Or, to state it another way, that all four children are inside each of us. Every person brings unique approaches, hang-ups, and perspectives to the same story. Shouldn’t we be thinking about our product’s target audience in the same way?

Without seeking to open old wounds, I should define information architecture. As information architects, we design structures, meaningful relationships between objects. A site’s interface design exposes these relationships, adding further layers of meaning. But the role of the IA is to define the objects addressed by a site and how those objects relate to each other.

In recent months I’ve had the opportunity to work on content-heavy sites–sites whose primary business is to present content from a variety of sources for specialized audiences. These experiences have given me an opportunity to reflect on what I do and how I do it. To support sites like these (which are hardly extinct or endangered as early Web 2.0 proponents would have us believe) IAs need to build four specific types of structures.

Content Types

A content type is hardly a new concept. Content management systems have been relying on them for years. In short, a content type is the collection of fields that define a piece of content on the site. The “structure,” therefore, is the relationships between these fields. You might define “article,” for example, as having three fields–title, author, and body.

Content types, despite the industry’s best efforts, are not a one-size-fits-all affair. Different projects require looking at content differently, and the information architect must be sensitive to how content will be authored, managed, and consumed. The art of information architecture happens when IAs think about creating a meaningful set of content types that neither require too much management, nor gloss over the important distinctions between different kinds of information. Content types that are too specific are difficult to manage because it can be tough for authors to determine which one to use. Those that are too general don’t have enough structure to be managed or consumed easily.

One benefit to thinking in terms of content types is that it positions information assets as objects of particular classes. Since most programming these days is “object-oriented”, thinking about content as objects can help build a bridge between user experience and development. In addition, modern web experiences leverage well-defined content objects as the focal points for community and participation. An emerging concept (at least for experience designers) is “social object,” the thing that unites people in conversation, connection, and community.

Templates

After defining the structure of the content, I usually think about what kinds of templates the site must support to display the content. For each content type I look at how an instance of the content will be represented in a variety of scenarios. There are two kinds of scenarios: one where the content type has a dedicated template and one where the content type is represented partially as an element of another content type.

For example, on an online magazine for professional musicians, I might have three content types–article, manufacturer, instrument. Manufacturers make certain kinds of instruments. Articles may refer to manufacturers or instruments. As an IA, I need to answer the question: To what extent do each of these content types need representation online? Obviously, I need a template dedicated to articles. I might also have a page for each luthier, and those pages might have references to articles mentioning that manufacturer. Therefore, an article has at least two representations on the site–as a page in and of itself and as a link from a manufacturer’s page. (At EightShapes, we refer to these roughly as views and components, respectively.)

There are lots of nuances to template design. You might, for example, develop views and components that support more than one content type, where the structure is the same regardless of the kind of information behind it. Alternatively, a content type may have multiple views (screens or pages) depending on the scenario or person looking at it. A common distinction, for example, is between a detailed view and a summary view. Some templates are not associated with any particular content type. A search results page, for example, will likely support a variety of content types.

For information architects, designing templates is where we come dangerously close to stepping on the toes of interaction/interface/visual designers. Generating a set of wireframes can be problematic when the overall visual approach to the site has not yet been ironed out, or when you’ve got people on the team who are more qualified to do that. Still, wireframes are the best way to represent (a) what goes on the page and (b) how those elements should be prioritized relative to each other. Each IA has his or her own way of navigating team dynamics.

Wayfinding and Navigation

With the content types and templates defined, I generally turn my attention to navigation. No matter how much the web has evolved, this question won’t go away: how to people get from one piece of information to another? It’s gotten more difficult to answer, too.

While navigation may seem like an antiquated concept in the age of search, pages still have links, and content-rich sites need some structure to help readers with wayfinding. Modern navigation, however, differs from original static sites in several ways.

First, sites generally have multiple navigation schemes. When presenting navigation for a new site to a client, I’m careful to say that sites don’t have just one architecture, one structure within which content sits. Instead, sites have multiple, often interlocking structures that are more dynamic than the simple hierarchies we created in decades past.

Next, at least one of the navigation schemes addresses contextual wayfinding. Recognizing that the home page of a content-rich site is rarely the primary entry point, information architects must create navigation structures on interior pages that paint a broad picture of the site without distracting from the reader’s starting point, which may be several layers inside the site. Again, IAs must walk a fine line between showing the range of content available on the site and keeping the available links meaningful.

Finally, navigation schemes look less like org charts and more like business plans. They aren’t prescriptive in terms of what labels or links appear in the navigation, but instead define a specific strategy for the kinds of links that should be included and why. Navigation, out of necessity, grows and changes over time and an organization must have a guide for putting links in the site’s scheme. Each scheme must have a purpose, criteria for including links, a prioritization relative to the other navigation schemes, hierarchical details (where does each link go?) and functional details (how does each link behave?).

Rules and Assumptions

As information architects deal more with abstracts (content types instead of specific pieces of content, navigation strategies rather than specific links) every abstraction needs a set of rules for governing how it will appear when instantiated. In the form of a question, when the system loads content into a template, how will the system determine what content to load?

The rules establish criteria for identifying appropriate content and what happens when no content meets those criteria. A rule might take the form:

Pull the three latest articles tagged with keyword X, less than 10 days old.
If the system can’t find three articles within this timeframe, hide this element.

As these rules develop, I find that I need to capture some assumptions. The rule above, for example, assumes that articles have an age associated with them and are tagged with keywords. I might capture the second part of this assumption this way:

Given a keyword, the system can identify articles associated with that keyword.

Assumptions, when it comes to content sites, usually take the form of “given input X, the system can retrieve articles”. Back to our music site, one assumption might be that for any given manufacturer, the system can identify articles mentioning the manufacturer. This might seem like a simple idea, but unless configured correctly, this function may be outside the capability of the content management system.

As the web matures, I see information architecture becoming about defining rules and boundaries, systems for information to live in. I’m considerably less concerned with site maps, labeling, taxonomies, controlled vocabularies, and specific navigation hierarchies. Frankly, I feel increasingly less qualified to do that kind of stuff: the dynamic nature of an organization means that a consultant like me can’t swoop in and add much (any?) value to their efforts to define a vocabulary or to anticipate the hot topics in their industry one year from now.

Information architects can add value in a different way. We’re playing at a more abstract level. Given all the content generated by an organization, how can technology invisibly and unobtrusively support the creation, management, and consumption of that information? What tools and structures must technology provide to let organizations realize the most value through its content? None of the web’s evolutionary stages have rendered these questions obsolete, and in fact has made them increasingly interesting.

To that end, we’ve donated $2000 to several local and national charities. This year we decided to focus on health and animals.

I chose the Washington Animal Rescue League and Susan G. Komen for the Cure.

In 2001, Sarah and I adopted Zebby, a funny little dog who instantly became part of the family and our older dog’s best friend and biggest devotee. Zeb died suddenly earlier this year. While it will be a while before we can find another dog who lives up to the enormous influence he had on us, we’re happy to support the shelter where we got him. Washington Animal Rescue League is a no-kill adoption agency in northeast DC with an innovative approach to the design of their shelter.

Last year breast cancer claimed the life of Sarah’s grandmother, a larger-than-life woman who had a profound effect on the lives of everyone around her. We’re still reeling from the loss. Sarah’s grandmother’s legacy, besides three wonderful granddaughters, was an aesthetic, a sense of fashion, and a positive outlook on the world. I think she would like Komen–a grassroots organization with its own sense of style and a unique voice among support groups.

Owning a design firm is filled with rewards–exciting work, fantastic collaborators, opportunities to innovate–but suddenly the scope of the reward seems much, much bigger.

EightShapes Keyboard Shortcut Mousepads — You can trade ‘em!

Originally uploaded by brownorama

EightShapes is proud to be a gift bag sponsor at UX Week 2007. Our contribution — a mousepad with keyboard shortcuts for one of five popular diagramming applications.

Here’s the cool part: if you got a mousepad for a program you don’t use, you can trade with another conference attendee!

Shy? Haven’t met someone with just the right mousepad? Drop us a line via info [at] eightshapes [dot] com and we can hook you up!

If rubbing elbows with your favorite web design authors isn’t incentive enough, you can get a $100 discount off registration with the code WD-BROW, as a close, personal friend of yours truly. Register before September 10 and you get an additional early bird discount of $200. That’s three days of the brightest minds in web design for less than a grand!

If you plan on attending any of these, drop me a line (brownorama care of gmail) and let me know you’ll be there!

Meanwhile, things at EightShapes and at home are keeping me busy…

UX Week (Adaptive Path)
August 13-17
Washington, DC
Under the guidance of experienced practitioners from Adaptive Path and other top companies, this four-day conference introduces user experience practitioners to new rich internet application design approaches, practical prototyping techniques, effective cross-organization communications strategies and more. To get a 15% discount, use the promotion code UXDB.

For UX Week, I’ll be doing an introduction to user experience documentation and facilitating a panel on challenges to deliverable creation in modern web design projects.

Voices that Matter (Peachpit Press)
October 22-25
San Francisco, CA
Voices That Matter: Web Design is a unique event brought to you by New Riders, the leading publisher of web design books and resources—and home to the most popular web design authors, trainers, and speakers. Some presenters will teach you new techniques; some will show you how to avoid the potholes and pitfalls in how-to sessions; still others will inspire you to try new pathways in creative, energizing, thought-provoking, idea-driven sessions.

For Voices that Matter, I’ll offer my own take on the challenges facing user experience documentation and some of the strategies adopted to address them.

User Experience 2007 (Nielsen-Norman Group)
Nov 4-9 and Dec 2-7
Barcelona, Spain and Las Vegas, Nevada

For User Experience 2007, I’ll be repeating my well-received hands-on workshops on document creation and introductory information architecture.

Here’s a general outline of the course:

Information Architecture Overview

1. What is Information Architecture?
2. What does a typical IA project look like?
3. How does IA fit into big projects?

Information Architecture for Content-Rich Sites

1. Inventorying content
2. Understanding how users find things
3. Establishing an organization scheme
4. Developing the navigation
5. Developing the search strategy
6. Working with controlled vocabularies
7. Testing the content structure

Information Architecture for Transactional Sites

1. Different kinds of transactions
2. Understanding and documenting transactions
3. Building flow charts
4. Describing page contents
5. Prototyping transactional sites

Information Architecture for Intranets

1. Special challenges of internal audiences
2. Planning the intranet
3. Intranet maintenance challenges

Incorporating Information Architecture

1. Planning Your Information Architecture Project
2. Fitting Information Architecture into Your Organization
3. Justifying Information Architecture

Since it’s only a half-day, we’ll be focusing intensely on two kinds of documents: wireframes and flow charts. Above all other documents, these are the two that I produce most frequently, and are the most requested by clients.

• New to IA?: This is a great way to get your feet wet and try out your documentation chops.
• Been there, done that?: This workshop will help hone your presentation skills and give you an opportunity to think critically about your approach.

The workshop is in the afternoon on Thursday, March 22. Register through February 9, and it’s only $300.

If you’ve got some ideas on what you’d like to see, send me an email (brownorama [at] gmail [dot] com). OR, if you’ve got some samples you’d like to share during the workshop, drop me a line. There might be a free book in it…

Making Comics includes a series of exercises at the end of each chapter. Livia, Austin, James and I got together to talk comics and try the first exercise, meant to illustrate the challenge of choice of moment. Though our discussion did stray into work-related topics, we mostly focused on the exercise itself — drawing sixteen panels that represent the storyline of a particular movie. The challenge was to reduce a full-length movie to sixteen moments, using only pictures.

The exercise was really hard, but really fun. While drawing my stick-figure rendition of Princess Bride, I made these observations:

• Most everything had to be abstracted. I don’t know if this was an artifact of not using words, or simply having to translate from one medium to another. In my comic, for example, the Prince demands Buttercup’s hand in marriage. To communicate this, I had the Prince “say” (using a typical comic convention of a dialog balloon) “wedding cake”. The second part of the exercise calls for reducing the number of panels to eight. Which to remove? Thinking through this, I realized that this would require further abstraction, eliminating most of the relevant details.
• Planning is good. Each of us, before starting, made lists and thought through various details of our stories. James even storyboarded his storyboard. For me, I made a list of moments to capture, and I did some character development, clarifying how I would represent each important characters, to ensure consistency from panel to panel.
• Some behaviors are extremely difficult to represent visually. Recall in the Princess Bride how two guys who start out Bad (the Spanish swordsman and the Giant) become Good later in the movie, rescuing the Man in Black from the Pit of Dispair. These kinds of moral transitions can be confusing without using words: why would bad guys who had been trying to kill our hero now be saving him? James, in drawing out The Matrix, ran into the same thing. When Neo is sparring with Morpheus, there’s no (obvious, clear) way to visualize that this is just practice, he’s not “really” fighting his mentor.

Looking at user experience documentation as a form of comic is going to become increasingly relevant as web experiences and interfaces become more complex, subtle, and nuanced. In showing AJAX transitions, for example, we designers need to decide which moments in the interaction communicate the design most clearly.

In addition to CLARITY, good storytelling gets the audience to CARE, according to McCloud. This is a more difficult concept to translate to documentation, but for me the relevant parallel is, well, RELEVANCE. There are many perspectives to web development — visual design, business, development, data integrity, etc. — and documents that try to address all these perspectives are unlikely to succeed. Instead, a document needs to focus on a particular perspective and focus the content on what’s relevant to that perspective.