Design Thinking from Thinking and Making

Random collected thoughts on design

Austin Govella — Fri, 27 Mar 2009 05:14:18 GMT

Collecting a couple of random thoughts where I can find them again. Considering this a crazy check as well: chime in if you think any of this is crazy.

In design, we model four constructs:

Actors (direct and indirect stakeholders)
Interfaces
Interactions
Systems

Actors use an interface to engage in an interaction bound by a system.

We place these constructs in four contexts:

Mental (user's mind)
Spatial (place, layout)
Temporal (sequence, prior- and next-steps)
Social (community)

Our methods help us accomplish one (or several) of three activities:

Generate data (discover)
Analyze (model)
Communicate (validate)

A 21st century primer

Austin Govella — Wed, 18 Feb 2009 15:22:03 GMT

Four pieces of required reading (and watching) have popped up over the past couple of weeks. They explore how society and cities will change after the crash and how design must also change.

Umair Haque delivers a fantastic presentation on Constructive Capitalism where he accomplishes two things. First, he synthesizes a pretty stunning critique of 20th century capitalism , why it doesn't work, and why it inevitably leads to the types of crashes we're seeing in societies today. It's material you've heard or read many times, but he provides a synthesis that ties everything together into a nice, tidy, frame that shows how 20th century capitalism actually destroys value. There's an amazing conclusion:

Strategy is a commodity. We have to reinvent these economics before we can reinvent this strategy.

Umair Haque from "Constructive Capitalism", 2009.

He goes on to reinvent those economics and describe a 21st century capitalism that pursues five different values:

Tomorrow is today
Connections, not transactions
People, not product
Creativity, not productivity
Outcomes, not incomes

Again, you've heard this before, but Haque ties it together into one nice frame.

Umair Haque @ Daytona Sessions vol. 2 - Constructive Capitalism on Vimeo. In a similar vein, Richard Florida writes a great article for The Atlantic: "How the Crash Will Reshape America". Florida describes how the crash and a new, rising economy brings along a new geography for the U.S. He explains of how and why our key regions and cities will change. Florida's article and Haque's presentation are intriguing enough on their own, but a couple of other interesting bits have popped up recently. Adam Greenfield delivered the table of contents for his new book as a Valentine. Far from limiting itself to a grocery list of material covered in the book, Greenfield's table of contents reads more like an overview for how cities will emerge. Barely a week prior, Mike Kuniavsky offered the table of contents for his own book. Though more of an outline, it reads like a checklist of how objects and services can and should be created. Haque reveals the high-level economic and social change, Florida shows how these changes will drive the shape of cities, Greenfield talks about how the cities function, and Kuniavsky outlines how one builds devices for this new geography. They cover both the new urban centers where design will flourish, as well as the new ghettos where design must flourish. Taken together, they're like a primer for design in the 21st century.

Methods for our madness

Austin Govella — Wed, 29 Oct 2008 19:00:04 GMT

I've always loved the phrase "supposed former infatuation junkie" since it seems to encapsulate my dirty little love of "process". I'm a process junkie. You have a process, I want to know about it. And of course, as one of those little IA heathens, when it gets cold and dark on snowy nights, I can't help myself but start organizing and classifying all those processes and their attendant design methods into some kind of unified theory of design. It's a sickness, and a design, and damn interesting, and this is something I've discovered:

All design methods apply a limited set of problem solving methods in a design context. Design is problem solving. That's pretty obvious and not the point. The point is that there are seven basic problem solving activities.

Generate
Disambiguate
Deconstruct
Synthesis
Affinity
Priority
Context

Of course, I've been classifying methods with these "seven habits of highly effective methods," but that kind of intellectual onanism only gets you so far. The entire point is that if you know where you are in the problem-solving "cycle", and you know what kind of problem you're solving, choosing the proper kind of method becomes more science than art, more conscious than unconscious.

Dolly Parton is playing just now on iTunes. As you read, I recommend you cue up some readin' music.

Generate

This is the first thing any one must do when solving a problem: generate a solution. While the entire design process might be seen as _generative_, that's not what I'm talking about here.

Generate refers to the class of activities where you generate several somethings. The most basic form of generation is the brainstorm where you literally generate what the fuck ever. Generation doesn't necessarily require you explicitly imagine more than one thing. However, anytime you recommend a change to an existing idea, it's because in your little designer head, you've generated an alternative model you think might work better. Vaguely, this may be like grabbing your drink off the bar, taking a sip, and then turning to scan the establishment for potential seducees.

Difference/Disambiguate

I wanted to call this chunk disambiguate because that's just so dead-sexy. However, the purpose of this chunk of methods is to understand what makes something something. You _disambiguate_ the one from the others you've generated.

A basic form of disambiguation might be that annoying part of the content inventory when you write a little description for every page in the site. I can't imagine disambiguation being anything more than comparing and contrasting the various items you've generated. You define what constitutes their thingness, and what doesn't. In the bar of design thinking, you're noting blondes, brunettes, talls, shorts, crazies, meeks, and exes.

Deconstruct

In my honest opinion as a child of the swingin' 20s, there is no technique more valuable to the information architect than to tear things apart and see what they're made of. This includes assumptions, interfaces, goals, orders, workflows, puppies, designs, but never kittens.

When you take the BRD and rip out all of the features and intuit the business and user needs, you're deconstructing. Regardless of how much you may drink, this is never recommended in a bar.

Synthesis

Of course, once you've torn things apart, you want to reassemble them into something better. This is synthesis, taking several pieces and making one whole. When you take disparate marketing demographics and imagine your persona, Sarah Carlson, the leggy brunette who's just your height, that is synthesis. Of course, this person is rarely ever in the bar, but that's ok. Synthesis creates the possible (or impossible). If it created the existing, then it wouldn't really be synthesis.

Affinity

IAs love affinity. Except with interaction designers.

A card sort is an exercise in determining affinity, the chat up of design. When grouping like with like, make sure to give them "the eyes."

Priority

Priority is the haven of the intellectual lazy and those who would settle with good enough. Instead of accomplishing that perfect world where everything synchs together in sweet, sweet harmony, you satisfice and choose what is more and less important. Satisfice for satisfaction.

Any kind of rating is an exercise in priority. Selecting a personas primary goals is an exercise in priority.

Context

A lot of a thing's thingness examines those intrinsic things that really thingify a thing. Context examines a thing next to other things.

We like to contextualize in different spheres: mental (user's mind), spatial (place, layout), temporal (sequence, prior- and next-steps), and social (community). Scenarios, use cases, flows, wireframes, site maps contextualize. Tanya Donnelly is singing now. How she isn't queen of the world... well, it just boggles. Any ideas on why this is? Or what about that break down? How you like that list? Missing an activity? This is a public call for an intergalactic crazy check. Sanitize me!

Designing versus doing

Austin Govella — Tue, 14 Oct 2008 16:12:27 GMT

From the Managing as designing videos:

One wonders, why design at all? Why not just do the thing? And the answer is because it's bigger than you can do in one fell swoop. It either involves more people or it involves you for a longer period of time than you can keep it clearly in your head.
And so you design. You do drawings or schematics, you write about it. You do some intermediate step between your idea and your realization of your idea.
Improvisation is quite the opposite. It's where you're able to pull it off right now in the moment and do it now. And it requires a different attitude and set of tools, perhaps, than designing does.
And it's another one of these dimensions where I think extraordinary leaders and managers are going to be capable of a balance. Of knowing when the organization should be improvising, of when they as a senior manager should be improvising and when a design attitude is called for.

Fred Collopy

(Via Victor Lombardi)

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.)

Weekly usability tests, Nielsen talks about Tivo

Austin Govella — Wed, 30 Jul 2008 03:05:38 GMT

Jakob Nielsen's latest Alertbox shares how Tivo did 12 usability tests in 12 weeks and offers some tips and guidelines for doing the same at your organization. I've actually been hearing about this a lot lately: design teams running weekly or bi-weekly usability tests. It'd be nice to have more companies share their experiences, the how and why and such. At CIM we did something similar in concert with a project using the scrum process. While this is all cool, the article summary really stuck in my craw: "frequent and regular testing keeps the design usability focused". Why would you want to keep your design usability focused? Nielsen probably doesn't mean only focused on usability, but it sure comes off that way. It just feels so 90s. If we all know the design should be focused on the experience what kind of frequent tests can you run to keep your design experience focused? Well? If you were running some kind of bi-weekly validation to keep your team experience focused, what would it look like? Hint: There's a comment box right down... there. Fess up.

Design research reaps $1.6M in organizational change

Austin Govella — Fri, 20 Jun 2008 18:21:28 GMT

Strategy+Business has a case study illustrating the impact of evidence- and research-based change.

In the case study, employee morale dropped, bringing gloom and doom. In response, management thought to boost salaries.

Unfortunately, after interviewing employees, Core Practice Partners discovered employees were happy with their current pay. Their unhappiness rose from unpredictable overtime schedules and a lack of close communication with management.

Employees felt management didn't care.

The solution? First, change shift schedules so they were predictable for employees and still gave management the flexibility to adapt production capacity. Second, get management on the floor to talk with employees on a day-to-day basis.

Compared to raising salaries, those solutions are cheap.

The obvious answer is not necessarily right. In this example, the company saved tons of money because they didn't need to raise salaries. They earned other benefits as well.

"...the manufacturing firm realized more than US$1.6 million in combined cost savings and new profit during this process, with $675,000 directly related to morale improvements, including lower training and recruiting expenses due to a decline in worker turnover and gains in productivity."

John Frehse, "It's not about the money", Strategy+Business, June 10, 2008.

On the web, we have our own "boost salaries". Common knee-jerk responses include add more ads, add more features, change the price, and change the visual design.

I bet nine times out of ten, those four options are the expensive, wrong option. But they're well-accepted and safe.

To succeed against the well-accepted and safe, you need trust so you can do the research and implement the "scary", untested new idea.

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!

Fantastic case study on ATM design

Austin Govella — Thu, 05 Jun 2008 17:30:09 GMT

Michael Beavers has started a new site called Physical Interface "about the messy middle between computer-human interaction, physical products, urban design, architecture, urban planning—and a great user experience".

The first article, by Holger Struppek, is a fantastic case study on the new interface design for Wells Fargo ATMs. Holger reveals some of the behind-closed-door design thinking and constraints that drove the new design.

It's a really interesting insight into how other teams and organizations work. Go read it!

(As a side note, Physical Interface runs on the wonderful PublicSquare content-management system developed for Boxes and Arrows. That's the same system I'm using to power Thinking and Making. It's probably the best CMS I've ever used.)

David Armano interviews Bruce Nussbaum

Austin Govella — Mon, 02 Jun 2008 04:06:00 GMT

Livia Labate tweeted this great interview. David Armano of Critical Mass catches Business Week's Bruce Nussbaum for a great, relaxed sit-down. Sounds more like a conversation over drinks than an interview. It's fantastic.

Broadcast by Ustream.TV

72 questions to ask on your first day

Austin Govella — Mon, 07 Apr 2008 04:00:00 GMT

Well, maybe not on your first day, but during your first few?

When I joined Comcast Interactive Media, my supervisor, Livia Labate, handed me a copy of Michael Watkins's job transition primer, The First 90 Days.

It's all about landing in your new position, figuring out the landscape, and then kicking ass. Intended for "leaders", it's actually good for anyone moving into any new position. The title refers to your transition period, and the book is about coming out of those 90 days with clear wins, the support of your teammates, and shared vision for getting things done. Recommended reading.

While I was going through the book, I put together a list of questions I wanted to answer. In a more generalized form, they're a good set of questions for understanding the ins and outs of any organization.

Questions about my performance evaluation

What are my specific duties within the team?
How am I evaluated? (What is success? What is failure?)
What are your goals for me?
What are the organization’s goals for me?
What can I do to cement credibility with the organization and other business units?

Questions about your supervisor’s goals

What are your supervisor’s goals for the IA team?
What are your supervisor’s goals for the organization?
What are your supervisor’s goals for you?

Cultural Norms (What’s most important? What’s sexiest?)

The timeline, the features, quality (product or experience), or the budget?
Being first to market or well-architected?
Having comparable products or innovative products?
Being on message or being visually stunning?
Client-side development, server-side development, design, marketing?
The customers, the products, the technology?

What’s the business structure?

What are the business units?
Are there any other fiefdoms?
Who are the key visionaries?
Who are the go/no-go gatekeepers?
Who are the greatest champions?
Who are the most-feared Black Knights?
Who are their influencers?
What are the key revenue streams?
How is your supervisor evaluated?
How is your supervisor’s boss evaluated?
How is the organization evaluated?
Who is your supervisor’s greatest Champion?
Who is your supervisor’s most-feared Black Knight?

What’s the story?

What’s the vision?
What’s the strategy? (compete on quality, not price?)
Are the vision and strategy different from the past?
Are they expected to change for the future? (We’re realigning now. To what?)
How fast is the organization growing? (Hiring versus attrition)
How fast is the organization’s market share growing? (overall and in specific markets)
How is the customer base growing?
How is the organization’s revenue growing?
Who are the organization’s top competitors?
What are their advantages over us?
What are their comparative weaknesses?
What is the organization’s strategic advantage?
What is the organization’s strategic weakness?
Are these strengths and weaknesses shifting? (How does the realignment affect them?)
Who are the future competitors?
How do we expect the market environment to change?
Are there other markets that will become a factor for us? (Opening, closing, merging, fracturing, etc.)
What capabilities, products, or positioning is the organization missing that prevents it from being prepared for these changes?
What’s the organization’s biggest challenge for getting to where it wants to be?
How did the organization’s story arrive at this challenge?
What was the impetus for the realignment?
How has the realignment affected morale?
Has it affected projects in a positive or negative manner?
Has the realignment affected products to make them better or worse?
How has it affected custmer service quaity?
During the realignment, were there any early wins or losses for any of the fiefdoms, champions, or Black Knights?
What are three cultural attributes?
What other cultural strengths should be preserved?
Where is the invisible elephant?
How can we fill that hole?
How can your department help the organization get there?
What are the reasons customers usually leave?
What’s the most common reason for joining?

How do we work?

What’s the real process (not PMI phases)?
What are the inputs for each project?
What are the usual timelines?
Who’s involved (beyond the project teams)?
How do projects come about?
How often are they driven by tech or engineering as compared to being service driven by CRM, sales, and marketing?
What is the organization’s batting average for success and failure?
Are there any benchmarks the organization uses?
Are there any common stories attributed to successes? For failures?

Who should I talk to?

Who’s done contract work for us?
Which media and technology analysts are best to watch?
Who’s been with the company forever?

Way back in the 90s, I cribbed this great list of questions from Vivid design that covered all the basic requirements gathering one needed when designing a website. I've long lost them. If anyone has those, I'd love to see them again. Even if only for the nostalgia.

For that matter, if you have any suggestions for additions, changes, or removals to the list above, let me know.

Unique visitors is a dumb metric

Austin Govella — Mon, 24 Mar 2008 10:13:00 GMT

Lots of organizations try to measure success by measuring unique visitors. Typically, these groups have some sort of advertising-based business strategy where they believe the more eyeballs they reach, the better they’re doing.

But that’s not true.

For sites supported by ad revenue, unique visitors tell you how big your check will be that month. If every visitor is worth $1 in ad revenue, and you have 1 million visitors this month, then your check will be $1 million dollars.

What’s missing, what’s not being measured is whether or not your business model is successful. “But I have a million dollars”, you say. But having a million dollars isn’t your business model.

Let’s say this month, you have 1 million visitors, they all earn you $1 in ad revenue, and you get your check for $1 million dollars. And let’s say your site sucks, so none of them came back, and they told their friends to never go. Next month you have no visitors.

Each visitor still earns $1. And you go to the bank to deposit your check for $0.

What’s missing, what’s not being measured is the behavior your organization relies on to make money. There’s something all those unique visitors do, and it's the doing that's necessary for the success of your business.

In marketing terms, unique visitors measures how many potential customers you have acquired. However, in order to make money, you have to convert those potential customers into actual customers.

Broad metrics like unique visitors and total page views give you broad aggregate data that’s just about useless. What you really want is a behavior-based metric that measures the behaviors that earn you money.

A lot of sites driven by ad revenue need the same behavior in order to be successful. A user learns about the site, they visit the site, and then they return to the site again and again. The visitor's return visits are what really drive ad revenue. Instead of measuring unique visitors, a better measure of your site’s success is return visitors.

Performance metrics should always measure the behaviors your organization relies on to survive. Your metrics should always be behavior-based. Aggregate metrics like unique visitors and total page views don't tell you much of anything.

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.)

“...quite delighted by small gorillas...”

Austin Govella — Mon, 17 Mar 2008 15:09:03 GMT

About a year ago, violin virtuoso, Joshua Bell, played the street musician, occupied a Washington, D.C. subway station, and gave brilliant performances of classical music.

The Washington Post asked about the "moral mathematics of the moment"?

Each passerby had a quick choice to make, one familiar to commuters in any urban area where the occasional street performer is part of the cityscape: Do you stop and listen? Do you hurry past with a blend of guilt and irritation, aware of your cupidity but annoyed by the unbidden demand on your time and your wallet? Do you throw in a buck, just to be polite? Does your decision change if he's really bad? What if he's really good? Do you have time for beauty? Shouldn't you?

Gene Weingarten, "Pearls before breakfast", The Washington Post, April 7, 2007. Everyone seemed to ask or answer the same question: why didn't anyone notice the virtuoso? The Washington Post nails the prevalent assumption: "He is the one who is real. They are the ghosts." Art has been deified so that we expect the entire world to stop and listen. I'm not sure that's the purpose of a street musician. Seems like they're only supposed to make our time more pleasant.

Design, Art, and Performance

We think because "Design" has a significant impact, it should receive a significant response. People should notice. But that's not the case. And there's no logical reason why anyone should.

A photo from Alexis Lloyd's 'Concrete Jungle' street art project.

Alexis Lloyd glues miniature animals in odd places around the city. Anne Galloway calls Lloyd's work a street art installation. And then she describes it as interaction design:

First, unlike most work in [interaction design], it doesn't cater just to the technological elite. In fact, I imagine all sorts of gadget-less people quite delighted by small gorillas swinging from fences, and rhinos storming over parking meters. Secondly, it does not require any direct interaction. While walking down a busy urban street, to simply catch a glimpse of a tiny lion stalking a tiny herd of antelope is enough to change one's frame of mind without demanding immediate action.

Anne Galloway, "Reimagining the everyday", Purse Lip Square Jaw, March 13, 2008. The real question about Joshua Bell's performance, or any performance, isn't about whether anyone notices. The real question is whether anyone's day is better. That's the first question: Are you leaving people better off than you found them? The next question: does your audience want to notice? There are two take-aways. First, anything you design should be as unobtrusive as possible, unless your audience wants it to be. Second, next time you whinge about business or development not "noticing" the experience, stop. Why should they? That's your job. They care about something else. Do your job, and make their job easier. Always leave people better off than you found them.

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.

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.