I’ve posted my materials for two of the sessions I’ll be doing at the IA Summit in Vancouver this year. On the docket for me this year:

• IAI Leadership Workshop, with Harry Max, Aradhana Goel, and Paul Gould.
• Enterprise Information Architecture Panel. I’ll be moderating, and the panelists are first-rate: Seth Earley, James Melzer, James Robertson, and Lou Rosenfeld.
• New Strategies for Content Management, based on my linguistic analysis of content management concepts, and immediately following Donna Maurer’s session on Lakoff.
• IA and Web 2.0 Panel, with Gene Smith, Michal Migurski, and Michael Arrington, with Brandon Schauer moderating.

If you’re attending any of my sessions and have questions or something you’d like me to address, let me know in the comments.

As always, DCIA is going to hold a dinner at the Summit. All are welcome!

See you in Vancouver.

Over the last couple of weeks, I’ve seen a few articles on how in the last few decades business has relied on computers to do our decision-making for us. Here’s one. These articles are pointing out that we need to move away from this model, instead creating systems that support decision-making by humans. I’ll start tagging these in del.icio.us under “divisionoflabor“.

These are the same conclusions that I drew from the analysis of content managment concepts. For content, the argument goes something like this: We establish structures in content management systems that help the systems decide what to do with content. These structures, however, are limiting because we can think of novel ways to use the content that the structures can not accommodate. The templates employed by content management systems to capture content impose a particular structure that enable particular decisions–where to store the content, how to display the content, and how to index the content. Perhaps your CMS allows permits additional decisions. But this creates a barrier–the content is, in effect, stuck in this structure, and if you think of a new way to use the content (a new way to parse it, or cut it up, or index it) you’re at the whim of this structure.

To fix this problem, we need to shift the purpose of our content management systems (and other enterprise software). Instead of making decisions for us, they should be designed to anticipate the kinds of decisions we need to make. Anticipating these needs, the systems can serve up data that helps inform those decisions. Additionally, the systems can rely on more flexible structures that recognize we can’t anticipate every use of content (or every situation in the case of workflow).

I’ll be talking about this in some more detail at the IA Summit and will post my slides over the weekend.

Here are some posts from my archives relevant to this topic:

• Decision-Based Design
• Embodied Process
• Content Management’s Inevitable Conclusions
• Anatomy of a Blend, Content Management Style
• Conceptual Blending in Content Management
• Conceptual Blending in Content Types

One question that’s sure to come up during this year’s information architecture summit is, “What is the role of IA in Web 2.0?” Some people have proposed that IA–creating meaningful structures of information–is obsolete. A key component of many Web 2.0 sites is that people can impose their own structures on information through tagging. In some people’s minds, this spells gloom and doom for our field.

Information architecture has long been associated with navigation–finding one’s way through space. In the early days, information architects were responsible for generating the list of categories along the left-hand side of many a web site. They thought about how all the information on a web site fit together, and where there were meaningful relationships. They collaborated with designers and others to shape the virtual space of a web site.

Frequently, information architecture was compared to fields like urban planning. Urban planners shape city space. They identify the goals of pedestrians and other people using the space and create designs to support those goals. This was a comfortable way to frame information architecture. If the web is a virtual space, it needs its own urban planners.

The metaphor WEB IS SPACE has been entrenched since the beginning. The linguistic evidence is overwhelming: The basic currency of the web is a site, which is located at an address. Even technical terms, like URL, participate in this metaphor. What do you think the L stands for? Location. Even words like browsing and searching derive from seeing the web as a physical location.

In discussing this with James last night, he pointed out that this trope was inevitable. Long before the web became popular, the same people who would make it what it is today were reading books like Neuromancer and Snowcrash, which envisioned a virtual space populated by projections of our real selves.

When the naysayers say there is no longer a place for information architecture in web development, they are still conceiving information architects as shapers of space. But as new frames for the web emerge, so too must new ways of understanding information architecture.

Web 2.0 is, in one sense, shorthand for the idea that some web sites challenge the WEB IS SPACE metaphor. What makes any of the sites profiled on TechCrunch special is that they don’t think of the web as virtual space.

Before getting to new a new metaphor for the web, I want to establish a framework:

Web Metaphor => Primary Concern => Role of Structure

In English: By framing the web with a particular metaphor, certain concepts are established as the main unit of currency, so to speak. Those concepts, in turn, force us to think about structure in a particular way. In the case of Web 1.0, the framework would play out like this:

WEB IS SPACE => Location => Navigation & Wayfinding

When we think of the web as physical space, the primary concern becomes location, and the role of structure with respect to location is navigation.

While I haven’t done a complete linguistic analysis of Web 2.0 writings, it’s obvious that there’s no clear-cut definition yet. I’ve started compiling links of definitions, but each person brings a slightly different perspective to this shift. In doing a linguistic analysis, what’s important is not just what words people use to describe the phenomenon, but how they reason about it. With WEB IS SPACE, we don’t just simply apply the same words to web and space, we actually conceive of the web as a physical place.

Initial analysis points to a more complex conception of the web, revolving around two central models. Tim O’Reilly addresses both of them in his seminal paper “What is Web 2.0: Design Patterns and Business Models for the Next Generation of Software.” WEB AS PLATFORM positions the web not as a virtual space, but as a foundation, much in the same way an operating system like Windows or Linux is a foundation for software.

WEB AS NETWORK is the other cognitive model we’ve been using to reframe the web. O’Reilly addresses this in the second section of the paper, though he refers to it as “collective intelligence”. This model makes salient the connections between web sites, through simple links or some more complicated mash-up.

So far, everything I’ve read about Web 2.0 conceives of the web in one of these two frameworks, or some mix of both. In a sense, these models have always existed, and O’Reilly points out that people have been building sites that exemplified these models all along. I won’t speculate about why this shift is happening, but it would appear that a little Gladwell-esqe Tipping Point action isn’t out of the question.

O’Reilly discusses the business implications of both these models in-depth. There has been a ton of discussion about these models, especially the best way to leverage them to make money. The chief concern of my endeavor is not how to make money, but whether there is a role for information architecture in this new way of thinking about the web. (Of course, for information architects, it’s very much about making money.)

To put one of these models in the framework I mentioned above:

WEB AS NETWORK => Participation => ???

It’s clear from the various writings about Web 2.0 that participation is the primary concern when framing the web as a network. The size of the network and the ability for the network to engage participants become very salient. Whereas a key metric for the WEB IS SPACE model is number of visitors (the more people who come to your location, the better), the WEB AS NETWORK model would spin this differently, looking at level of participation. With many Web 2.0 sites looking to appeal to “edge” communities, quantifying participation is more interesting because they are going after smaller and smaller populations.

WEB AS NETWORK services generally don’t limit participation, but they erect a structure to make it meaningful. Look at del.icio.us or Flickr–quintessential Web 2.0/networking sites–and it’s clear that there are highly structured experiences. The designers behind these sites made conscious decisions about what it means to participate–not to exclude people, but to make the participation meaningful. You can post a URL or a photo to either of these sites without tagging or describing them, and yet they’ll still be attached to a user account and have a date. These simple contributions won’t be as meaningful as one of these items posted with tags, but participation does require a minimum amount of information.

Wikipedia is another great example of WEB AS NETWORK. It thrives on participation, but that participation is only meaningful within the context of rules established by the site. Some of these rules are business rules, but some are structural. O’Reilly’s article includes a sidebar with the tantalizing title “The Architecture of Participation.” He’s talking about technical architecture, but perhaps some of his points relate to experiential architecture as well. In this excerpt, he’s actually talking about the open source software movement, and how it provides a good parallel to what’s happening on the web:

We could restate the first phrase like this:

When we frame the web as a network that values participation, there is a clear need for structure to lend meaning to participation. Information architects must lead the efforts to define that structure, and collaborate with graphic designers and interaction designers to make sure that structure is clearly communicated to users. The problem is, I don’t know what this is called. We have convenient terms for creating structures in space–navigation, wayfinding, etc.–but not for creating abstract structures in other “environments”. Therefore, I can’t fill in the rest of the model, at least with a clever word or phrase:

WEB AS NETWORK => Participation => Structuring Participation

The second model of the web, WEB AS PLATFORM, has been more difficult for me to nail down. In many ways, it resembles the WEB IS SPACE model, because platform, in this sense, refers to an environment in which software is constructed, like an operating system. Like Windows or OS X, a platform is more than a space, though. It’s a set of rules, even a culture, establishing boundaries around development.

This environment, in O’Reilly’s words, is “without an owner, tied together by a set of protocols, open standards and agreements for cooperation.” Del.icio.us provides a good example of this frame as well, exposing all their data in an easy-to-parse format. It appears the primary concern for WEB AS PLATFORM is the format of the data, and value is measured by how easy it is to appropriate the content for some other use. In this frame, highly valued sites are also those that make effective use of other people’s data (usually Google Maps).

The role of structure in this frame is also difficult to pin down, and information architects generally don’t play in the space of data architecture, though they may collaborate with those who do. Still, I wonder if can get more involved in designing APIs and data feeds, especially if they have a role in designing the underlying structure of participation. Expressed in the framework:

WEB AS PLATFORM => Data Sharing => Data Formats

Sites that exemplify these new frames are not without their critics. Scott Karp, who writes Publishing 2.0, indicates that liberal participation from a broad audience can lead to meaningless data: “If you have a random group of people act as a filter, you’re going to get a random result.” To put it in terms of this new frame, participation demands structure, because without it Karp’s “sea of information” just becomes more turbulent. (Isn’t it interesting that someone writing about the new age of publishing still refers to information in terms of navigable space? I don’t think we’ll ever lose that trope.)

Next steps: Like my work in deconstructing content management, these frames offer rich opportunities for further research. I’ll continue to collect linguistic evidence and try to flesh the models further. At this point, my original question has not been answered in full. That is, initial analysis indicates that IA may place some role in the web as it’s been reconceived through these models, but the precise nature of that role is still up for discussion. What I’m most interested in is elaborating on the framework (model => primary concern => role of structure) and further clarifying structuring activities in the contexts of these models.

It’s true. I’m writing a book for New Riders (the same people who brought you this gem, and this one) on documentation. On a few occasions, I’ve solicited friends and mailing lists for documentation samples, and have gotten some great examples to use in the book.

A couple of people have written to ask me for details about the book. Over the course of writing it, I’ve had to provide information to my publisher to help clarify my vision and intent. I’m posting some of that material below, to provide some background.

You can pre-order the book from Amazon and from Barnes and Noble. Please do so. You will make my mother very happy and contribute a very little bit to the college fund for my unborn son. (Yes, my wife is pregnant while I’m writing the book. We don’t do anything half-assed.)

If you have any more questions, or would like to volunteer some sample documentation for a chapter, please drop me a line at: brownorama [at] gmail [period] com.

Book description draft copy from the author questionnaire

Pick up any book on Web design and you’ll either have a book on method or a book on best practices. But neither methods nor best practices take into account the nuances of each project and client. What is consistent, however, is the documentation that you have to produce – the means you use to capture and communicate ideas about system design. This book doesn’t preach a specific design method, nor does it date itself by providing design best practices that will be obsolete tomorrow. Instead, it gives practicioners tools for sharing their design ideas with their clients, stakeholders, and customers.

The book covers 10 different kinds of documentation – also known as deliverables – in three categories: documents that describe users and their needs, those that support strategy and planning activities, and those that describe the user experience. For each deliverable, the book provides a quick overview of what it is and how it generally looks, a description of the deliverable contents, strategies for using the deliverable in meetings and presentations, and an explanation of how the document fits into the overall project.

To describe the document creation process, the book uses a layered approach, showing how every document can be built in a series of three layers. The first layer is the bare minimum of information – the content of the document that makes it what it is. The second layer provides further detail, creating a more sophisticated tool. The last layer consists of nice-to-haves that may help support other agendas. By dividing deliverables into these layers, the book gives the reader a systematic approach for planning and creating them.

Jacket copy:

• Build ten essential types of documentation for Web design, focusing your deliverables on team and client communication.
• Tailor your documentation to each project without reinventing the wheel every time – use the layered approach to add increasing levels of detail without sacrificing purpose or clarity.
• Plan effective documentation presentation meetings, structuring them appropriate to the purpose – like brainstorming meetings and client buy-in meetings.
• Avoid common pitfalls – like clients signing off on documents without understanding what they mean — before they happen.
• Employ whatever methodology and documentation tools best suit your team and project – use this book to refine the outputs, not the process.

Audience descriptions from author questionnaire

Experienced Practitioners: This book will be useful for people in the business who work as user experience consultants because it will serve as a reference and a source for new ideas. They can consult the checklists in the appendix to make sure their deliverables are complete, or they can read the chapters for more information on handling special situations.

Novice Practitioners: For people who are new to the field, this book offers practical advice on easing into creating their first documentation.

Stakeholders and Clients: For people on the receiving end of the documentation, this book will help them to know what to expect. For those who are using user experience design professionals for the first time, this book can help them plan projects and collaborate more effectively with their design teams.

Book description from an email to the interior design team

The book is about the kinds of documents created during the web design process. It is meant to serve as both a reference and a learning tool. For more experienced professionals, it helps refresh their memories as they create documents, and provide strategies for using the documents in their work. For clients or people learning the trade, it provides a background to different kinds of documents and helps them know what’s expected of them, and what to expect.

Some other random notes from the email to the interior design team

I want this book to look like the young professor in college who hasn’t been jaded by the politics in academia, who engages students in rich conversations without being stuffy. The students respect the professor, but are not so awed as to be intimidated by him.

LOTS of whitespace. This book is, in a way, incomplete. It’s like a cookbook where for each recipe you’ll make your own notes about what works and what doesn’t. Give people room to add annotations.

The illustrations and pictures should be on the same pages as the sections that reference them. Most chapters have illustrations and samples, and the book was written as if the reader had that example nearby while reading the relevant section. The words and pictures are meant to operate like those in a comic book: working together to make a point, not two different ways of saying the same thing.

My favorite books from a design perspective are Edward Tufte’s books on information design.

There are no other books on the market about documentation. I believe it will be competing with books on design process and method. What makes this book distinct is that it’s not PRESCRIPTIVE, like a methodology book would be. It recognizes that people have their own methods, but need to produce the same kinds of work product, even if there are minor variations from project to project. The book breaks documents down into essential elements, nice-to-haves, and optional elements. In this way, it’s adaptive, flexible, and supportive.

Book description from interview I did with Kyle Pero for PhillyCHI

The book describes 10 different essential design documents, like wireframes (duh), usability test reports, personas, concept models, and site maps. People always ask me things like “What about [insert obscure, proprietary document here]?” The hardest part was limiting the number of deliverables to 10. There are so many tools out there, but I wanted to focus on the essentials, the ones that I get asked to produce on nearly every project I’ve ever worked on.

There is one chapter for each deliverable, and every chapter is structured the same way, consisting of four parts: At-A-Glance, Creating, Presenting, and In Context. The At-A-Glance section provides an overview of the document. This is to help people who haven’t made one get a sense of what it is. The Creating section describes the contents of the document, and strategies to ensure your document is complete and accurate. The Presenting section offers strategies for using the documents with clients and team members. Finally, the In Context section looks at how the document fits into the overall project, relating to other deliverables and some food for thought on how the document might change in the future.

There are three things I’m loving about the book:

It’s process-agnostic. I didn’t want to write another design methodology book. The market is flooded as it is, and frankly, I’ve never used the exact same methodology twice. What’s remained constant throughout is the outputs. You may use different methods, but at the end of the day, you still need to produce a site map (or whatever). I wanted to write a book that people could use without having to think too much about how to adapt it for their own needs.

It’s tool-agnostic. This is not a how-to book for Visio or any other product. Books about applications can have a short shelf-life and I wanted something that people could use for a long time. Whatever tool you use, you’ll find useful advice in here about how to structure the deliverable, and what kinds of information to include.

It’s flexible. To make it as flexible as possible, I describe the contents of each deliverable as a series of three layers. The first layer is the essential information, it’s the stuff that makes the document what it is. For example, with site maps the first layer elements are shapes representing sections of the site, and lines connecting them. If you have these, you have a site map. Layers two and three describe other elements that you can use to embellish or add further contextual information. This approach gives designers the flexibility to create documents that suit their situations. Unlike process books, which tend to be very prescriptive, this approach makes it easy to adapt the documents to individual circumstances.

The Importance of User Experience

Originally uploaded by soldierant.

New friend Bryce Glass has put together an easy to understand concept model describing the importance of user experience.

Bryce is also lending his Flickr concept model to my book. More importantly, he’s a dog person and likes comics.

UPDATE: Got an email from Frank Spillers clarifying this image. Here’s the scoop straight from the horse’s mouth:

“Please note- that poster was commissioned by my company Experience Dynamics- we
paid for it, provided all the content and even coached Bryce on the usability
of the diagram (we went through a few iterations). If you are not sure about
this, read his paragraph underneath the image on Flickr.”