[Reprinted from my old blog, dated October 2005]
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.
- Focus the system on providing information to users to support the decisions they need to make.
- Trust users to make good decisions if given the right information.
- Avoid enforcing business rules, which may change with each new situation.
- Evaluate requirements based on the extent to which they support decision-making.
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 tech lead and I met informally a few weeks ago, and it was clear that he and I see eye-to-eye on this approach. He lamented the existing system as inflexible, indicating that the users have been extremely frustrated that it’s not designed to match their thought process. They’ve had to develop some work-arounds to accommodate situations that are not as extraordinary as they first thought.
- The system is meant to support a process with more-or-less clear inputs (submissions from customers), outputs (approval or denial of submissions), and milestones (specific dates are determined at the outset). These clear-cut bookends make it easy to imagine the process in this way.
- The system has pretty clear roles: a lead (the person who makes the decision about the customer submission) and a reviewer (the person who does the initial review of the submission and makes a recommendation). Because of these clear roles, we could structure our conversations around the different people making different decisions.
(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:
- Different people answer the same questions differently. The best example is the assignment of reviewers to customer submissions. Some leads do this arbitrarily while others apply a thoughtful approach. It told us that we couldn’t use the system to enforce any particular method.
- Some decisions are repeated. Since our users are looking at a collection of items, they need to ask the same questions about each item. Sometimes they can make these decisions in bulk — about a number of items at once — and in other instances, they can only make them one at a time.
- Some people have to answer the same question based on different inputs. Leads and reviewers all have to decide how they’re going to priortize the customer submissions, but they use different criteria to make this decision.
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:
- Two cards went together if they were related decisions — decisions about the same kind of thing or made virtually simultaneously. For example, two decisions considered related were, “Do we have enough people assigned to the project?” and “What method will we use to assign people to customer submissions?”
- Two cards went together if they were decisions that could be supported by the same information.
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:
- Interaction models: At this point, we haven’t thought about the transaction side of the application. In a sense, this approach is more bottom-up: we’re looking at the screens we need to design to support various decisions, but not how those screens should relate to each other. At this point, it’s conceived as a linear process, but clearly it’s more complex than that.
- Same screen, different users: The way these requirements shake out, it’s very focused on individual user types. Clearly, the same screen may be used by different users, even though they’re making different kinds of decisions. I’m not sure how I’ll resolve this.
- Validation: The current situation at the client makes genuine user research difficult, so I’m not entirely sure how we’ll validate the design. Like I said, the source of this information has been the team itself, who has done extensive requirements gathering. This isn’t a case of excluding the users because our team are decent surrogates, but it is still a bit of a vacuum.
- Extension of method: Will this method be useful for other projects? Only time will tell.
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.
I’m teaching two workshops in September, and it’s not too late to sign up!
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!
My second poster from the 2005 IA Summit, and another one I’m particularly proud of. In the mid-2000s, during the renovation of our house, I became interested in audio systems. As an IA, I was curious about how people who expect their entire music collection to follow them around could navigate the library with a small interface. That led to getting a few different whole-house audio products to try, and subsequently this poster.
In 2005, I presented this poster at the IA Summit, on different techniques for representing data and content in wireframes. By request, I’ve posted it here.
Michael Scott is (or was, if you’ve been following The Office this season) the branch manager for a mid-sized paper company in Scranton, Pennsylvania. He and his branch are successful despite themselves, and corporate headquarters asks him to do a northeast roadshow to other branches, to explain the secret of his success. (Corporate is constantly surprised by the performance of the Scranton office, for reasons that will become clear in a moment.) For the roadshow, they make only one provision: He is to avoid the office in Nashua, New Hampshire.
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.
From the get-go, Nathan and I knew that training and education would be a major part of EightShapes’ offerings. We anticipated offering private training to our clients in our techniques and expertise. We also aspired to build a multi-day conference attracting participants from all over the world. With Adaptive Path no longer offering UX Week in Washington, DC, we perceived an enormous opportunity to create an event that served our local community while providing content worthy of a national or global conference.
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:
- Small
- Inexpensive
- 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!
One of the things EightShapes, my company, does is to help our clients improve their documentation practices. We look at the work they’re doing now, identify ways to improve their approach, create tools on a common platform, and instruct them how to use these tools and expand the set.
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!
This is the closest I will get, hopefully, to the public debate on what we call ourselves. I’m not a fan of the conversation, but the dialog below was an itch in my brain I had to scratch. I’m always surprised by people in our field taking an either/or black-and-white approach to things like definitions. As I hope the dialog below shows, the labels aren’t so much labels as they are convenient signposts pointing to ever-increasing areas of specificity without precluding any other.
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!
In April, I’ll be running a workshop at the Web App Summit on design documentation–you know, the documents you make to help explain your brilliant ideas to your adoring clients and colleagues. If your work involves creating wireframes and flow charts, usability test reports and personas, you’ll get a lot out of this session.
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.
