Design Thinking from Thinking and Making

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.