I was a late blogger. It must have been around 2004 when I started blogging in earnest. Greenonions.com was primarily a vehicle to elaborate some strange (some might say paranoid) ideas about how cognitive linguistics (as described in George Lakoff’s book Women, Fire, and Dangerous Things) can shed light on the challenges with content management. I wrote dozens of blog posts on how the metaphors we used to describe content management were (a) evidence that we had conceived the technology incorrectly and (b) actively undermining our efforts to implement good content management systems.

The two venues where I really got to explore these ideas were at the IA Summit in 2006 and at the IA Retreat in 2005. At the Summit, I led part of a workshop sponsored by the IA Institute, and then I gave a regular session on new ideas in content management. The Retreat was more fun. I constructed a workbook (PDF download) that drove the conversation.

I’m confident that with sufficient time to do research, I could elaborate this concept into something substantial. The language we use to talk about computing no doubt shapes the design of interfaces and the ways technology integrates into our lives. Emphasis on “sufficient time”.

I’m not interested in drawing a solid line between IA and content strategy: you do this and I’ll do this. As we’ve seen with most multi-disciplinary approaches to design, different people bring different perspectives. In the elaborations below, that’s exactly my intent: to show how the perspective of a content strategist is useful in design challenges I face day-to-day as an information architect.

Range of priorities

What I said: The range of priorities within a given content type. For example, is every press release going to be equally important (or unimportant), or is there a big spread between the most important and the least important press release?

Why this takes a content strategist: Intimate knowledge of the content and how users relate to it helps answer the question whether the content type is inherently important in their work, or whether importance is driven by external circumstances and other criteria.

Why this matters to IA: As I’m designing an interface to highlight content, I need reliable ways to prioritize new compositions. If there’s a big spread, I’ll need to develop a metadata framework that provides other means for prioritizing content.

For example: A high-tech marketing site offers various “solutions” that correspond to particular business problems. Imagine a “green technology” section within the government industry pages. The green technology pages provide various types of content–white papers, case studies, executive briefs, brochures, etc. Users can click a content type to see a full list. Some compositions are more important than others because they have a longer shelf-life. Some brochures, for example, provide an overview of green technology while others describe specific applications. Some brochures reflect the latest thinking while others provide more of a foundation.

Algorithmic prioritization

What I said: Whether the relative priority among its peers can be determined by a rule, or if a human needs to decide. That is, given a set of five press releases, is there a rule I can reliably apply that will prioritize them? (For example: release date.)

Why this takes a content strategist: Intimate knowledge of how the organization creates content can identify whether they’re capable of supplying sufficient metadata to support elaborate prioritization criteria or whether they have people dedicated to providing editorial support.

Why this matters to IA: My specifications need to distinguish between content areas that are populated automatically and those that require human intervention. I need to be able to spell out the rules for prioritizing content, but I want to make sure I do it in a way that’s sensitive to both user needs and the organization’s ability to support it.

For example: Suppose we decide that the green technology page should incorporate a taste of each of these content types. To create a focal point for the page, we need to pick one main composition from among all the content. We then need a couple examples of each type–exemplars that illustrate the kinds of information you’ll find. We decide that for the page’s centerpiece, there’s no convenient criteria for selecting that content automatically. Instead, the design specification calls for human intervention to determine the most appropriate composition for the center piece.

Inherent prioritization

What I said: Whether there is an inherent prioritization between content types. That is, is every press release going to be more important than every white paper?

Why this takes a content strategist: Understanding the range of content to appear in each type, an how users relate to that variety. Also, content types represent genres, so content strategists will understand how people integrate those genres into their work.

Why this matters to IA: Yet another rule to facilitate prioritization. If I understand that one type of content will always be more important than another, I can use content type as a prioritization criteria.

For example: One more look at our “green technology” page on this high-tech client. User research shows that purchasers of the client’s products are most interested in how their own peers have been successful with green technology. The design team decides that case studies should therefore be the most important content type. At the same time, the business doesn’t want a case study to overwhelm the other content types: there’s plenty of valuable information in there that also helps people decide to buy. To balance these needs, the design team decides to build more solid relationships between the other content types and case studies, such that every white paper, brochure, and executive brief points back to a case study, and vice versa. Through designing page components, the information architect makes this relationship explicit.

• Do these design challenges ring true? How would you have handled them differently?
• Do the perspectives implied in these vignettes align with your experience?
• Are the distinctions drawn sufficiently clear/vague to suit your team?

What do you think, should I elaborate the other points, too?

Image from Flickr user @alphageek, licensed under Creative Commons

Maybe it’s just the projects I’m working on, but I feel like I’m using the word “constraints” a lot.

(That sounded a lot more bitter than I intended.)

It’s a word we’ve been throwing around, but experience shows there’s considerable nuance to it. Shining a light on these constraints may help us better understand the boundaries in which we must operate, and help us spell out the requirements for a project.

Nathan is working on an essay about design standards, and he’s taking a more thorough look at how designers and organizations should relate to them. Standards may be a way of dealing with constraints, or a constraint in and of themselves, but there are other pieces to the framework that bear spelling out.

What is a constraint?

Constraints are inputs into the design process that make designers are focused on solving the right problem. The design process depends on exploration and iteration, two things that can take designers further away from appropriately solving the right problem. Constraints allow us to evaluate the output of our design process to make sure we achieved our objectives.

What I’m most interested in, though, is a taxonomy of constraints. What are the specific things that establish boundaries and provide a means for validating design?

User research

Designers who subscribe to user-centered design philosophy prioritize user research perhaps above all others. In short, user research yields a set of expectations–what users would like the product to do. As we produce design ideas, we can compare the idea to user needs. Doesn’t address a need? The idea dies.

Project objectives

Most of my work these days involves designing web sites to meet a specific business objective. Sometimes it’s hard for me to relate the business objective to any other constraints, but that’s the nature of the organizations I’m working for. The project is a small piece of a larger machine. Depending on the piece and the machine, failure of the part may or may not mean failure of the whole. Regardless, these constraints can sometimes seem arbitrary as they serve some abstract objective and not a concrete requirement driven by users.

Project parameters

As much as we don’t like to admit it, there are external (and again, seemingly arbitrary forces) that scaffold the design process. Most explicitly, these are deadlines that confine the range of activities we can perform in order to conceptualize and flesh out a design. Less explicitly, these may be the whims of project stakeholders and other team dynamics.

Technical implementation

Though technologists are fond of saying “We can make it do anything,” the truth is that most design work happens in the context of existing systems. These existing systems come with capabilities and configurations that make some design ideas more feasible than others. The sometimes unsaid extension to the technologists’ mantra is “We can make it do anything with sufficient time and budget.”

Operational implementation

Just as the technology provides a context for a design idea, so too does the organization that will support it. There are people behind every technology, having to provide support in everything from customer help to content updates. Without the infrastructure from an operational perspective, some design ideas will not be successful. To thrive, a design must acknowledge the organization that will support and maintain the final product.

Industry standards

Otherwise knowns as “best practices,” these conventions emerge after withstanding the test of time. Used widely on other web sites, such standards become constraints in so far as they establish a baseline from which other design decisions extend.

Organizational standards

This is where Nathan’s essay will come in. Establishing standards specific to the organization is a complex process with numerous benefits. Suffice it to say that from the designer’s perspective, standards provide a range of starting points for solving problems. Positioning and integration into the design process is crucial: done poorly, these constraints come across as creativity-killers.

Design principles

A good team will summarize their direction in a single theme or collection of bullet points. This direction is specific: “make it easy to use” gets eliminated as a principle pretty quickly, for example, because it isn’t specific to the project and is common to all our projects. Instead, design principles are specific and meaningful to the team working on the project. They are means for making design decisions.

They are, in a sense, a super-set of all other constraints. I didn’t really think about this until now, but teams compose design principles when they want to boil down everything they’ve learned from all the other constraints.

Constraints are good

I don’t know if this–design decisions within a framework of constraints–is the right way to look at design. I can’t imagine Steve Jobs making a list of constraints before sketching out the Next Big Thing. On the other hand, design doesn’t end with a concept. Myriad other choices go into realizing a vision like the iPod. No doubt constraints play a role in mediating these other decisions.

Here’s the thing: I like constraints. They define a design problem. They help me understand what success is. They let me collaborate efficiently with other team members who share an awareness of the project’s boundaries.

Further exploration

Some ideas on exploring constraints further:

• Prioritization: What process do we use to prioritize constraints? Is there a Maslow’s hierarchy for constraints that implies which things are most basic and which are less necessary?
• Distinguishing from requirements: What’s the difference between requirements and constraints? In short, requirements state the problem and constraints are a tool to help me solve the problem. Can the distinction be more nuanced than that?
• Managing conflicts: How do project teams deal with conflicting constraints? Presumably these conflicts are ironed-out at the beginning of the process, but in practical terms, I suspect this does not happen formally until the conflicts arise.

These principles were the topic of my short session at this year’s IA Summit (taking place in the arid, strangely quiet Phoenix, Arizona). I’ve posted the slides to SlideShare (also embedded below), and the speaker’s notes are intact. For those interested in the process that got me to the slides, you can download a PDF of the outline I prepared.

One of the major conclusions of my work in content management theory is that systems designed to enforce decisions will fail. Consider a workflow system that forces users through the same process, regardless of circumstances. Invariably, situations arise where the basic workflow doesn’t hold — authors are absent from work, editors don’t have the right expertise to review a document, the content demands a new structure. Yet the majority of content management systems — indeed, most business systems — prevent humans from accommodating these scenarios because they are confined by the rules imposed by the computer.

I realized that computers should stick with what they’re good at — serving up information — and humans should be allowed to do what they’re good at — making decisions about day-to-day situations.

Coincidentally, I have begun work on a new system that is ripe for applying this philosophy. This project has a couple things going for it:

(The purpose of the project is to support a process for reviewing submissions from this organization’s customers and providing some kind of response.)

We’re still in the early stages of the project, but so far it seems to be working well. The project manager, tech lead and analysts have been enthusiastic to play with these new techniques, for which I’m most grateful. The design team seems to know that I won’t let them down, and they’ve been positive about my lines of questioning, so I seem to be getting at information that will help inform the design. Here’s what we’ve done so far:

Decision Lists

Instead of compiling all our observations into a list of requirements, we brainstormed a list of decisions our users have to make during the course of the process. These decisions were expressed in the form of questions like, “How many reviewers will we need?” Though the answer varies with each situation, they pretty much always have to answer this question.

As the brainstorming progressed, we sorted the decisions in more or less chronological order and categorized them in different events. For each event, we indicated who the key decision-maker was and the scope of the decisions — what the decisions applied to, whether that be the entire project, one of the customer submissions, or one element from one of the customer submissions. Most importantly, we began listing the inputs — the information that the users need to make the decisions.

The outcome of this process was a table that listed every decision our users have to make during this process. I also captured some of our outstanding questions about the process, so we could clarify with users at a later date. Some observations from this exercise:

Most of the data for this exercise came from the team’s existing knowledge. Obviously, first-hand user research is preferable, but at this point infeasible.

Sorting Decisions into Screens

Admittedly, after we came up with this list, I wasn’t sure how I would use it. Everyone got into the process of creating the list, but I hadn’t though much further ahead. I was used to personas — a flury of activity yielding deliverables that sat on the shelf.

After a requirements meeting with the client, we held a post mortem and the project manager indicated that we were starting to come up on the design deadline. I suggested a brainstorming meeting, but wasn’t entirely sure how I would facilitate it. At first I thought about an exercise I saw Marc Rettig demonstrate where he’d taken all the system features, put them on stickies, and organize them into related groups. It then occurred to me that I could do the same thing with our list of decisions.

I printed each decision out on a card and we did an internal card sort. There were a couple principles guiding the card sort:

During the process, we elaborated on the kinds of information the users would need in order to make the decisions. We also realized that although we’d separated some decisions by events in the listing exercise (above), they really went together. In other instances, we divided a single event into multiple groups of decisions — one event ended up as three groups of decisions.

To facilitate the activity, we imagined each group a “screen”, such that a user should be able to make all the decisions in the pile without having to click away. In other words, one screen in the application should be able to support all the information required to make all the decisions in the pile of cards. This is how I set up the exercise for the team, and thought it made sense because we were trying to group like decisions. In the back of our minds we knew that this initial take may be totally off base, but it did help move the discussion along.

The feedback on this exercise was very positive. It allowed us to envision the user experience without getting caught up in screen design — even at a basic level. I didn’t stand at a white board and sketch rectangles. It was refreshing.

Decision-focused Wireframes

Even my wireframes look different. I’ve only just started, but for the first time my IA decisions have real traceability. In addition to functional annotations, the wireframes include the decisions that the screen needs to support. I’m taking a crack at ranking the decisions based on our card-sorting conversation. Each wireframe, therefore, includes a list of decisions that the user should be able to make when looking at the screen and which of those decisions is most crucial.

The wireframe itself is shaping up like my page description diagrams — a list of content in priority order. By including the list of decisions, I’m showing my work: the most important information on the screen corresponds with the most important decisions users have to make.

Next steps

It’s hard to say at this point whether this approach is worthwhile, and the success of the wireframes will be a big part of that. The challenge for me will be to get out of the high level and focus on the details. (Though a decision-based approach does force this by putting crucial information front-and-center in the design process.) There are a few other things that we’ll need to work out:

Despite these reservations, I’m really pleased with how this approach is working. For years I’ve wondered how to adapt the requirements process to the needs of an information architect. Conventional requirements (”The system shall…”) have always felt inadequate to capture user needs for our purposes. Personas are too high-level, too difficult to apply directly to requirements. Use cases are too time-intensive. For the first time, I feel like I have a useful mechanism for capturing IA requirements.

Creating and Using Concept Models

Hosted by TriUPA
Research Triangle Park, North Carolina
September 8, 2009 9am-5pm
Details and registration

The ideal tool for thinking through and designing structures for today’s web sites, concept models have become extremely popular artifacts. Creating them, and getting your team members to buy into them, can vary from challenging to really challenging.

Instead of representing individual web pages, concept models describe structures that are more appropriate for planning complex navigation strategies and working with content management systems. Their flexibility means you can apply them in a variety of circumstances and use them to describe different kinds of structures.

I’ve revamped this workshop from the ground-up, after getting lots of great feedback over the last couple of years. The content focuses more on pragmatic issues and now includes a section on translating concept models into wireframes. I’ve also created two sample models that will form the basis of our discussion.

Creating and Using Flow Charts

The Mansion at Strathmore (Bethesda, MD)
September 25, 2009 1pm-5pm
Details and registration

This is the next workshop in EightShapes’ monthly series. I’m especially excited about this one because I haven’t taught a workshop dedicated to flow charts, only as part of a larger workshop on deliverables.

Our clients are increasingly asking for flow charts (again!) since they’re crucial to planning and describing overall experiences. There are also a couple interesting variations which we’ll cover as well (storyboards, more focused on narrative; and wireflows, flow charts that integrate wireframes).

Early bird pricing (US$195!) lasts another couple weeks, so register now before the price goes up!

Hope to see you at one or both of these!

These days, one of the ways I meet new people is through the playgroup my son goes to. Sarah (my wife) will make a connection with another mother, and then we invite the family to hang out. In this slightly fictionalized dialog, I meet Lizzie and Mark, who have two sons. Their elder son John and my son Harry are in playgroup together. (Names have been changed.)

The scene: Sarah and Lizzie sit in the living room watching the boys play while Mark and I hang out in the kitchen as I’m preparing brunch.

Dan: Hey, Mark, it’s nice to meet you.

Mark: Nice to meet you, too.

D: So, what do you do?

M: I’m a doctor.

D: Cool. If it’s DC, you’re either a doctor or a lawyer, am I right?? (Slight look of regret on Mark’s face.) So… «ahem» where do you work?

M: I’m up at NIH. (NIH = National Institutes of Health, a government organization responsible for conducting medical research. Based in Bethesda, where I live, it’s a major employer in our area.)

D: So, you’re a researcher?

M: Yeah, but I also spend a lot of time at Suburban. (Suburban = local hospital across the road from NIH.)

D: You do clinical work, too?

M: Well, at NIH we just get the weird cases, but at Suburban, in the clinic, I can get a broader range of patients.

D: That makes sense.

M: I’m a cardiologist, so we want to look at hearts with a range of conditions.

D: (Regretting putting so much butter in the french toast I’m making.) No kidding.

M: Yeah, so we end up going to Suburban. They benefit because they get the imaging equipment we’re working on and we benefit because we get exposure to a wider range of patients.

D: Imaging equipment?

M: That’s kinda what I do. I look at different ways to visualize the heart as a means for diagnosing conditions.

D: That’s really cool.

M: Yeah, I had no idea this where I would end up, but that’s how these things work, don’t they?

D: Tell me about it.

M: So. What do you do?

D: Brunch is ready!