Information Architecture from Thinking and Making

Target's ClearRX prescription bottle redesign wasn't all that

Austin Govella — Sat, 30 Aug 2008 10:23:00 GMT

When we talked about how Target redesigned their prescription bottles, we focused on a couple of important points: First, it's always reasonable to assume an intelligent person can look at an existing system and design changes -- or something new -- that corrects any problems. These improvements don't reduce the system's initial efficiencies. Second, to ensure adoption of any change, you need to make sure you talk to everyone who'll be affected. However, in our praise of the new design, we didn't really give the old system a fair assessment. The cylindrical, brown prescription pill bottles you grew up with are kind of like shipping containers: they're everywhere. And despite the valid problems Target's CleaRX solves, the original brown bottles worked amazingly well. Pharmacists distributed millions of these bottles without any problems. The design is elegant. Simple tubes are cheap to produce. Adding a child proof cap was probably pretty simple. (ClearRX changed their neck to be circular, like the old bottles.) And the tube is a simple canvas you can easily wrap any label around. More importantly, at the time the original bottles were introduced, it was probably less possible to produce the CleaRX bottles, and more possible to produce the cylinders. The cylinders were a "problem that could be solved". Design is less about designing the interface and more about designing the organization that designs the interface. In that sense, the staid old brown pill bottle was the better design solution. (If you're interested in more about the CleaRX system, I've saved several articles on del.icio.us: http://delicious.com/austingovella/case+studies+target.)

Two questions about Information Architecture

Austin Govella — Wed, 30 Jul 2008 03:43:37 GMT

So, we're working on the second edition of this book, and we had two questions for all the information architects out there... If you can spare a couple of seconds (and have already done the A List Apart survey), I'd like to hear about common questions you deal with as information architects. You can take the quick survey by clicking here.

A sample 'Only' statement for the I.A. Institute

Austin Govella — Thu, 12 Jun 2008 10:13:00 GMT

To kind of go through how this works, I thought we'd work through an example using the IA Institute. Now, I'm not picking on the IAI. I love them. I am a reasonably vigorous part of them. But when I was sitting in the annual meeting, I though to myself, "man, do these guys need an only statement". So here goes our fictional exercise at crafting an Only statement for the IAI.

We'll start with their tagline (“The IAI supports individuals and organizations specializing in the design and construction of shared information environments”) and convert that into an only statement:

WHAT	The only organization
HOW	that develops and supports a community
WHO	for information architects
WHERE	anywhere in the world
WHY	who want to design information spaces
WHEN	in a world of ubiquitous data, access, and connection

Well, that's not totally true. We still can't agree on what an information architect is, so let's change that the UX professionals:

WHAT	The only organization
HOW	that develops and supports a community
WHO	for ~~information architects~~ user experience professionals
WHERE	anywhere in the world
WHY	who want to design information spaces
WHEN	in a world of ubiquitous data, access, and connection

And do we really develop new communities, or do we support existing communities? Let's tweak that, and change the text so we don't use world twice:

WHAT	The only organization
HOW	that ~~develops and~~ supports a community
WHO	for user experience professionals
WHERE	~~anywhere in the world~~ around the globe
WHY	who want to design information spaces
WHEN	in a world of ubiquitous data, access, and connection

So, that's it. Now we have an Only statement that describes who we are and what we do. It's a nice enough exercise, but Only statement works best as a way to validate design decisions.

Using the Only statement

Creating the Only statement packs all of your meaning together. Once everything's packed, you can unpack the meaning to understand more about the project's core essence.

So, in the magic world of our example, we've reached the final version of our Only statement, and it reveals an interesting fact about the organization:

It's not necessarily a professional organization, and not necessarily supported by membership.
It's all about the community of practice, and not necessarily the practice. (Props for the 'Blurt!)

That definitely gives us some things to think about.

Based on the Only statement, we might reassess the services the organization provides. For our fictional version of the IAI, we might decide a community needs several things:

Jobs (an ecology of stuff to do and people to do it; not necessarily paid work.)
Discussions (email lists, forums, distributed conversations)
Multiple languages (translations)
Events (meetings, conferences, f2f conversations)
Localized news, events, discussions, jobs (Politicians always say "everything is local".)
Discussions with other communities (elevator pitches/mobile widgets, evangelization)
Mentors and mentees

And since we're framing things up, maybe we organize community needs into two chunks:

knowledge sharing (our list of community needs from above)
community memory (best practices, tutorials, case studies, library, books, links)

Already, we have an understanding of what the IAI is and what it's not. We have a framework for deciding what kinds of activities it should support, and those it shouldn't. Essentially, we've defined a strategy we can follow for years.

And that, I think, is the magic of the Only statement: that it can help guide product and design strategy. But does it have to? Next, I'll talk about at how an Only statement does and doesn't interact with strategy.

The 'Only' statement: focus on your project's key goals

Austin Govella — Thu, 05 Jun 2008 19:33:00 GMT

The myriad reasons mission statements suck has more to do with who put them together and why. Any time you explain your team's shared vision in bite-size morsels anyone can consume, that's what we call "a win". Although some mission statements explain your vision, they rarely explain why, or provide a convincing how. Tthe why and the how are what make your vision a signpost your team can strive for.

Introducing the Only statement

A couple of years ago, "Marty Neumeier":http://www.neutronllc.com/ released a follow-up to the "Brand Gap":http://www.amazon.com/gp/product/0321348109?ie=UTF8&tag=thinkingandma-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321348109 called "Zag":http://www.amazon.com/gp/product/0321426770?ie=UTF8&tag=thinkingandma-20&link_code=as3&camp=211189&creative=373489&creativeASIN=0321426770. It's a great book. Although it might seem like a book about brand strategy, I thought it was more of an introduction to business analysis. (I posted a brief "review of Zag":http://www.thinkingandmaking.com/view/the-best-innovation in January.)

In Zag, Neumeier describes a great technique, the "only" statement (starting on page 65). An Only statement is like a mission statement except it focuses on what makes you _unique_. A mission statement might answer "what do we want to do?" The only statement answers "what do we do best?"

How it works

The concept starts simply enough. Complete this sentence: "You are the only [blank] that [blank]."

The first [blank] is for your category, and the second is for what makes you unique. An example explains it better. Neumeier creates an Only statement for a fictional wine bar as an example: "Our brand is the ONLY chain of wine bars that builds community around wine education".

Neumeier unpacks the magic:

Even with this simple statement you can see that there are three unique attributes that will set this brand apart: It's a chain instead of a one-off; it's about community, not just customers; and it's built on education, not just enjoyment.

The Only statement as an exercise

The more detailed version of the Only statement exercise has you answer six questions:

WHAT	is your category?
HOW	are you different?
WHO	are your customers?
WHERE	are they located?
WHEN	do they need you?
WHY	are you important?

For the wine bar, Neumeier provides these answers:

WHAT	The ONLY chain of wine bars
HOW	that builds community around education
WHO	for men and women of drinking age
WHERE	in cities and progressive towns in the US
WHY	who want to learn more about wine
WHEN\|	in an era of cultural awakening

As Neumeirer explains, answering these questions describes your category and how you're different (the WHAT and HOW). It also describes who your audience is and where they are, as well as focuses "on a need state" (the WHY) as well as an underlying trend (the WHEN).

Using Only statements to validate design decisions

Neumeier's goal is to help organizations find radical differentiation, so the Only statements focuses on your unique selling point. If you can focus your team on your project's Only-ness, then feature decisions get easier.

When you want to add a new feature, run it by your Only statement. Does the new feature match up with your WHAT, HOW, WHO, WHERE, WHY, and WHEN? If you're choosing between two features, which one is better? (Maybe neither?)

Using Only statements for shared vision

An Only statement is a really good way to focus a team on the project's constraints (the WHAT, WHO, WHERE, and WHY), as well as on its strengths (the HOW and WHEN). This kind of focus is especially important on teams where shared vision drives the quality of the work (like "an agile team":http://www.thinkingandmaking.com/view/agile-ux-six).

It's equally important to note the difference between sharing a vision and shared vision. Sharing a vision is when Kennedy says we'll have a man on the moon in x years and everyone agrees: yes, we will try to put a man on the moon in x years. Shared vision is more like a shared worldview. When Kennedy shares the vision that we'll have a man on the moon in x years, everyone believes, yes, we *can* -- and we _should_ -- have a man on the moon in x years. Only statements help communicate a worldview that a team can share.

Only statements in the wild?

As I was putting this together, I realized it's a little abstract, so I'll try to post an example using a real project. However, if you have an example we could use, let me know!

A common language for interaction design

Austin Govella — Wed, 28 May 2008 20:28:32 GMT

Working on a way to get a group of people to annotate simple and complex web interactions in a similar/common way. There would seem to be two parts to this kind of Sisyphanic exercise.

The group would need to communicate using a similar format. The medium constrains the message so there would be fewer ways to be different. More of the same.
The group would need to communicate using a common vocabulary.

This is a quick sketch at a common vocabulary for talking about interaction design on the web. It assumes several pieces are required to talk about most interactions.

You have an object,
A user or system triggers something,
The system has a response,
That response has a target, and
Transitions usually make it better.

So, for each of those five steps, I've collected a common vocabulary.

Common triggers for web interfaces

A trigger happens when a user or system does something that is noticed by another user or system. Web interfaces have a collection of common triggers.

On mouseover (and/or on focus)
On mouseout (and on blur)
On (left) click
After a time interval

Common triggers for form elements

On focus
On blur
On submit
On reset

Page level events (more rare)

On page load
On page unload (when we leave this page, but before we see the next one)

Special interaction events

On resize
On scroll
On mousedown or mouseup
On right click
On double click

Interface responses

When a trigger is, uh... triggered, the interface really only has a few responses.

Show something
Hide something
Change/update something
Go somewhere else (change the page)

Response targets

When the interface responds, it does so via an object on the page, its target. We have several possible targets.

An element (displays in the page)
An overlay (displays over the page)
A lightbox (displays over the page, modal)
A popup (displays in a new browser window)
An alert (alert display in browser, modal)

Transitions

If users need to know the interface has responded, it's often important to highlight interface response. (Norman and Cooper have frameworks for when and what you should communicate to users.)

On the web, a common set of transitions has emerged.

Fade in or fade out
Slide in or slide out
Enlarge (from something or nothing)
Shrink (to something to nothing)
Highlight
Play sound
Shake

It's often good to combine transitions. For example, if an autosave is successful, you might fade in a highlighted confirmatin message. Similarly, 37 Signals popularized the "Yellow Fade" technique where a highlighted confirmation message appears before the highlight fades away.

Using the vocabulary

Use is pretty easy. Annotate as usual.

Let's say you have a header. You would annotate interactions for each applicable trigger (much as you probably do already), but you make sure to use the above, approved list of words.

So, for our header, on mouseover change the header to a highlighted state. For our header (element), on mouseover (trigger) change (response) the header (response target) to a highlighted state.

So, there's no rocket science here. The benefit would be everyone communicates the same way about the same things. Not tested. The next bit is about a common format.

Agile + UX: six strategies for more agile user experience

Austin Govella — Wed, 07 May 2008 04:30:19 GMT

There's a secret lie lurking behind agile methods. 'Agile' suggests fast. At Comcast, we're using a scrum process that throws around terms like "team velocity". And the agile literature does promise better, faster. It's no wonder that when organizations hear this, all they hear is faster. Of course, the secret lie is that agile isn't necessarily faster. It's driving tenets are to help people stay happy and create better software. The namesake agility is meant to allow teams to change product direction every few weeks instead of every six months. How do you make these kinds of agile changes? You test: Build, push, evaluate, tweak (rebuild). Unfortunately, the iteration cycle, "agile", and phrases like "team velocity" were confused with "fast". The biggest problem with lots of user experience methods is that they're not necessarily fast. They're not necessarily slow, but they do take time. At Comcast, even though user experience work is seen as valuable and important, its also seen as a slow point in the process. How do you handle this? You have six options.

1. Synchronize UX with development

My previous post on parallel workstreams touches on this. You run a UX sprint ahead of the development sprint. You figure out what dev will work on next sprint, and you work on that stuff this sprint.

In the parallel workstreams post, I go over some of the problems and realities you see with this approach: parallel workstreams, more UX than fits in a dev sprint, etc. (Check out that post for more detail.)

2. Separate modeling from design

Design doesn't really take that long. Most of us are cranking on problems we've seen before and solving them in ways they've been solved. Most of the design is using documentation and discussion to -- virtually -- walk through the product and make sure it works the way users, developers, and the organization expect.

With a good team of smart, happy people (i.e. an agile team), the design is easy. Modeling -- not design -- is the part that requires thinking and synthesis and time. You need a good model for your users, for your business, and for your interface. Don't confuse models with requirements, because they're not the same. For Fancast, the user model includes information like people think of TV shows more than they think of episodes. (You're more likely to search for 'Seinfeld' than you are for 'soup Nazi'.) These kinds of models frame how the team thinks about how to solve its various problems. Models suggest requirements because they suggest how you should think about the problem. If you can do your modeling up front, then you don't have to do it during the sprints, you can spend your small time on the fast bit, the design.

3. Design literacy

If there's not enough of you to go around, but you still need going, then you need more you.

Every team has a certain design literacy, a certain level of experience and maturity designing stuff. (Jess McMullin covers this really well.) Essentially, user experience practitioners are really, really, design literate. If you don't know an answer, then you know a method or where to look to find it. The more your team knows about user experience and design, the less they need you. This is a good thing. Leave good books laying around. When you make a recommendation explain why. With a good team of smart, happy people (i.e. an agile team), they'll pick the basics up really quickly. After all, it's not rocket surgery. Once the rest of your team can handle most things by themselves, it's like there's more you, and you can focus your expertise on the more wicked problems.

4. Collaborative Design

Agile is all about build, push, evaluate, tweak. Oddly enough, design is all about build, push, evaluate, tweak, except we do it in our heads before we bother coding it.

Everyone digs this, so take advantage. There's no reason to do your virtual build, push, evaluate, tweak by yourself. In fact, it's better for the team's design literacy and easier to share your models if you don't. Get in the same room and sketch, point, talk, and iterate. By the time you're done with the conversation, every one has a good, consensual idea of what you're building. In the end, a consensual idea is why you document. If everyone leaves with the same idea in their heads, then the last reason you have for documenting is recording details that might fall out of people's heads. Things like how a list is ordered, or what happens if there's an error. As above, you can spend less time on basic documentation and focus on what documentation is good at: remembering things you won't.

5. Lower fidelity

Documentation is still a good thing, but the more details you have, the longer your document takes to produce. Wireframes are the best example of this. A well-annotated, high-fidelity wireframe for one page can take a day, easy.

If you need to spend less time, use fewer details. If you've collaborated on the design, and you've helped improve their design literacy, then your team won't need all the detail. Strip your documents down to the basics and only deliver what people need. Make your wireframes more like page description diagrams or block layouts.

6. Book your time

Agile developers don't really pretend to code faster. That's silly. But they're fanatical about estimating how long something will take and exactly how much time they have. They're clear about their limits.

In fact, that's a clear benefit of agile methods. The extreme focus on a small sprint's worth of work means its easier to estimate, track, and communicate changes to your timeline. If it's going to take you 10 hours to work on one feature, then be clear about that. Book your time the way the development team does. Use their systems and their language. Use story points, tickets, and time tracking. Only commit to what your estimates say you can commit to. If something starts to take longer, communicate the change in the timeline. The agile system manages this (by bumping lower-priority items off the sprint).

Become agile

Obviously, these six strategies are not mutually exclusive. In fact, they work best when pursued in parallel. The crazy thing is, in retrospect, they're kind of the obvious application of agile principles to user experience design. They don't necessarily make you work faster, as much as they let you work in a more agile way.

There's one more strategy for working better with agile development teams, and it involves reframing the way the product and development teams perceive product development: have agile become UX. But that kind of design mumbo-jumbo requires a separate post. Maybe later :-P

Agile + UX = idealized vs. current state

Austin Govella — Tue, 08 Apr 2008 16:03:00 GMT

Please listen to the attached soundtrack whilst reading the following.

Agile really likes to focus on iteration. For a lot of developers, this is code for biting off small, manageable, deliverable chunks. Small, manageable, deliverable chunks is not necessarily the same thing as iterating on a design.

They _can_ be the same, but they aren't _necessarily_ the same. Regardless, this means the current state of your product is not the same thing as the envisioned state. This is true for almost every product development process, but agile can make this more of an issue.

How iteration works in the agile process

One of agile's tenets is that you release small changes to a product frequently, instead of major releases less frequently. The agile sprint is a cycle as short as two weeks where the team is supposed to develop, test, and release a feature in its entirety.

Say you wanted to add forums to your site. By itself, this might take three weeks worth of work. A small, manageable two week task might be to add a way for users to register their email address. At the end of the sprint, the team would expect to release the next version of the product that includes user registration. On the next sprint, developers might release the back-end updates necessary to handle the forums, and two weeks after that, they might release the front-end interface that allows access and participation in the forums. During these three example sprints, everyone knows the ideal state: forums on the site. And each sprint moves you closer to this ideal state. However, iteration requires two corollary management tasks. First, you have to communicate the ideal state to the team. Everyone needs to have the same shared understanding. Second, you need to track the gap between the current design and the ideal design.

Communicating the ideal state

I'm totally thinking "this is why we crank out wireframes".

To clarify for any non-UX people reading this, drawing, annotating, reviewing, editing, reviewing, approving, communicating, and clarifying wireframes is not the sexy part of the job. Sure, some people really get off on that sort of thing, and I make a point to wear fishnets any time I open Visio, but most practitioners do wireframes because they have to so they can communicate the shared understanding of what the product is _supposed_ to be. Let me be clear. Deliverables are not teh sex. Teh sex is what _leads_ to the deliverable. (Someone -- who shall remain anonymous -- put it this way: "Toddlers are awesome. Poopy diapers suck. Wireframes are the poopy diaper that happens after your toddler has eaten a great meal.") Of course, this doesn't have to be a 500-page spec. Doesn't have to be wireframes. But it has to be something. Even a photo of a whiteboard session that everyone has access to can work. Whatever it is, it has to be something.

Minding the gap

You can't mind the gap unless you have two sides to point to. One side is the current version of your product, and the second side is the idealized version.

While your agile team is iterating on the current state and marching towards the ideal state, someone has to keep track of what has and hasn't been built. This seems silly. I imagine agilists saying that the smart, unfettered, goal-centered team members will manage the gap. Sure. I suppose they could. In my experience they don't. Nothing against _them_. I'm one of _them_. And even being heavily invested in "my baby", I'm not minding the gap. This ties into my post on parallel work streams where I mentioned the sprint support role that's emerged at Fancast. Everyone is busy doing something. Engineers are developing. IAs and designers are designing. Product's reviewing, tweaking, and iterating. It's really pretty awesome. But, if a feature is limited so that it will fit into the current sprint, all of a sudden you have two features. You have the edited version being built, and you have the ideal state you _hope_ is coming. If the functionality is different, you need two shared understandings: one for now, and one for later. Now stay with me. We're imagining rolling sprints. This sprint, a small portion of a feature, an edited version of the feature is built. Next sprint, you build the next version. Or maybe you don't. Maybe the iteration isn't as important as launching another small feature. Agile lets you turn on a dime, and you've just turned. The ideal state falls into that ghetto, the sprint backlog. Who remembers that ideal state? The team's busy with something else now. And what if you've got really lean documentation? There's a gap in organizational memory. And it's not minded.

Dirty laundry. Look away. Do not read any further

Here's a dirty little secret from where I work.

Let me set the scene for you. Engineers? Rock stars. Seriously. In the IA group we have engineer love-ins where we talk about the engineer we're crushing on this week. The product team? Fucking brilliant. Seriously. They just get it. Everything. And the IA team? If I may say so myself: fucking awesome. (And, no, I am -- by far -- *not* the only IA on the team. But, for the record, the _entire_ IA team at Comcast Interactive seriously kick ass.) So here's the dirty secret. Back in September we wireframed a new version of the preferences section. In October we "iterated" on the first wireframes, which really meant they were totally redone. Each time, they were bumped off the next sprint by other things. We're redoing the wireframes a third time right now. It's not the people who are the problem. We've got good people. And it's not the project. The prefs aren't particularly sexy or ground-breaking. We just don't mind our gaps very well. Or at all, really. But if you're doing agile, you have to mind your gaps, or you'll forget where you're going. Heck, if you're moving really fast, you'll forget what's actually made it on to the site.

We tried to warn you: how organizations are architected to fail

Austin Govella — Thu, 20 Mar 2008 15:00:34 GMT

I’m in the midst of editing a series of articles on Failure for Boxes and Arrows. The series is based presentation organized by Christian Crumlish last year at the IA Summit in Las Vegas.

Boxes and Arrows just published part one of Peter Jones’s article about the organizational architecture of failure: We tried to warn you. It’s a really smart, really excellent look at how organizational “failures” reveal themselves as project failures.

It’s a coffee break read: grab your coffee, print it out, and read it.

I think it’s especially interesting because I.A. is an alignment discipline, helping align business, users, and technology. Its the failure of one or all of these to align that causes the kinds of failures Jones is writing about.

(Peter Jones blogs over at Design Dialogues and works at Redesign Research.)

Designing with patterns: Lessons from Yahoo! and Comcast

Austin Govella — Mon, 17 Mar 2008 11:00:00 GMT

Christian Crumlish and I will share design pattern lessons learned at this year's IA Summit in Miami. Christian will talk about his experience with Yahoo's design pattern library while I'll share what we've done at Comcast Interactive Media.

Presentation info

Designing with patterns in the real world: Lessons from Yahoo! and Comcast

Monday, April 14 2008, 11:45 - 12:30PM

Presentation description

Can you streamline web design and development with design patterns? Really? How?
Do patterns help or hinder agile user-centered design?
Do design patterns stifle innovation?

We’ll share what we’ve learned about bootstrapping pattern libraries from scratch and how to “extract” patterns from existing products. We’ll share stories (er, I mean real-world case studies) to illustrate ways pattern libraries can both aid and stifle innovation, how they help solve real-world web design problems, and how they support rapid production of common IA deliverables. We’ll bask in the glow of the “magic triangle” of patterns + code modules + wireframe templates that enable rapid prototyping and agile development, and then cower in the miserly shadow of the “iron triangle” of fast, cheap, or good. How to structure and maintain a pattern library? Check. We’ve got you covered. How do you trick… er… get people to adopt patterns and help improve them? What tools help you do this? Are wikis the answer? How far can you get with an open-source CMS, a boatload of other people’s mistakes, spit, baling wire, and wing and a prayer? To find out, come to Austin and Christian’s presentation where we’ll share what we’ve learned, what works, and what we will never ever do again at Comcast and Yahoo!

More information

You can find more information about the 2008 IA Summit at the conference website.

Lazy Site Map Generator

Austin Govella — Sun, 10 Feb 2008 05:04:52 GMT

Jason Pearce has put together a Lazy Site Map Generator that takes a site architecture in Excel, converts it into a Visio-friendly format, and then creates your sitemap in Visio.

I haven’t tried it, but it looks very useful.

Fancast officially launches

Austin Govella — Thu, 10 Jan 2008 16:11:00 GMT

Tuesday at CES, Comcast officially launched Fancast, a next-generation, personalized, cross-channel entertainment website.

So far, work on the project has run everywhere from ecstatic to calamitous, but it's definitely been one of the most interesting sites I've worked on.

But Wired rewards all the sweat and tears in one sentence: "Fancast turns out to be surprisingly well-designed -- and useful enough that the biggest complaint is likely to be, what took so long?"

The best books on innovation

Austin Govella — Mon, 07 Jan 2008 05:00:00 GMT

Over at Noise Between Stations, Victor Lombardi asks "What’s your favorite innovation book?"

I recommended Marty Neumeier’s latest book, Zag, one of my recent favorites. Not only is it a great discussion of experience-driven innovation, but it’s like business analysis 101 in book form, and rounds everything out with the "Only Statement", a new method and deliverable for aligning your team and keeping everyone focused on what’s important.

There are some great answer’s to Victor’s survey with some excellent and less than obvious recommendations. If you’re looking to hone your design thinking skills and boost innovation in your organization, head over there and check out the comments.

How to not boil lobsters: strategy keeps projects on track

Austin Govella — Sat, 15 Sep 2007 19:06:00 GMT

Joel Spolsky writes about drastically realigning the design on the new website. "Drastically realigning" is corporate-speak for scrapping the whole thing and starting over.

Joel's post reminds me of a story I saw Douglas Adams tell at a lecture in the early 90s:

Lobster think

Apparently, throwing a lobster into a vat of boiling water is a little cruel. You throw them in, they writhe about, die in agony without so much as a smidgeon of dignity.

On the other hand, if you put a lobster into a pot of cold water that's over the fire, the lobster doesn't mind. When the water gets warmer, the lobster thinks: "It's only one degree warmer. The previous temperature was okay, so one degree warmer is okay, too."

Then the water gets warmer, and the lobster thinks again: "It's only one degree warmer. The previous temperature was okay, so one degree warmer is okay, too."

This goes on and on until, finally, the water is boiling, and the lobster sits there, looking very dignified, obviously very deep in lobster thought.

Joel and his design firm were boiling a lobster instead of designing a website. How do you stop yourself from making the same mistake?

Lobster strategy

Basic lobster strategy goes like this: if you do not want to be boiled, do not get into a pot.

This sounds very silly, but we paid a very senior lobster consultant (with suspicious burn marks) a LOT of money to tell us this. He told us in person, put it in a PowerPoint, and made a nice, BIG, pretty poster with arrows and bars and iconographic pictures of lobsters and pots and grim reapers.

Obviously, Joel and his design team know better than to boil a lobster. They're trying to design a website, for crissakes! And in the original meeting, I bet everyone at the table agreed they would not put any lobsters in any pots.

So what happened? Joel sums it up:

Links had sprouted up all over the place, making it hard to tell where to go next and where you've already been. Most of the elegant whitespace in the original design was lost when we went from the original 1024 pixel wide design to an 800 pixel design.

Joel Spolsky, "There's no place like 127.0.0.1", Joel on Software, September 11, 2007.

In essence, they forgot their rule about lobsters and pots. Someone had a change that brought in a lobster. And then someone else had a change that introduced a pot. And then somehow they added some water. And then somehow the lobster ended up in the pot...

If everyone knows the strategy for your project specifically states no lobsters in no pots, ever, then when someone else walks in with a lobster, everyone at the table can say "no".

The worst part about Joel's story, somewhere along the way, the smart people at the table noticed the lobster, and the pot, and the water, and either they said nothing, or they said something, but not in a way anyone understood.

Joel's absolutely right that good design is a process of learning what's wrong, and sometimes you learn later, rather than sooner.

The take away is that you need to be comfortable being wrong. If you think you see a lobster, stand on the conference table and scream out loud: THAT IS A LOBSTER!

Maybe it's not a lobster. Maybe it's a polar bear and everyone will laugh at you. But if it is a lobster, and another smart person at the table agrees with you...

I look forward to a day where lobsters can live long, fulfilling lives without the fear of being boiled alive.

Personal information spaces, diagram by Dan Brown

Austin Govella — Tue, 22 Feb 2005 17:53:00 GMT

Personal info space diagram analagous to commmunication/interaction model: the users mental model (personal information space) interacts via an interface (the task) with external actors (the external information supply):

http://www.greenonions.com/index.php?p=80