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!

From The Office: Michael and Holly

Last season, Michael fell in love with his office’s new HR manager, Holly. When the powers that be found out, they relocated her to Nashua, anticipating (not without reason) serious repercussions from the office romance. Months later on the road trip, Michael’s traveling companion, the receptionist and office manager Pam, talks about finding closure on an old romance of her own. Michael becomes convinced a trip to Nashua will help him get closure on his relationship with Holly.

Upon arriving at the office in Nashua, Michael and Pam learn not only that Holly is out sick that day, but also that she has started a relationship with someone in that branch. The effect on Michael was evident, an even balance of humor, discomfort and compassion that is the show’s calling card.

Michael decides to conduct the training anyway. It is, no surprise, an unmitigated disaster. He hasn’t even uttered half a sentence before he passively aggressively picks on Holly’s current flame. Needless to say, before long he retreats, leaving Pam to finish the training (along with all of Michael’s slightly inappropriate and extremely unconventional training props, like a real chain saw).

This is merely one example of many that illustrate Michael’s complete ignorance of basic social conventions. Each week The Office treats us to insights about basic human behavior, especially in a professional context. Michael’s exaggerated behaviors shows us what happens when you take best practices for dealing with office dynamics too far.

As part of our Difficult Conversations workshop, Chris brainstormed four pieces of advice. We use these to kick off the workshop because they are, on the surface, some basic tips for improving our skills in managing difficult situations. At a deeper level, however, they are yardsticks by which to measure our own behaviors.

• Be Positive: Focusing on what can happen and what’s working in a situation preserves the forward momentum of the project.
• Engage Your Audience: Making colleagues essential to the process curtails potentially adversarial situations stemming from a perceived lack of ownership.
• Empathize: Putting yourself in your colleagues’ shoes can help put their comments and behaviors in a larger context.
• Lighten Up: While still taking the project seriously, it’s possible not to take yourself too seriously, jeopardizing progress by letting your ego get in the way.

In adapting this workshop to a short lecture, I wanted to help participants understand that it’s important to strike a balance with each of these best practices. To that end, I identified the extreme for each of them, surfacing what it meant to take each of them too far:

• Be Positive: ignoring potentially adverse situations or issues
• Engage Your Audience: losing the focus of the project in favor of coddling colleagues
• Empathize: getting too personal
• Lighten Up: making a joke out of everything

In looking at these extremes, I saw Michael Scott, the logical exaggeration of all the things we try to do to smooth over office politics. The reason why The Office is a successful sitcom, besides the sympathetic characters and good writing, is that it’s grounded in reality. Michael’s behaviors aren’t alien to us. They’re sourced from ideals we strive for. The ideal, though, isn’t an extreme: it’s a balance.

What we did not anticipate was a global financial meltdown. Believe me, if we had, we definitely would have told you about it.

Before the mess, we put on a successful, sold-out, one-day workshop in August 2008. It was small, but participants seemed happy and satisfied. We priced the full-day workshop about $200 less than a full-day pre-conference workshop costs at the IA Summit. We probably could have charged more, but we wanted to gauge interest, format, venue, logistics, etc.

At the beginning of 2009, I sat down to plan the EightShapes conference. At that point, it was clear that people were doing business differently. On the consulting side, we saw our clients going through budget cuts, and it was taking longer to close new customers. We heard about friends getting laid off. We started a drinking game around using the words “limit travel” during project planning calls.

We ran a survey to gauge interest in content and different formats. Respondents indicated that they would be up for a two- or three-day conference. We got to planning a multi-day event that mixed workshops with regular sessions.

Then came the conferences, the usual ones we attended every year–Interaction and IA Summit. Though Interaction was larger than last year, I know it took some effort to get the numbers up. Attendance at the IA Summit was almost half what it was last year. My pre-conference sessions, with participants usually numbering in the dozens, were considerably more intimate. The evidence suggested that the big conferences weren’t doing as well–businesses both small and large were watching expenses.

So, we decided to go in the other direction. Fortunate that we work in a community with a large UX presence, and one that craves education, we based our new approach on three things:

1. Small
2. Inexpensive
3. Practical

We had kicked around the idea of a monthly workshop series before, and now dusted the idea off since it seemed like a good fit for the current climate. (If you’re following along, you’ll note idea has been kicked, dusted, and fitted.) The new format meant we could focus our marketing to the DC UX community, explore new venues, and keep costs down by eliminating typical conference niceties. At the same time, with a smaller group, we could preserve some of the creature comforts without adding too much cost. Here’s how the concept netted out:

• Venue: Cool library room at the mansion at Strathmore, an elegant arts venue in suburban DC
• Cost: $188
• Size: 12 people max

So, without further ado, the EightShapes Monthly Workshop Series, and our first workshop, reprised from the IA Summit at about $200 cheaper, Modeling Concepts.

If you’re in the DC area, I hope you’ll join us!

As part of this process, we survey and interview the design team and people who work with them. What we find is that many large design teams fall into the same traps and are trying to overcome the same obstacles, even in industries as different as high-tech and hospitality.

Last year, it occurred to us to run the survey that we use in these projects across the whole industry, to build a picture of how our field uses documentation.

To that end, we’ve launched the EightShapes Documentation Survey, an industry-wide inquiry on design documentation practices, techniques, and tools. The survey is actually dramatically different from the one we use in our practice, only because we wanted to cast a wider net. We had to make it applicable to a broader audience.

If you complete the survey, you could win a book! We’re giving away two copies each of my book (Communicating Design) and my partner’s book (Modular Web Design).

So, dive in! It’s 25 questions and won’t take you more than 20 minutes!

The EightShapes Documentation Survey

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!

At the IA Summit, there were a couple of contentious sessions. To be honest, I didn’t attend them. On purpose. I don’t go to the Summit to get my hackles raised or to be entertained by over-the-top performances. I go to learn things, to make connections (both conceptual and personal) and for inspiration. The good news is that these weren’t lacking this year, only overshadowed. Here are a few themes that emerged:

1. Core Idea

The notion of using theme in the design process is hardly new or unique to design, but it’s something that was explored from several angles. I’ve been noodling on the idea for a few years, ever since I decided to revisit creative writing and read a book or two on the subject. In writing, obviously, a theme is crucial.

At last year’s Summit, Leah Buley presented a fantastic talk on being a lone wolf user experience designer. (Her CommonCraft-like approach was in part an inspiration to me to use a sketch style in my presentations.) The talk covered a few topics, but one of the things she mentioned was “design principles,” a collection of ideas that are meant to guide the design process. It was an appealing merge of two things–a theme and more traditional software requirements. They were sort of creative requirements.

Cindy Chastain took the idea further this year by more directly applying techniques from creative writing (in this case, screenwriting) to the work that we do. She generously shared a few templates with us, showing how she captured a central idea, and then built upon the idea. This nugget, this core concept isn’t a throw-away line, generic and shallow. Instead, it’s a carefully considered expression of the product’s theme, message, and philosophy. It’s specific, meaningful, and pervades the entire design process, like a melodic theme might do in a piece of music.

But the notion was elsewhere in the Summit. I loved Matthew Milan’s talk on insight. His overall message to us was that having the insight is more important than having done tons of research. A little research to back-up a couple of meaningful insights is better than million dollar research projects that serve only to validate ideas. Like creating a theme for design work, expressing the outcome of research simply, meaningfully, and in an engaging way (Matt’s shocking but useful example was “your customers behave similarly to drug users”) can be a powerful tool for motivating change.

2. Self-Reflection

Chris Detzi and I put together a pre-conference workshop on “Difficult Conversations” and it went better than I could have hoped. While we had a lot of content prepared, our real goal was to encourage good discussion and sharing. We provided a framework to help people talk about their challenges. One of the session’s underlying messages is that difficult conversations have to start with self-reflection, with gaining a better understanding of your own strengths and weaknesses. I hope the participants found this exercise valuable.

Self-reflection also popped up a couple times in the regular sessions, though perhaps not as clearly as “core idea”. Admittedly, I read it into the message of a couple sessions, perhaps because I was feeling self-reflective.

Samantha Starmer gave a heartfelt and practical talk on “HiPPOs” — the Highest Paid Person’s Opinion — and how to deal with them. While it was, at one level, a better summary of our pre-conference workshop than I could have given, it was also a good exploration of corporate politics. Again, her underlying message encouraged participants to think about their role and place in the corporate hierarchy and what they can do to route around the silos. Self-reflection seemed like a key ingredient.

Sam’s wasn’t the only sessions that didn’t deal directly with information architecture. I was pleased to see several “soft skills” sessions in the program, including “Courage to Quit,” a panel discussion on starting your own shop. Three of the panelists were sole proprietors and my colleague Chris Fahey represented the “small partnership with employees” model that we use at EightShapes. Each gave a great account of their history and lessons learned in pursuing self-employment. At the conclusion of the individual presentations, I asked what kind of self-reflection was necessary in order to make the plunge. In starting EightShapes, for example, I had to be honest with myself (and my partner) about the range of my capabilities, my ability to grow, and what I really wanted out of the arrangement.

Sarah Rice, Whitney Hess, and Chris gave great responses, echoing some of the things that I had thought about and expanding on the idea that self-reflection is important as an entrepreneur beyond just starting the company. Chris also admitted that mostly things move too fast to reflect on them beforehand.

Of course, Professor Michael Wesch’s keynote was nothing if not a meditation on how new technologies permit new levels of self-reflection. Hardly apologetic for what to some might appear self-centered, Prof. Wesch’s talk instead celebrated the depth of connection people find online, through these new tools. He highlighted YouTube’s “response” feature, a way for people to leave video messages for each other, as a means for inviting others into one’s internal thought process. In a meta sort of way, Prof. Wesch’s talk was a self-reflection of self-reflection. This is what conference keynotes are for, though, aren’t they.

3. Context

While hardly as strong as the other two themes, I did appreciate that there was a lot more “meta” talk at this conference than those past. Right next to discussions on facets, deliverables, and heuristic analysis were sessions on the environments and climates in which we operate and for which we design products.

Prof. Wesch again set the stage with a concept called “context collapse,” a notion that things we say and do take on a life outside the context in which they were uttered. The extreme example is the politician or TV personality who says something without knowing they’re being recorded, only to find that clip posted to YouTube. Wesch likely wasn’t saying that there is not context. Instead, I took his meaning to be that context is no longer static.

Andrew Hinton’s talk was a nicely serendipitous follow-up to the keynote. His session also explored the role of context in design. For social media, context is crucial because our identity is derived not only from who we are, but who we are in specific contexts. Giving him pause, for example, was his teenage daughter friended him on Facebook. “I can’t not friend her,” he said, “but I did have to think about who I am on Facebook and whether it was OK for her to see that.”

Several sessions raised issues around the context in which we work. Though I didn’t attend his session, Eric Reiss talked about “return on investment” (ROI). What I got from the live-Tweeting and accounts from friends was that we designers mistakenly try to use ROI as a way of shoe-horning design into a business context. Eric offered other ways of realizing and communicating the value of design in a business context.

Jesse James Garrett’s closing plenary was also a meditation on context, on the state of the industry, on the divisiveness between different disciplines and the sour situation we’ve created for ourselves. Argue with the content or the packaging, but the core assumption is undeniable: The in-fighting in the fields of user experience design is not a context that makes doing our work fun.

For me, though, it was interesting to hear about how other designers and businesses are responding to external pressures. Financial crisis aside, there’s a lot to learn about how people do design relative to clients becoming more sophisticated about our work, to the backlash against specific methodologies, to the trends in new techniques.

As always, the greatest value for me is talking to people outside sessions. This year I got to hang out with people I’ve only ever really interacted with through Twitter. I got to reconnect with old friends. And I got to catch up with people in between, people I’ve met a few times in person but mostly know online. The range and depth of our relationships is far more fascinating, engaging, and rewarding than it’s ever been before.

Next Year

I won’t mind seeing pre-baked controversy in the program next year. If organizers want to include a purposefully contentious session, so be it, but I hope these debates aren’t about how we do our work. Deliverables, methods, and definitions should be off the table for debate. Instead, I hope that these heated discussions can be around the work itself.

For example, I’m thinking of submitting a talk where me and my partner each present designs we’ve done throughout the year and the other critiques it. Nathan and I tell each other what we like and don’t like about our work all the time. I’d like to see how the community responds to that kind of debate.

Either way, I can’t wait to see you in Phoenix next year!

Let me give you a taste of how the workshop goes:

• In the first third, we talk about general best practices around documentation. We’ll spend time looking at how purpose, audience, and other factors shape the overall document.
• In the remaining two-thirds, we dig into specific documents. Usually, for each type of document we’re discussing, we spend ten minutes or so sketching a sample artifact (like a wireframe or flow chart) and then sharing a few of them.
• The fruit-throwing portion of our session then begins, where I show examples from my portfolio. We talk about what works and what doesn’t work about a few of them. My ego is sufficiently iron-clad such that we can get pretty brutal during the session, but know that I cry in the corner during the breaks.
• With the Socratic “learn by doing” out of the way, I’ll talk about some considerations for each artifact. Though I persist the “layers” approach described in the book, I’ve started providing a set of “content decisions”: a finite set of Things to Think About while you’re planning an artifact. Here’s the relevant slide for flow charts:

Some other things you should know about the session:

• There’s lots of discussion. I love hearing people’s war stories and ideas on how they do documentation.
• Even though this is a “basics” workshop, the basics are definitely getting more advanced. Most participants are familiar with the fundamental conventions of wireframes and other artifacts, so the session ends up being about how to improve your personal process for doing these things.
• My style is conversational, low-key, humorous*, and honest.

So, that’s the long and the short of my full-day workshop at the Web App Summit. If you’re considering coming, leave me a comment and I’d be happy to talk with you about whether the session is right for you.

If you’re sold, and hopefully you are, the icing on the cake is that if you sign up with the promotion code BROWN, you’ll get an extra $50 off for each day. Sign up for all four days and you’ll get an iPod nano. So, what are you waiting for? Register now!

* LOL not guaranteed. We will back snorts and giggles, however.