This has generated a trend toward quantitative and statistical approaches to design.  In Google’s school of thought, with modern web technologies almost anything can be built and fielded so quickly that the cheapest and best way to design is to brainstorm, build, put it in front of the world, and see what happens.  If your statistics improve, great, do more; if you degraded performance, roll back and try again. 

Almost inevitably, a corresponding backlash developed against this view.  The “soft” camp holds that designers need to be free to innovate without restriction, letting intuition drive solutions.  The debate really got fun when Doug Bowman, a top Google visual designer, quite publicly left Google last year.  Both camps dug in, and in today’s overly polarized culture, started hurling mud at each other.

To me, the whole thing got framed like so many other arguments do today, as strictly as a black and white issue: design “versus” analytics.  In fact, it is kind of tempting to think one is right, and the other is wrong—especially when the debate gets framed as Google versus Apple and fanaticism sets in. 

But like so many other false choices, I think it’s better to look more deeply and recognize when a statistical approach is appropriate, and when it is not. 

So when are statistics useful for design?

Businessweek recently published a great article about the design activities and rationale behind Google and their 2010 homepage redesign.  The broad arc of the effort that is traced in the article echoes the Google philosophy: get a bunch of super-smart people in a room, brainstorm lots of solutions, figure out which will work with the architecture, implement, and optimize with large scale testing driven by statistical performance measures.

Sounds great, worked great.  Google rolls on.  But let’s look a bit closer at the design circumstances that made Google’s application of statistics work. 

1.      Easily obtained performance metrics clearly, unambiguously and quickly define the “goodness” of the chosen solution

This is a simple statement but it has profound design implications.  Google’s metrics are clear: speed, number of clicks per search, and so forth.  They can be measured straightforwardly with the tools Google has.  And they can be measured relatively quickly—results of a design change can be known within days, even hours, of making the adjustment.

2.      Many of the changes Google tests are between a small number of similar, low-risk design options

The work practice that search supports is clear, and all of the options Google chooses to test support that practice.  So, small changes, like the color of the search button, the pixel width of the search box, and what to call “similar” results, can be compared relatively evenly and won’t break the user.  So you’re comparing apples and apples. These small changes are ideal to test statistically.

3.      The design options are cheap and fast to generate and field

In the web world, iterative cycles can be quickly made—even iterative cycles on the “real product.” Of course, this is the real magic of the statistical approach, but it is a significant luxury that is not enjoyed by all products and services in the world.

For me, the thing that gets lost in the debate about design “versus” analytics is how relatively rare this combination of circumstances is.  Surely if all three are true, the application of Google’s design rationale is hard to argue with.  But aside from a subset of the web world, very few design domains have this triple luxury.

As an example, I’ve been working a lot lately with automotive clients.  In the car industry, market share and margin are king.  But there are literally millions of design choices that impact those two big “metrics.”  Aesthetics play a big part, and the purchaser benefits of the look of a car are not even well understood, let alone objectively measurable.  Product cycles take years, so designers can’t just make a change and see what happens in a couple of hours.  Designers can’t deploy a prototype to millions of drivers instantaneously.  And so on. 

It’s clear other physical products are similar, but so are some software packages, and even web applications.  Think about CRM or ERP—some software, even if it’s web based, takes a long time to roll out, and has lots of work practice redesign issues surrounding it.  Again, none of the circumstances I outlined above fit.

Design choices in these domains is not just apples and apples.  Or Apples and apples.  We need to think different.  Statistics alone aren’t useful, and we need to make use of other design methods that give us other sorts of data from which to design, things like values, culture and behaviors.

So what’s my take-away from all of this?  For me, it’s not a question of either design or analytics.  It’s in having the maturity of design thinking to choose when a particular method is useful and when it is not.

What I saw was a community that is continuing to learn and grow. Agile methods were pioneered by developers, for developers, and tended to be restricted to the perspective of developers. But, of course, creating products and systems is not just about cutting code—there are many other tasks and skills that have to be coordinated. Agile 2010 was, in large part, about how to bring those tasks and skills under the umbrella of the Agile approach.

This is causing a little heartburn among the old-time developers. Bob Martin, “Uncle Bob” to many, one of the initiators of the Agile approach, complained that programming and programming issues are becoming a minority of the sessions at the conference. A lot of people would like to see the Agile community return to its code-cowboy roots.

But I’d say it’s not that the coding contingent has shrunk at all—it’s that the conference has grown around them. As the conference addresses more and more of the overall problem of delivering working systems, more and more roles and issues are being addressed. And overall that’s a good thing.

At this conference, for the first time, the need for a “concepting” phase seems to have become generally accepted, and people understand that this is separate from a “sprint 0”. Dave Thomas, in his keynote, called it a “sprint 0”—but then added that it might well take several sprints’ worth of time. And he recommended iteration of the concept with users—he mentioned 6 iterations of the concept and 3 iterations of detail, if my notes are right—before Agile development starts. (I think he overstates the case, at least for most projects. See my monograph for a process structure that can get this feedback more quickly.)

Dave also discussed the need for designers to be involved in creating the product backlog—because the user stories represent a design that had to be envisioned as a coherent whole. See what I mean about Agile growing up?

Gerard Meszaros added detail to this high-level claim in his very good talk, From Concept to Product Backlog—What Happens Before Iteration 0? (PDF). Gerard laid out the tasks that really need to be done between developing the product concept and writing user stories. (Including prototyping the concept with users! Yes!) One diagram of his is particularly useful—it’s head-slappingly obvious once you’ve seen it, but not something that has been much discussed at this conference before.

Of course, I expect the next response will be for Agilistas to take all those activities and start working on ways to make them smaller and faster, and make them happen closer to the time when their results are used. It’s a conversation I look forward to.

Our own field of user-centered design is coming into its own at this conference as well. A few people—not me!—are talking about how to gather data, how to do rapid prototyping, and how to guide development from user data. Contextual Inquiry was mentioned several times as a standard research technique useful in an Agile project.

There’s beginning to be an understanding of why the user experience has to be designed as a whole. Gerard talked about “story blinders”—how Agile can lead to limiting your perspective to a single story at a time—and how that can lead to a disconnected user experience as well as to an incoherent architecture. In the session, Distributed and Automated Testing Usability Testing of Low-Fidelity Prototypes, the presenters discussed many of the same issues and did a very nice summary of the value of low-fidelity prototypes in an Agile context (as well as showing a potentially useful tool for distributed testing). Making Usability Testing Agile offered some practical experience of a UX team integrating with Agile development.

Oh, and my own session? I used a board game of my own design to show developers and UX designers how to work together within Agile sprints, getting the design done just in time for developers to pick up and work on. The session went really well, and we had good discussions after the game about how the continuous back-and-forth between UX and development led to shared goals and shared success, and how the flow of user stories became the kind of lean development that the Kanban folks are looking for.

Finally I’ll leave you with what was maybe the most profound insight of the conference, offered at the session Product Management, Agile, & Customer Development:

Why do most products fail?

Lack of customers.

Hmmm.

“CI can only work in the United States”, they said. “You Americans tell strangers on an airplane your life story. We aren’t like that.” And—as they pointed out—they were from former Communist bloc countries like the Czech Republic, Poland, Hungary, and Romania.

“We can’t ask a customer to show us what they do and explain why they do it; that’s unacceptable. We have history that works against being comfortable asking and answering in such a way.” (In fact, only one person felt comfortable speaking up on behalf of several class members who were silently thinking this but didn’t want to say it aloud—you know who you are—and thank you again for speaking up!)

Of course they had a valid point about their countries’ culture. So what to do? Decide we should forget about CI in their countries? What about the other nations that have cultural norms seemingly at odds with CI? People are using CD and CI in companies throughout the world; we meet non-Americans all the time who introduce themselves and share stories about how they use the techniques. How are they are able to do it?

I think the answer is that we need to understand the purpose of a CI interview. Its goal is to gather user data, not opinions—to be grounded in what really happens, not what is believed to happen. And this also answers the question Karen raised in her recent post, “How can we innovate by talking to users?” Because we aren’t asking them what they want.

Remember the role the interviewer takes—it’s not that of a traditional interviewer or “inquisitor”. Instead it’s the role of the humble apprentice who is there to learn from the customer who is the master of their work. We don’t ask open-ended questions or questions unrelated to the work—questions like that could be experienced as an inquisition. When you ask questions with the attitude of a humble apprentice learning from the master the customer will respond positively, regardless of what country you are in. From here you can adjust the interview to fit your particular culture.

Here’s one thought about how my clients in Central Eastern Europe might adjust their interview approach. In the U.S. we advise interviewers to look for ways to interact with the user early in the interview by asking questions about what you’re seeing and hearing and uncovering the user’s reasons and intents. By doing this early we’re signaling to the user from the start that this isn’t going to be a traditional question-and-answer interview.

But in some cultures it might work best to start with a lot of looking and listening, and not so much interaction. Then ask focused questions about exactly what the user is doing. Finally, move into a freer interaction after the user has gotten used to the idea of being watched. The cautionary note is that it is easy to stay in the observer only mode; you have to monitor yourself so you do interact with the user.

Thinking about how to best apply CI techniques and fine tuning your approach should happen anywhere in world—including the States. Here at InContext we recognize that you adjust the method and its techniques to work for you. Heck, I used to be an InContext client and I know that’s what I did. But do it consciously, being mindful of the compromises you are making and being sure you are not compromising to the point of making the data you collect unreliable.

What do you think? What are you doing to make Contextual Inquiry interviews work in your culture?

New Publication: Agile User-Centered Design

UX designers have found Agile methods to be a mixed blessing. On the one hand Agile methods define a role for the customer voice on the team—so they have a natural user focus built in. But the new methods disrupt existing relationships and ways of working, they introduce a new culture (which takes some getting used to), and their idea of user involvement isn’t exactly what user-centered design people expect.

In this newly published monograph (or lecture, as the publisher calls it), I bring together our latest thinking for how Agile development and user-centered design should be combined. I discuss the key elements of Agile for the UX community and describe strategies UX people can use to contribute effectively in an Agile team, overcome key weaknesses in Agile methods as typically implemented, and produce a more robust process and more successful designs. I talk a lot about Agile as it’s really showing up in organizations, as opposed to how it’s defined ideally, and suggest ways UX designers can cope.

The lecture is available for purchase as an online document (PDF) and also in hardcopy at Amazon.

Agile 2010

I’ll be presenting a session at Agile 2010, the big conference on Agile development. The conference covers all aspects of Agile development, including managing the process, how-to, and experience reports. I’ll be presenting a hands-on session on Wednesday, The User Feedback Two-Step. I’ll use a simulation game to give participants the experience of working on an Agile project, both as developers and as UX designers. The game lets participants practice how to plan stories and schedule work into coherent iterations. Come say hello if you’re there!

Agile Boston Open Space

The Boston Agile group is hosting an “Open Space”, a day-long mini-seminar, on September 16.  I’ll be convening a session on how UX designers work within an Agile process. We’ll discuss industry best practices and share stories about what’s worked and what hasn’t. Open space sessions tend to be more free-wheeling and interactive, so it should be a good time.

That’s it. I hope you’ll be able to take advantage of one or more of these opportunities—this is an exciting time in the world of Agile and it’s fun to be part of it.

“You know what was conspicuously missing?” my husband said as we walked out of the store.

“Nokia!” we said together.

Where is Nokia in the new wave of cool mobile phones? They had the market, the reliability, cell phone models with large screens, integrated applications, SMS, and the first powerful ring tone store. They had cameras, web surfing, and music. So they had the basis to leap into this market—to create it. But Nokia was not on the shelf.

Juhani Risku, an ex-Nokia executive, was recently interviewed by Andrew Orlowsky of The Register, who posted an intriguing and revealing article. Risku’s recent book about his time at Nokia is a minor sensation in his native Finland, and contains a sweeping diagnosis of Nokia’s perceived innovative malaise.  He offers some radical suggestions for a new Nokia, one that can keep up with the Googles and Apples of the world in terms of groundbreaking products and services. Throughout the article Risku’s pain at Nokia’s malaise and his anger at their non-performance runs deep.

The inability to ship is not unique to Nokia—as I wrote in Corporate Identity and Innovation: “Innovation is not just, or even primarily, about technology leaps—or user experience leaps—or new category definitions. Innovation is about corporate identity and corporate skill.”

Nokia was a valued client of ours some years ago. We loved the people and the place and the energy. We introduced Contextual Design to that organization, training probably 100 people in how to do the process. We stopped doing direct work with product designers in Nokia in 2001, about the time Risku came to the company.

Any time people have great hopes for their company, they look around for causes when the company seems to stumble. But I must say, I was surprised to find myself listed as a leading cause:

Another feature of the modern Nokia bureaucracy, that wasn’t present 15 years ago, is the obsession with data gathering.… There is a philosophy called Contextual Design, every designer at Nokia has been trained in it by the guru Karen Holtzblatt. Everybody has attended her courses and got her very expensive book signed. The idea is that you ask the users what they are doing, then design something. If you think about Apple, they don’t ask anybody. The idea of users as designers is a catastrophe!

Wow! I didn’t know that I trained so many people or that I was even a minor contributor to Nokia’s problems! If we at InContext (and others in our field) affected designers around the world to understand the lives of their customers,  what they do, their intents, their motives, the drivers of their joy, delight and frustration—and armed with that knowledge, to create great products—I think that’s great!

Why? Because, as Risku later says, “We have to rely on what the desires of users are and trust the designers.”

Yes, this is the core of the Contextual Design philosophy—understand users in order to find out their fundamental intents, desires, and drivers. But these are invisible to the users—so the only way to glean them is to go out in the field and talk with people in the context of their real life.

I have written repeatedly about this core philosophy—in our book and in the article Don’t Ask Your Customer. Yes, innovation and requirements do not come from asking the customers anything.  Customers will never reliably tell you what to make or build. If we listen to their feature requests and implement them, we will probably be implementing a tiny fix to an annoyance in our product or adding a feature that a competitor has. But we will not create a new wave in the industry.

Gathering field data does not involve asking customers what they need or want or do. But it is sometimes hard to get developers, designers, UCD professionals, managers, and C-level executives to understand the difference. Field data does not mean asking questions of people and looking for answers in their words.  Field data-driven design means learning what is happening in people’s lives and experiences and then using that knowledge to invent something of value.

I don’t agree with Risku when he says about designing from field data: “It’s only relevant to evolutionary products, it’s not relevant to blue-sky products. When you have a blue-sky product, there are no users, and so there are no users’ opinions.”

But I do agree that companies should not design from user opinion.

Design and innovation emanate from a dialogue between the inventor and the world into which the invention will be placed. Design springs from the heart of inventors deeply immersed in knowledge of the customers’ lives and the technology that might transform it. Contextual Design—and field data gathering—creates that immersive experience. The solution comes from dipping the inventors into that data and letting them go.

Risku lists many, many ideas that were never shipped by Nokia—evidence enough that immersing designers in field data generated lots of ideas.  Unfortunately Nokia the organization could not find a way to ship them.

I share Risku’s pain.

His claim, which I agree with, is that the ID is responsible for the overall structure of the application as experienced by the user. Are we building the right system? Does it do what the user needs? Does it do it in a way that the user finds natural, providing just what is needed, when it’s needed, and nothing extra? These are issues for the ID to solve. (I actually prefer to call this the User Experience (UX) and talk about User Experience designers. No matter. There are fine distinctions, but they aren’t important here.)

It seems obvious when viewed from the user-centered side of the house that (1) this is a real job, (2) it needs to be done, and (3) it requires a whole-system view of the application. You can’t do the ID job if you look at the app in parts—if you take each subsystem or, Lord help us, each screen, and design it independently from the rest. For the user to have a consistent, comprehensible understanding of the app it has to present a consistent and coherent interface.

Yet your average developer has a real problem understanding this. Right now, this disconnect is creating difficulties in the agile community—the interaction designers (or usability engineers, or UI designers—whatever they are called in the particular organization) want to consider the application as a whole, thinking about all the parts together. The agile community doesn’t understand the need.

The agile approach to design is to do as little of it as possible. The agile approach to design looks like this: Write a story—which describes one particular part of the proposed app, independent of all the rest; design the system support for that story, including the UI—without planning ahead to ensure the UI is consistent; implement it; and wait for the users to complain. Fix it when they do.

I’m hardly exaggerating at all here. Agile developers have had such success with their build-a-bit/test-a-bit/iterate-a-bit approach that many see no reason why it shouldn’t work for the  UI as well.

The origin of this kind of thinking goes back much further than agile methods. This is exactly how developers have been trained to think since Programming 101, which I think they are taking in in grade school these days. They are taught to split implementation into modules; every module should be independent of every other; no module should be dependent on the internals of any other; you should be able to completely change a module implementation without affecting any other module. If you have to change other modules as well, the task is given a special name—refactoring—and you get to complain a lot and have a good excuse for being late.

But this is the exact opposite of good interaction design. If any element of the interface changes, it may well require changes all across the system. If I change how popups work in the Accounts Receivable package, it may well be necessary to make the parallel change in the Reporting package—otherwise the user experience is inconsistent. If I restructure the layout of one page of my website, it’s going to look like it doesn’t belong with the rest of the pages—so I have to change them too.

What this means is you have to do some up-front planning to get the user interaction right. You have to map out the application as a whole and think about how the parts are going to fit together, so you can decide what kind of screen layouts, user interaction mechanisms, and graphic details will work to communicate to the user throughout the app. You have to think about the needs of each part of the app to ensure your interaction architecture provides all the necessary components to make the function visible. Thinking this way is as natural to interaction designers as modular thinking is to developers.

In fact, developers do think systemically. Suggest a feature and they’ll automatically do a deep dive—working out the whole set of module changes required to implement it, down to changes in the underlying database structure. And they’ll make sure that this set of changes works together—systemically—to implement the feature. It’s just that they keep the system coherent vertically, by diving from the user-visible behavior all the way down to the technical implementation, rather than keeping it coherent horizontally, across all aspects of the system that affect the user experience.

If you don’t consider the overall user experience as a whole, you’ll have to refactor your interface during development—which can easily mean massive change across every part of the system, with massive user disruption. If a little up front user research and interaction design will avoid such a mess, it’s probably worth it. Our challenge is to find the appropriate way to incorporate interaction design into agile methods.

I think the motivation behind the concept of creative intelligence is to foster the generation of creative solutions, whether to benefit a company internally or to provide solutions to our customers. Put in that context, I would propose that a CQ (Creativity Quotient) at the individual level is less important than at the organizational level. My experience is that the most creative solutions come about when a team of individuals participate in the creative process.

In a prior life, I frequently led cross-functional teams charged with defining next generation products, computer and We would bring a team of 10-12 people together, immerse them in the customer data we had collected, and generate new product concepts together—and we came up with great ideas. Each individual brought their unique perspective to bear on the ideas and the mixing together and feeding off of others’ ideas brought about something greater than any of the individuals could have created on their own.

It’s sort of like putting different ingredients together in a mixer, adding water and out comes a cake, ready to be baked. As a team we had generated ideas like ‘ET- phone home’ for systems; where the computer or storage system would automatically contact the vendor (us) whenever an event happened. That way, we could actively monitor and repair systems before they actually failed. While EMC eventually shipped this functionality first (I believe) we had the idea long before anyone shipped it and our support people were key contributors to this creative solution.

Other ideas we came up with was to pre-load a customer’s specific configuration onto computer systems, software and I/O cards, before shipping to the customer. When the system arrived it was ready to go, a system image unique to that customer’s configuration already installed. This saved large companies a great deal of time when they were buying hundreds of servers at a time. In order to deliver this type of solution, our support, sales and manufacturing people all had to be involved, creating new processes. I was always especially impressed with the contribution made by team members in the Support and Manufacturing organization. Frequently these functional areas were treated as an after-thought. But the pre-configuration offering would never have come to be without their contribution.

I see the power of teams to generate creative solutions all the time with projects we do with our clients. The client team members come from various parts of their organization and with our participation they generate great ideas of how to improve products, develop new solutions and the like. I think the key is to provide the framework for a team to function in a creative way. While there is a lot of discussion about how to do that, the Contextual Design process offers a really straightforward methodology: gather user data, immerse a cross-functional team in the data and then generate new concepts (we call this visioning) by means of a structured, facilitated process. A previous blog by my co-worker, Larry Marturano, shares his perspective on this generative process.

My premise here is that it’s not about any individual creative intelligence but rather the power of different individuals bringing their unique perspective together in a process that allows each contribution to build on others’ ideas. Now, developing a way to measure the group or organizational creativity could be a interesting pursuit. Let the baking begin.

If you haven’t read Blink I highly recommend it; the book is insightful and entertaining—as is Gladwell himself. In fact, while writing this blog on an airplane I happened to take out my copy of Blink. Immediately, the woman across the aisle leaned over to tell me this was the best book she had read in the last year; it caused her to change her life. And then the flight attendant passed by and asked us what the book is about since her husband is trying to get her to read it.

My reasons for reading Blink were different than theirs. Hearing Gladwell inspired me to buy it because the stories he tells support something I talk to people about all the time—doing observational user research in the field, why it matters, and how to convince management to let you do it. If you are fighting to justify going out to observe your customers in the field instead of doing traditional interviews—here’s some ammunition from a credible source not connected to the technology community. Better yet, he’s not one of us user experience or Contextual Design zealots. (P.S. Fighting with facts, figures, and metrics as ammunition is often not the best way to convince people—a simple, evocative story like this one may be far more persuasive).

One of the key stories from Blink involves Vic Braden, who is one of the world’s top tennis coaches. For years Braden spent a great deal of time talking with top professional players about how and why they play tennis the way they do. As quoted by Gladwell, here’s what Braden says he learned from all the talking: “We haven’t found a single player who is consistent in knowing or explaining exactly what he does. They give different answers…or they have answers that simply aren’t meaningful.”

Braden found that the tennis players said they did one thing, but when he videotaped them he discovered they did something quite different. But what do you think tennis coaches tell their students to do? You got it—what the pro players say they do, not what they actually do. The result is that tennis players are spending hundreds of dollars to be told the wrong thing by coaches.

This all resonated for me because Contextual Inquiry (CI) interviewing comes from the same underlying foundation. We know that we can’t ask our users what they do—or what they need—because they can’t really tell us. And the more expert the user is, the more “invisible” what they do is to them. They do work; they don’t self-analyze themselves to understand what they really do.

But wait, this story has the tennis players being videotaped. Does that mean that technology designers need to videotape our users? InContext gets asked that a lot. The answer is “almost never”. If the technology is supporting the use of the body or if fine-level body placement matters, then videotaping can be useful. When you are delivering a product or system, what’s going on in the user’s thought process is important and you can’t capture that by videotaping.

For example, I recently coached a customer team in doing CI interviewing; we were observing a physician perform surgery. How the surgeon used the equipment and his hand and body movements were only a manifestation of what did really matters for this team’s solution—the considerations surgeons weigh in their minds and what support they need for decision-making when performing the procedure.

So that’s your argument for why you have to go out to the users, as supported by Gladwell. We have to go to our customers—wherever they do the work or life activities we want to support—and observe them as they do their actual activities or re-create what they recently did. If only ask them what they do—even if we’re in their office or homes–they’ll be just like those tennis pros who inadvertently lied to Braden. And we’ll be like the tennis pros who have designed programs that don’t help their customers.

I go to the big Agile conference every year, and when they talk about agile development they talk about how one week sprints are best, unless you do continuous integration, and really everybody should be doing Kanban by now.

At CHI, it didn’t sound quite like that. It was more like: “Our Sprint 0 is really more like bugfix.” Or, “Nobody really iterates. They just implement and go.” Or, “We’re really doing Scrummerfall”—a combination of SCRUM and waterfall—don’t ask.

It was a useful reminder that no matter how much everybody wants to say they’re using agile development, like any new process development teams are all over the map—and many aren’t really getting very close to the theoretically correct agile process at all.

The other realization I had from the various hallway conversations is that what’s missing in a lot of agile development these days is not a new problem at all—it’s the lack of sound user data to drive the process. This should be a no-brainer—agile development is based on the idea that you will iterate and evolve your system with its users. But then the development team tries to rush right into development with no up-front design—which means, no time for user research. And UX people are spread so thin that trying to get out to real users during the sprints is very hard.

And to make matters worse, a lot of teams don’t seem to be doing the other half of agile. Not only do they not work with their real users, but they don’t iterate either. They take a story, implement it, and then move on, with no time for rework or re-thinking if the implementation doesn’t meet their users’ needs.

If this sounds like your situation and you’re feeling frustrated, take heart—you have good reason to be frustrated. But there are solutions to these problems. I’ll be writing more about them over the next few months and I’ll talk about what you can do make your agile team more nimble.

This work is part of my overall work on practical innovation which I started to share in my Lifetime Award talk. Expect to see more about practical innovation and “cool” in upcoming writing, services, and books. I’ll keep you posted.

As part of this inquiry we wanted to engage the CHI community. We did it in our SIG on understanding cool – and we got over 70 people to participate. This was our submission:

Design practitioners know that part of their job is to create products and services with usability in mind.  Making products and services learnable, efficient and pleasant to use are certainly goals, but every designer dreams of creating something more—something so great that people crave it, long for it, must have it.  Marketers call it “a must have”, “compelling”, or “insanely great”.  But most of the rest of us just call it Cool.

Over the past several decades, Cool has evolved into a marketing imperative.  And so Cool has become like an overarching requirement for many designs, especially in the consumer product space.  But Cool is hard to pin down—there’s no accepted way to define it, measure it, or design for it. Like glamour, it is an ineffable yet powerful quality that depends on a host of subtle factors. This SIG created a forum to go beyond “you know Cool when you see it.” We collected and collated a number of concrete examples of Cool and identified patterns and design principles underlying Cool.

In the SIG, we wanted to hear the voices of the CHI community as users. We weren’t looking for their professional opinions about what was cool—we wanted to understand their personal experience of cool.

We broke into groups, each addressing one of 3 domains:

• Sensation and Aesthetics
• Fit to the Life Tasks
• The Device itself.

Each group broke into pairs and did mini interviews of each other, capturing key experiences on Post-its. Then the group as a whole discussed their findings and identified a set of key learnings from their own data. We had wonderful participation and got some validations of our field data findings and some new ideas.

Here is a summary of the findings:

Sensation and Aesthetics—Cool is:

• Immersive—It transforms you to another place and time; adrenaline rush;
• Example: surround sound
• Empowering—It makes you do things better than before and feel in control;
• Example: personalizing and customizing a phone.
• Delightful/Surprising—You discover new ways of doing things; color makes you feel alive and “modern”
• Example: watch YouTube on a plane—“Oh wow, I can do it now!”

Design Principles

• New isn’t always better—combine familiar things in a new way

Fit to life tasks—Cool:

• Saves of time and effort—it makes something that was complex, multi-stepped, or boring faster and easier and closer to a single step.
• Example: Pandora gives you one place to find artists
• Example: The Miele Vacuum fits many needs: powerful, easy, allergy reduction, less effort, works on all surfaces.
• Example: The iPhone liberates you from worry about how to get around and where to go in a new city—everything is in your hand.
• Example: The electric toothbrush—you stand there and it does the work
• Provides a no going back experience–Once you have the product you can’t go back to less; you appreciate a company that does it well; it builds brand loyalty
• Adapts to your life–It fits to your behavior and needs
• Example: Pandora internet radio, I can get my music based on mood;  my child can get their music and as the child grows they can get different music. One tool to deliver on all of it.
• Enhances your life—Adds a new dimension to daily life.
• Example: Tivo adds program choice
• Example: Internet TV incorporates community into watching
• Enhances your relationships—Helps you connect to others or express your identity

Design Principles

• Money does not equal quality. Can be cheap and good or expensive and not great.
• Deliver on the core value prop—Be clear about the top 2-3 things you will deliver on.
• Time is precious—the product needs to be efficient and quick
• Enhance life, don’t mimic it. The digital version must be better than life
• Expand your users’ understanding
• Add richness or a twist to what people already do
• Empower people to tell stories

The Device Itself – Cool technology:

• Is invisible—it does what is needed without human effort
• Is engaging—It pulls you in, turning activities into play, or by inviting you to explore; the interface itself engages.
• Is effortless—It works even if you are lazy.
• Example: On the internet you don’t have to directly participate in anything to get information;  just post and things happen magically
• Reinvents the familiar—makes something technical feel like the real thing
• Example: iPad feels like a real book so you feel like you are in the future
• Fits the hand—It fits you physically; it’s comfortable in your hand or in a physical space

Design Principles

• Make work feel like play
• Make something familiar more fun, delightful, or effortless

But upon reflection, I see a different meaning in the awards given this year.

We at InContext have been working for a long time—over 20 years, apparently a lifetime, YOW!!—helping people in real companies bring rich data into their design and decision-making processes. In the beginning there was engineering-driven design: 10 smart guys in a room deciding what would be “cool” technology to ship. Cool technology at that time had a lot more to do with data and integration under the hood than how it affected people’s lives in day-to-day life. Products were often tools for other engineers or tools that other engineers could customize for businesses. And there were for sure few women who were in those rooms designing or coding.

But as the platforms evolved and evolved more, and as we moved from natural language command line interfaces to WYSIWYG to VisiCalc to the Web to the iPhone, “regular” people started to be the real customer. This was the tip of a revolution that Hugh and I faced so long ago—and this is the revolution all of us have faced more and more over the years. Regular people who don’t care about understanding technology—who only care about what they are trying to do and how to get it done quickly with little “fussing with technology”—are our customers and business users today.

As a result, understanding people, their lives and their needs became critical for product management and engineers. This was the challenge in companies and in our community when Contextual Design was born. At this time there were also few “user-anything” job titles: Interface/Researcher/Designer/Experience/information architects…

Design for real people means understanding how technology can fit into their lives in valued ways. The contribution of Contextual Design and other field data techniques is getting the data that characterizes what is going on with people’s lives into the minds of the people designing and building products and systems. This is not just understanding how people respond to or interact with a particular tool or offering. Rapid prototyping and usability testing have always had this secondary focus. Field data provides the fodder for, as Ben Shneiderman said of our process long ago, “The only generative method in the field”.  Figuring out what to make in the first place—figuring out how to improve lives with technology given what people are doing and experiencing—this is what those of us who start the design process out in the field are committed to.

This balance between understanding the lives of people vs. testing tools and measuring the result reminds me of the nature/nurture question in developmental psychology; what has greater influence your genetics or the environment you are raised in. Both are important for understanding how we develop into who we become. Similarly our industry needs a way to understand what is going on in peoples’ lives so we can invent new solutions with the emerging new technologies that work for people. Field data is the compass showing direction and showing the context that any technology must fit into. Field data gives designers, product managers, and engineers the picture of the world they are designing for. But iterative testing of any product or solution improves what is already there and works out the user experience bugs. Any good requirements and design process needs both.

As Irene Au from Google said during a panel this year: “Web statistics and surveys can optimize the user experience but cannot create fundamentally new designs”

Or listen to Arnie Lund from Microsoft (another new member of the CHI Academy who is focused on practice): “What you measure is what you get—you never find out “why” from the data you collect off the web—you end up with way more data than you can deal with and no way to make sense of it. Optimizing one metric can degrade others. You don’t know how to balance them. But web metrics work to validate hypotheses or test two designs against each other.”

So what did we celebrate this year at CHI? We celebrated the recognition that field data gathering is at the center of the work we in this field do to make products and systems work for people. Take a look at who was recognized:

• The keynote was by Genevieve Bell from Intel, an anthropologist who was hired by Intel to understand the lives of women and people outside the United States.
• Lucy Suchman, who was the first person I knew using field data to inform product design, another anthropologist, received the Lifetime award for research.
• I received the Lifetime award for practice—creating Contextual Design as a practical process for teams to gather and use field data for the purpose of design.
• Allison Druin and Ben Bederson received the Social Impact award. They are known for working with children directly in the field and as collaborators in design.

The really impressive thing in this year’s CHI is not so much about acknowledging women, although I’m gratified to see it. The really impressive thing is that our community has recognized the value of field data for the purpose of design. Understanding the details of people’s lives has become mainstream, central to the design process. This is real industry change and we are celebrating it.

I for one was honored and humbled at the congratulations. But more, I was impressed by the number of students and university professors who came up to tell me how much they use our book and processes to teach design. We are indeed into the next generation—new designers, user researchers, product managers are learning the value of understanding people in the context of their lives to drive their design decisions—and that can only mean better products and technologies.

In my lifetime achievement talk I addressed innovation—the reality of what practical innovation requires of a company. Through an analysis of Avatar and the iPhone I mapped the challenge of producing a game-changing product or experience. And I addressed the role of field data in this process of practical innovation.

So go see it—tell me what you think. And think about the next layer of change needed in our industry. This talk was a prototype in how to talk to the top of our organizations. This is the audience I hope to engage in my next lifetime.

1. Tweet about what you think is the single most helpful design principle. If you had to choose just one principle that you could get all those non-designer folks out there who are creating websites that are impossible to navigate and apps that are just too hard to use, what would that principle be?
2. Include #CDbook and @incontextdesign in your tweet.
3. Our design chair, David Rondeau, along with assistance from the other designers here at InContext, will choose a winner based on quality, originality, and general “interestingness.” Winner will receive a copy of our first book, Contextual Design: Designing Customer-Centered Systems.

The Rules

1. The contest will run for two weeks.
2. If you enter once then think of a better principle, it’s OK. Multiple entries are allowed.
3. However, don’t do things that violate Twitter Rules, like post the same tweet over and over or create multiple accounts.
4. Unfortunately, the contest is only open to participants in the US for the English version of the book (no Korean or Hungarian available right now).

Nothing is as satisfying for us as seeing our clients successfully adopt Contextual Design. That’s why we wrote the book.

Learning Contextual Design for your teams

Unlike other vendors, we prefer to work directly with your team in executing our design projects. Working side-by-side with experienced InContext professionals, your team members help perform the work and not only execute to your business goals, but also receive practical, hands-on experience in Contextual Design. Even engagements where we do the work offer opportunities for involvement in select aspects of our process.

Our more traditional training classes are filled with practical examples and exercises, aimed at providing you the confidence — and the techniques — to get started.

Adopting Contextual Design in your organization

Our repeatable, structured process is ideal for institutionalizing as part of a company-wide design process. We can work with you to help you adopt Contextual Design to your organization’s innovation front end, software development and business analysis process, whether you use Agile, RUP, or other structured development methods. With our long history and expertise with a variety of large and small companies, we can help you navigate the organizational pitfalls and get customer data into your organization.

No matter how you engage us, our teaching-based approach will benefit your team long after we’re gone.

We bring a practical, no-nonsense culture and approach to our work with you. We invented Contextual Design, and with almost two decades of partnering with a variety of clients, we know exactly how to run our projects on time and on budget no matter the domain. Our flat fee schedule lets you know your costs up front.

Whatever service you choose, we work with you to define the right plan for your project, your resources, your timeframe and your budget. This flexibility ensures that you get value every time we work together.

Design Services

We partner with you to gather the user data you need and generate a vision, market message, business process, and validated designs that fit your users and your business. You can choose how much to be involved.

For any of these services you will be assigned an InContext team. The team members are guided by a project manager and overseen by a design expert. The project manager provides you with an up-front, day-by-day schedule and stays in close communication with your team and key stakeholder. At your option, let us help you find the right users and set up the field visits.

We run all our projects to the planned schedule, and you can rest assured that it will complete on the very day we say it will. And for any design service the InContext principals oversee the quality of the results.

Hybrid Design Service: Create a cross-company team. Build a joint project team including people from our company and yours. Your team members are trained while working side-by-side with us on your project. We manage the whole team to produce the agreed upon results. This is our most popular service.

Subscription Service: You get a dedicated team and project management and design expertise assigned to work on a series of projects over the span of one to three years at a fixed price. Think of this as your outsourced design team bringing Contextual Design to work on your projects.

Partial Involvement Service: Our team does the work and delivers the result to you. Your team members participate in a limited but structured way which provides them with intimate understanding of the data and the design results. They can come on visits, help build the affinity diagram, and be in the visioning process but they don’t have to commit to full time participation. Participate as your schedule permits.

Coaching Services

When you’re looking to make customer-centered design a part of how you do business, our coaching and training services will give you a head start. All our coaching services can be tailored to meet your specific needs.

Awareness talks: Familiarize your team, stakeholders, and managers with the purpose and benefits of customer-centered design.

Workshops: Learn Contextual Design during a focused period of time.

Side-by-side coaching: Learn Contextual Design techniques while working on your own deliverable. Our coach helps you plan and trains you in key techniques as they are needed.

CD adoption services: Build Contextual Design as an organizational skill.

Where does innovation come from?

People say innovation is about creating something totally new. So how can you generate requirements and design for something that has never been seen before by studying customers now?

The fact is that even “disruptive” inventions always respond to and transform some existing behavior or need. Technology moves quickly, but the core underlying human and business behaviors actually do not. Mobile phones address the need to connect, but that doesn‘t mean people didn’t communicate before mobile phones — or even telephones. Deeply understanding your customers’ current core needs and behaviors allows you to address them with future technologies, processes and solutions. And deeply understanding your employees’ real behavior and process ensures that your business changes make sense for the people and the business.

There is no magic bullet for creativity, but by bringing the key ingredients together, we make it easier for great ideas to emerge. Our visioning step steeps your team in the customer data, and leads them through a simple ideation process aimed at creating new product, service and process concepts.

Better requirements through validated innovation

Your customers can be your innovation partners — not by telling you what to build through feature requests, but by giving you early feedback on the concepts you create based on their needs, while it is easy and inexpensive to modify them.

Paper or quick online prototypes allow you to test your designs and solutions with the only people who matter — your customers — easily and quickly. What emerges over several rounds of iteration is a validated set of your most important requirements, based on actual customer behavior with real concepts. Validating content, interaction design, and information architecture ensures that you know what will succeed before you start to build.

Our User Environment Diagram and Living Specification capture these validated, prioritized requirements, the validated design and the structured customer data behind them. We help you have confidence that you’re building the right product in the best way.

Innovation for a wide range of applications

Using our Contextual Design process, we’ve worked with a wide range of clients and together created a broad variety of products and processes. We can do the same for you!

• Hardware and software products
• Business applications and systems
• Customer and enterprise facing web portals
• Consumer products

Understand your customers

Your customers are the experts at what they do — but you can’t depend on them to tell you. Like all experts, their behaviors, values and attitudes become habitual, all but invisible to them. It’s why the best players rarely make the best coaches. And it’s also why focus groups and surveys by themselves are often incomplete, overly general and too often misleading.

With Contextual Inquiry we take you into your customer’s real world, and collect data about people in their workplaces, homes, cars or wherever the real action is. We partner with customers to draw out and record the way things really work, and reveal the important details that are useful for design.

Characterize your market

Contextual Design’s work models, affinity and personas represent your customer data in a structured format that allows you to see common patterns without losing individual detail. This allows you to characterize your whole customer population — the markets, departments, or organizations that will use your product or system. Because your data is structured, you can add to your customer understanding over time as you collect more data. And the models give everyone on your team — marketers, designers, product managers and engineers — a common language to talk about customer needs.

Map your business process

By gathering customer data where the work is happening, we can help you reveal the messy details of business life that you might miss with other methods: the workarounds, the politics, the unspoken ways things “really work around here.” Deeply understanding these realities augments your business analysis and helps you define the right requirements for your new process or system. And our work models give your team — business experts, business analysts, process modelers and IT — a common framework to discuss user needs.

Identify the essential requirements

Your customers ask for features — more features than your organization can hope to implement. By understanding the real customer problems behind these requests, you can identify simpler and more powerful solutions that actually have fewer requirements and are easier to develop and use. Sometimes, when customers ask for A, B, and C — the real solution is D!

A repeatable process complements your development practices

Too often, efforts to understand the customer are ineffectual or wasted because it’s hard to figure out how to make customer data useful to the development community and others involved in implementation.

At InContext, we have real-world experience you can leverage incorporating customer data with Agile, RUP and other software development processes. Whether you’re a marketing manager, business analyst or a product manager, you need to know that investment in customer understanding will yield results in the development process. We can help.

You know the importance of understanding the needs of your users or customers. But what’s the right way to discover those needs? Here, take a quick quiz.

When is this the best place to conduct a user interview?

Only when you want to learn how people have a meeting! For designing products and systems you first need to understand how your users work, then support that work in your design. But people can’t articulate how they really do their work, so you have to get out of the conference room and go to their workspace to see them do it. This is the essence of Contextual Inquiry. See how Contextual Inquiry differs from other techniques.

How much time should I spend interviewing managers?

Only for as long as it takes to get the names of the people who do the actual work. These are the people you need to interview. The manager may have an idea of how the work is done at some high level, but you can be sure the actual workers do it differently to deal with real-world problems and the inevitable work-arounds. Using Contextual Design, you move from relying on abstractions and pure intuition to using real work practice data. Only then will you see a clear path to the best design for your users.

What’s wrong with this picture?

Nothing. You’re observing and discussing with the user, actively learning and documenting how they perform their work as they do specific tasks. You’re like an apprentice, asking why they did what they did so you understand their motivation and intent. This is how you begin to understand user needs. Learn more about capturing and interpreting user data by reading tips on Contextual Inquiry.

What should my questionnaire look like?

You don’t use a questionnaire at all. What you need is an interview focus and a way to take notes. You’re there to have users show you how they work, so let them. Rather than asking hundreds or thousands of users a set of canned questions, you go deep to understand the actual work structure with a much smaller and carefully selected group of users. With Contextual Design you can typically get requirements for a group, department, or market by interviewing 12 to 30 users, depending on the domain and how many different user types you need to cover.

Since 1992, InContext has been a leader in moving the high-tech industry from engineering-driven to user-centered design, helping major companies across industries tame complex problems with innovative solutions that delight users. InContext can partner with you through coaching, hybrid teams, or complete outsourcing of design projects. Find out how InContext can introduce a new level of innovation to your organization.

At InContext, we’ve successfully trained teams on how to bring real customer data into their organization and integrate it into their technologies and methods. We’ve worked with many large companies, helping them address these problems and manage their projects to a successful and timely outcome. Having been in business since 1992, we’ve seen the introduction of many different technologies and methods and we know how to leverage customer-centered design to get the best out of any of them.

Agile Methods

Many companies are now adopting agile methods—most often XP or Scrum—and finding them very effective in reducing chaos in the development process. Unfortunately, these same methods tend to disrupt existing arrangements. It sometimes happens that a working UX group is displaced by the introduction of XP and a development team that says, “We’re doing Agile! We’re not planning anymore!”

While any number of ‘Voice of the Customer’ methodologies can be used, we believe user-centered design offers significant advantages over other methods such as having a representative from each department or conducting focus groups or surveys.

But in reality, Agile methods depend entirely on a strong connection to the voice of your user. If your user isn’t a strong, powerful voice on your Agile team, there’s no way for rapid iterations and frequent testing to improve the product. Yet most teams find it impossible to make actual, full-time users full-time members of the project team. Most project teams end up using surrogates.

Contextual Design gives you a way out—a practical way to keep a strong user voice on the Agile team. Read our article on our work with one of our clients to find out how.

Six Sigma

To improve process quality, Six Sigma has become a popular approach. It depends on careful measurement of business processes to find out what takes the most time and where defects are being created. When the process is changed, continuous measurement ensures that changes produce real improvement.

This highly measurement-oriented approach depends on deep insight into what is going wrong in the current process and how to change it to make it more effective. When the process includes people and people’s work strategies, that insight is hard to develop.

Contextual Design dovetails with Six Sigma process improvement by generating the deep insight you need. While any number of ‘Voice of the Customer’ methodologies can be used, we believe user-centered design offers significant advantages over other methods such as having a representative from each department or conducting focus groups or surveys. We have helped many customers gain a full understanding of people’s work strategies, intents, and problems. Learn about our user-centered design process and contact us to discuss how Contextual Design could be used in your organization.

Process Design

When building internal systems, companies have to design the business process and software together, to ensure the software provides the right information and function to support the process as envisioned. Often software design and process design is done by parallel streams operating as part of a larger effort.

With Contextual Design, we’ve successfully coordinated these efforts, integrating both design streams using our in-depth understanding of the user’s work and of the business needs to define tested, proven processes and robust system interfaces that support them.

Since 1992, InContext has been a leader in moving the high-tech industry from engineering-driven to user-centered design, helping major companies across industries tame complex problems with innovative solutions that delight users. InContext can partner with you through coaching, hybrid teams, or complete outsourcing of design projects. Find out how InContext can introduce a new level of innovation to your organization.

Innovation comes from a deep understanding of your customers or users and a proven process for transforming that knowledge into insightful, user-tested solutions. Your users will say, “This is exactly what I need” and you’ll have the data to prove it.

“New ideas and new products always are a transformation of some existing practice; always respond to some existing human or business need. You can’t rely on the usual market research to figure this out.”

What if you have an exciting—even potentially disruptive—new technology or product? Is it really a winner without an accepting market? People say innovation is about creating something totally new. How can you collect requirements for something that has never been seen before and therefore has no market data to inform it? But new ideas and new products always are a transformation of some existing practice; they always respond to some existing human or business need (find out how). Inventing at its best addresses something that people care about, and if people care then there is something to study to inform that new invention. You can’t rely on the usual market research to figure this out. You need a learning organization that looks beneath the market and sees the patterns of use that your technology enables.

Since 1992, InContext has been a leader in moving the high-tech industry from engineering-driven to user-centered design, helping major companies across industries tame complex problems with innovative solutions that delight users. InContext can partner with you through coaching, hybrid teams, or complete outsourcing of design projects. Find out how InContext can introduce a new level of innovation to your organization.

Agile methods are a relatively new approach to producing software. In contrast to traditional approaches that emphasize requirements analysis, design, and implementation as distinct phases, Agile methods seek to minimize up-front planning in favor of producing working code quickly and often. Feedback from these baselevels is used to ensure that the resulting product is useful. Scrum and XP (Extreme Programming) are two popular Agile approaches.

Agile methods organize development around short sprints, from one to four weeks in length. At the beginning of the sprint, the team decides on the function to be implemented. At the end, the resulting code is tested and the team reflects on their process. In theory, the project is re-evaluated at each sprint and could change direction completely to better meet user needs. In practice, there is generally a strong expectation that the stories defined at the beginning of the project are the ones that will be implemented (just as they would have been in traditional development) and there is little time to rework stories that users aren’t happy with.

Agile methods favor face-to-face interactions over formal documentation. Rather than write requirements down only to see them changed in the middle of development, Agile teams seek to have the customer or product owner tell them directly about a needed function, right before coding on that function starts. To organize development, high-level user needs are written on simple index cards. All the details of the design of that card are worked out in conversation with the customer.

Accordingly, the customer role on an Agile team is critical to its success. This role defines what needs to be done, prioritizes tasks, and works closely with the developers to work out each detail of the system. However, most Agile teams often struggle to get real end-user feedback into their development—there is little time during sprints for user visits, users may not be local, and developers usually do not have skills or training in getting the best information out of users.

At the same time, Agile teams often find that there is little time to think about the system coherently, either to envision a whole-product solution to the users’ needs or to design a coherent user experience. For development purposes, Agile methods split both the proposed system and time up into small independent chunks. There’s no time and no process for looking across the whole system.

User-centered Agile, bringing Contextual Design to Agile Methods

This is where Contextual Design supercharges Agile development. CD defines a Phase 0 that precedes Agile development, providing a framework for user research, ideation, and high-level design. Phase 0 is itself iterative, incorporating several rounds of user feedback to ensure the right product is built. Phase 0 gives the Agile customer team the knowledge to write the right user stories

Then, during Agile development proper, CD techniques help the UX designers work with developers and gather user feedback within the constraints of a sprint. CD provides methods for fast prototyping with users and for maintaining the coherence of the user experience—two of the major difficulties Agile teams encounter during development.

CD guides Agile development with a 4-10 week Phase 0:

• Contextual Inquiry field interviews to research customer tasks
• Consolidation to understand users’ real needs, not just their expressed wants
• Visioning to invent a coherent solution to the user problem
• Quick Interaction Design Patterns and the User Environment Design to maintain a coherent user experience architecture throughout sprints
• Paper prototyping to rapidly iterate designs with users.

Let us work with you

We can work with you to ensure the success of your agile project. We can help you:

• Define and scope the project appropriately for agile development;
• Identify the key user populations to guide development;
• Run a Phase 0, an initial user research and analysis process to scope and structure the system at a high level, this system concept being itself tested and iterated with users;
• Define and prioritize user stories for your first release;
• Develop user interaction patterns and architecture for your concept—and drive it consistently throughout the sprints
• Ensure that everyone knows their job during development sprints to ensure good user feedback, provide guidance to development, and keep the project on track.

Agile Design Services

For any design services you will be assigned an InContext team. The team members are guided by a project manager and overseen by a design expert. The project manager provides you with an up-front, day-by-day schedule and stays in close communication with your team and key stakeholder. At your option, let us help you find the right users and set up the field visits.

We run all our projects to the planned schedule, and you can rest assured that it will complete on the day we say it will. For any design service the InContext principals oversee the quality of the results.

Phase 0 Customer Research and High Level Design: If you have confidence in your own Agile skills, we can drive your project with Phase 0 customer research and high-level design. We put together a team consisting of our experts who gather and analyze the customer data you need for success. We design, test, and iterate a high-level system concept to set your project direction. Finally, we run a joint release planning session with your team to write and prioritize user stories. We ensure the involvement of your stakeholders and experts at key points in the project to set the design direction.

Hybrid Design Team Option: We create a cross-company team including our expert designers and your key personnel. The team works side by side, under the direction of our experienced project manager. Your people participate in every activity, being trained on new skills as needed. You get the results you need, on the day promised, and also get your people trained in key user research and design skills.

Outsourced UX Team: If your UX resources are stretched too thin, we can provide you the expertise you need on your project. Our experts gather and analyze user data, including your team members as desired. Working with your stakeholders, we develop and test a system concept. We write user stories and participate in prioritizing them for your release. Throughout development sprints we do low-level design and work closely with your developers to ensure they know what to do for every story. We test the system as it is developed to drive continual user feedback into the process.

Agile Coaching and Training Services

When you want your own team trained in customer-centered agile development, our coaching and training services give you a head start. Any of these services may be tailored to your specific needs.

Awareness talks: Familiarize your team with the key issues surrounding agile development and customer-centered design. These talks address the main issues teams stumble over when introducing agile methods to an organization.

Side-by-side coaching: We coach your team through their own project, introducing Contextual Design and user-centered Agile techniques as they are needed.

Courses: We teach Contextual Design in the context of agile development to your people in a classroom setting. We practice key skills, including the transition from CD to development.

Agile development in the large

• Above all, people want products that meet their needs. Green features are not most peoples’ priority, only a secondary delighter. So don’t count on them to pay more for the green attributes of your product or service.

  Solution: Understand peoples’ essential requirements for your product or service, then design more sustainable solutions that meet them.

• People don’t want more complexity in their lives. They don’t want to have to think about tradeoffs when buying or using things; they don’t want to do research or go to a website for a rebate. They want simple choices with minimum fuss.

  Solution: Do the work for them—encourage conservation with minimum choices, in the moment, at the point of use. People leave products at their default settings, so have defaults favor conservation.

• Habits are hard to break. People may be favorably disposed toward conservation messages, but it’s much less likely they are actually adopting conservation behaviors. Lasting behavior change really only comes through a connection to peoples’ values and participation in community-wide action.

  Solution: Appeal to naturally conserving values—no waste, be frugal, no toxins—while finding lower-impact ways to address consumptive values such as wanting bright lights on for safety. Identify the communities that matter and cultivate its influencers—trade professionals, religious leaders, media personalities—to motivate new actions.

Start by gathering field data about your target population

With customer data we can help you understand and change human behavior and experience at the point of action – when habit can be broken through product and systems designs, identify which communities are best to target, who the influencers are, and what behaviors are the best to target for change.

Whether you are a utility, a business, a consortium of businesses, or even a business with a green line of products, a deep understanding of your customer population will give you the data you need to vision a strategy that will work, the technology to support it, and the messaging to communicate it.

On Tuesday, April 13^th, Karen is being honored by CHI with a Lifetime Practice Award. She’ll be speaking from 9:00-10:30, Tuesday morning, about practical innovation at her acceptance speech. Come listen to her talk about what makes for successful innovation - and the challenges  confronting a company trying to bring innovative ideas to market.

Finally, on Thursday, we’re teaching a course on interaction design called “Looking Below the Surface: Understanding and Analyzing Interaction Design” from 9:00-10:30. Focusing on the essential core concepts of design, this course will use real-world examples to help participants better understand interaction design and the importance of underlying structure. We will also provide strategies for making “good” design decisions and introduce interaction design patterns as a method for identifying structure.

Hopefully, we’ll see many of you at least once during the week. Make sure you come up and say hi!

CT’s core customers are legal professionals and paralegals working in corporate legal departments and law firms who manage the enormous bulk of documentation required for corporations to be in legal and regulatory compliance with corporate transactions, corporate records, and jurisdictional and securities compliance. This body of complex data requires multiple periodic filing updates, frequently across jurisdictions. Since form-based work was common across many core users, supporting the tasks around forms became the center focus of the redesign. CT’s previous offerings focused on providing services to perform this work for the customer, but they wanted to move to a self-service model. Therefore, the team’s research focused on understanding the roles, actions and motivations of the corporate and legal professionals who contribute to and accomplish the work surrounding the forms.

Because the new product would need to support users in various industries, and at different levels and intensities, it was vital the design be flexible enough to accommodate most variations of work flow.

Additionally, the company sought to relocate phone support to web-based support. To meet these needs, the team looked to answer the following:

• What is the users’ common pattern of work across multiple form types?
• Can CT design a user experience architecture that works for all types of documents?
• How can CT customers be encouraged to use web-enabled self-service?

The Process

InContext and CT formed a hybrid team with the intent of providing multiple CT members with on-the-job instruction and focused coaching in Contextual Design. The team performed 30 customer interviews and interpretations. This rich user data was analyzed with InContext’s affinity diagram and work models, capturing all of the key aspects of the work, and producing a comprehensive design which was then tested iteratively with users through paper prototyping.

Delivering Results

Grown from direct user data, all designs are validated results to work across document and user types.
Specifically, the core structure of information architecture and the additional systemic sets of activities to be supported results directly from designs based on user centered data. New product characteristics include:

• Enhanced workflow and guided assistance, enabling direct action
• Smart automation, reducing needless, tedious work
• Support for tasks according to the user’s preferred work flow
• Flexible views of data allowing users to meet their changing needs

There is a lot that is paradoxical about innovation – especially about new product development.  One particular paradox I’d like to talk about here has to do with “managing” innovation.  The problem is this: the nature of innovation is essentially unpredictable, but corporations have a legitimate need to manage it and harness it.  The resulting tension has generated tons of ink, digital and otherwise. 

In my twenty years working in corporate technology research and with InContext’s clients, I’ve seen two radically different approaches to dealing with this dilemma, representing each half of the paradox.

The first approach is to treat innovation no differently than any other business operation – as a deterministic process to be controlled, measured and predicted.  There is a lot of pressure on companies, especially in today’s environment, to get the most out of every dollar invested.  And to be sure, operational management techniques have greatly improved.  IT innovation has allowed corporations to streamline operations, slashing costs and giving management more real-time and finer-grained monitoring and control than ever before. 

A lot of this is rooted in a management mental model of business operations as a big machine.  Each part is interconnected, each part can be monitored, each part can be replaced if defective.  From Frederick Taylor on down, this model has pretty much been the dominant way to think about business.  And in some cases it works well.  Supply chain and production have been revolutionized by mathematical modeling, for example.  The machine is deterministic, or at least stochastically predictable.

The problem is that new technology innovation and new product development is much messier than neat mathematical models lead us to believe – even stochastic ones.  One big problem is that new technologies often are developed years ahead of the products that eventually commercialize them, and in ways that are completely different than the innovators expected. Or products get used in unintended ways that are big hits. In my prior technology research management role, I remember trying to balance my portfolio of research investments using the Black-Scholes option-pricing model that was all the rage for a time.  The model required “estimates” of inputs – market sizes, probability of commercial success (of what, I wondered), commercialization costs – that were just plain unknowable at the time.  And the outputs were extraordinarily sensitive to some of these assumptions. 

The completely opposite school of thought is the “genius” school.  In this line of thinking, no amount of analysis is going to help, so go with the smartest people you can find and do what they say.  Lock them in a room and make a big bet on what they want to do.  Ignore the customers and charge ahead.  The engineering mythologies of the skunkworks and the lone genius fit here, and the seduction for companies is that sometimes this works. Sometimes lightning does strike, and when it does, it feels heroic and it makes great press.  The RAZR story, although somewhat mythologized itself in its retellings, is a well-documented example.  But it’s also a cautionary tale, as Motorola was never able to make this kind of innovation sustainable.  Scott Berkun, in his great book The Myths of Innovation, points out just how unsustainable, and how rare, this model actually is.

The right model to me is somewhere in the middle - more Buddha than Black-Scholes. 

Paradoxically, if you try to control innovation too closely, it slips away.  Rigid modeling and strict stage-gate processes both work against real creativity and innovation.  To maximize your innovation effectiveness, you have to learn to give up your need to control too tightly.  You cannot be absolutely certain of innovative outcomes – you need to learn to live with the chaotic, random process that is creativity.  But learning to live with chaos and randomness doesn’t mean that innovation is unmanageable.  You just have to learn to stack the odds in your favor.

Some of these odds-boosters I’ve blogged about before – cross-functional, cross-organizational teams, and having a repeatable, executable process for gathering and analyzing customer data.  But there’s one more practice that’s important as well – a culture of building and testing, playing and prototyping rather than analyzing and predicting.  Michael Schrage calls discovery through prototyping “Serious Play”, and says you can tell a lot about the creativity of a company by how it manages its prototypes.  The more culturally “mainstream” playing is, the more creative the company – and the more competitive its offerings.

Early, iterative prototyping and testing with customers is a big part of what we do with clients every day.  We’re exploring concepts, bouncing them off of users and redesigning them together on the spot.  It’s a little chaotic, and sometimes unnerving.  But by letting go of our need to design too much up front, we actually get better ideas, and by the time we’ve gone through 2 or 3 rounds of this, the real design concept emerges.

Now, if you’ve followed me this far, you’ll appreciate this final little bit of paradoxical deliciousness.  It’s easy to think, and some authors advocate, that just being “free” and playing is enough to be innovative.  Instead, I assert that it’s a structured design framework that works best - one that incorporates a willingness to think freely and play with prototyped solution possibilities.  Infuse this process with a deep understanding of users, your business focus and technical capabilities and you’re pretty much guaranteed to come up with something useful, practical and implementable.

So dealing with the “fuzzy front end” takes a little Zen.  Stop trying to predict up front where your next billion dollar idea is coming from – and build.  Build, play and learn – and watch the winning designs emerge.

Go scan the business bookshelves. Innovation that produces major profit is the holy grail of business. Everyone wants to know the secret sauce. And now everyone wants to duplicate Apple’s secret sauce.

Dick Brass, in his Feb 4^th New York Times op-ed piece, lambasted Microsoft for not being first to ship touchpad technology. But then, Xerox PARC was not the one that made money from the direct manipulation interface, though they invented it. On Oct 18^th, Ashlee Vance of the Times published “Forecast for Microsoft: Partly Cloudy,” talking about whether or not Microsoft can transform itself to succeed against Google. Google and Apple are the current innovation darlings.

I won’t claim to have the last word on the secret sauce of innovation, but I can share some observations about the role of institutional mission and the ability of a company to deliver on a good idea.

And I suggest to you that Apple was successful because they just did the next right thing, given their corporate mission and skill.

The Phoenix team that crashed and burned

More than 18 years ago, a client of ours was trying to reinvent themselves. They had a new CEO who was looking to shake the company up and define a new growth direction. So he created Phoenix teams. Each team was supposed to figure out a new direction to take the company. The teams were funded and the scope was open. How much more committed to innovation could management be?

One of the product managers heard about our work and called. This company made hand-held measuring instruments; now some of their traditional customers were becoming involved in the emerging PC help desk services. At the time, the industry was in the middle of the changeover from IBM/VT100 terminals to PCs. There were early iterations of remote control apps on the market, including PCAnywhere, but they were expensive, difficult to use, and unintegrated.

At first, the Phoenix team studied people who did PC hardware support and repair and found there really wasn’t much of a market — they just did module swap out. So the Phoenix team that we worked with looked at the needs of the help desk users — a largely new market. These help desk users were people who might have been techs using measuring instruments before PCs came along, but by and large they didn’t use these instruments in their current help desk positions.

Help desk support for this company was a possible business adjacency: a new role for existing customers with a need to support a rough emerging technology. Not a bad place to hunt for business expansion.

We took the team into the field to understand what was going on with the help desk worker. We found out that their key problem, the primary time waster, was managing how to help users solve their problems without being there.  The solution was a help desk-targeted system, including trouble-ticketing, which at that time was not adequately provided.

The team was excited. Here was a new market with some big problems — the technology was either non-existent or, at best, costly and clunky. But the solution was software — not software embedded in hardware. The solution was trouble-ticketing and remote access solutions — not measurement. These were not usual solutions for this company. The team highlighted these organizational risks to their leadership, but management said, “Keep going.”

After several years of encouragement, this Phoenix team came to their final “go/no go” management review. The project was cancelled, the team disbanded, and the product never shipped. Someone else eventually made the money off of that same opportunity. Our team bemoaned the lack of insight of their company — and discussed leaving to become a start-up. They didn’t, but some just quit.

What happened?

This company knew how to create and sell small hardware boxes with really good measuring technology. They created software supporting the instruments. But this hardware company had no appropriate business models or organizational structures to make this new “hot idea” real. They didn’t know how to create, package, sell, or price software as a stand-alone product. Software as a product just wasn’t within their core skills area or part of their core business mission. Going from small hardware boxes with really good measuring technology to a help desk support environment was simply too big a stretch away from the core identity of the company.

Just because a team can see a direction doesn’t mean the company can go in that direction. Just because a new — even adjacent — market opens up doesn’t mean that a project can deliver on that opportunity within the context of the corporation they belong to. Delivering on an insight is as much about existing business identity and existing business skill as it is about what is technically feasible.

The future of collaboration that was never built

It was March 2000. There was content up on the Web but few transaction-oriented sites. There was interaction between consumers and information, but little between businesses. Where was the Web going? It wasn’t yet clear.

We were commissioned to study five industries and understand the future of B2B. The study was funded by a large enterprise software solution company looking for their web advantage. We studied software companies, trading, purchasing, corporate finance, and the auto industry. The data was loud and clear: the potential was enormous.

The most interesting findings were on the role of business-to-business collaboration. We recommended to our client that the future was in collaborative places for teams to communicate across corporate boundaries and negotiation places for safe transactions. All online, all secure, with the ability to support ongoing presentation, document sharing, and private conversations — both topical and attached to central documents. We recommended online places connecting companies where collaborating people could join and work — all for the purpose of transacting business across corporate, regional, and national boundaries.

At the time, there was no LiveMeeting, there was no WebEX, only email-supported, business-to-business collaboration. It was clear — by looking at the practice and the breakdowns in the practice — what the Web could become. This company was already supporting within-company sharing of data and information; this direction was a natural adjacency which could be implemented on a new platform.

It’s been more than 10 years now since we made those designs and recommendations. All of the ideas we foresaw have now been shipped-by someone else. Why?

This company was founded on knowledge about data — how to store it, how to share it, how to make databases work within an enterprise. They had a very successful sales model that targeted core back-office enterprise workers; they had a software platform that made producing many applications with shared access to common data easy to build. And new requests and needs for the core platform and products were coming in all the time. This was their cash cow.

Our design team’s new ideas required rethinking at every level: business models, data sharing, sales models, security across corporations, how to build on the Web, how to connect the Web to their existing platform, how to message to the users who would now use this environment — not the usual back-office customer.

No matter how much this team wanted to innovate — and they really wanted to innovate — they couldn’t move their organization. Our client discovered the possibilities first, understood the customer, had the design — but they did not catch the wave because this new solution required enormous energy and focus to create. And the organization was already focused on their core business. It is hard to put your focus on a new ball when all eyes are on the balls coming from existing customers.

Winning the market with planning

A large publishing company delivered very large paper reports. These reports compiled the findings of a professional search and included opinions for a very key business issue. The Web was encouraging publishers to provide paper products online. But these reports were enormous — hundreds of pages. “Would our customers want something online?” they asked. Could they be wooed away from paper and accept an electronic solution? What would it take to put it online? It is so big — could it even go online?  This company began by asking some good questions — before they acted.

The company’s enlightened VP knew where she wanted to take the company and knew that she had to build a software organization and competency to get there. They started by going to focus groups, showing  some initial mockups based on what they thought customers had told them they wanted. But the customers said, “No — this is all wrong.” Then they came to us.

In 2003 no competitor had anything online — and the team’s work showed that delivering on paper had real problems that an online report could address: finding information in the report fast; bringing the most desired information to the top; designing the content layout for simplified scanning; providing highlighting and tagging tools. The company delivered on the promise — and took the market by storm. Not because they were first (which they were), but because they designed their solution to directly overcome the known problems of paper. But simultaneously, they developed new business models, a new brand presence, and a new software delivery organization. They delivered an organizational solution — because they were committed to this new direction and planned for it. Having the right design was critical — but aligning the organization made it possible.

For industries like publishing, threatened by emerging online platforms, the necessity to figure  out how to deal with “e-everything” is strong. But denial that there is a problem (which we have seen) or haste to toss everything up on the Web (which we have also seen) can undermine client loyalty, along with the bottom line. Changing the company in response to technology changes takes enlightened, focused leadership acting on the corporate culture.

An innovative stretch

But what happens if you are a software product company — a really good one in your space — and you are looking for an innovative leap on new platforms?

Our client makes modeling software and wants to keep its current user base and grab the imagination of future generations. The current population is aging and knows how to use “old-time” technology. But real power and value comes with more sophisticated modeling — if only everyone was using it — and if only they could start with some easy templates. Web 2.0 and serious search technology was emerging. “What if,” they thought, “we create a kind of marketplace to share and reuse models?”

They called us to help them leverage new technology the right way to encourage designers to use the environment and to “get real” about its value. They got the data, planned the project, knew the necessary technology, shipped the solution, and are watching the communities grow today. They are seeding the users of tomorrow — with this new environment.

What happened?

This company leveraged their same mission with their same users to achieve an adjacent goal on a new platform. They incorporated new social networking and search technology with which they had serious competency. They  created buzz for their existing and new products to the upcoming generation. For them, it was just the next right thing.

From the inside of an organization, innovation often looks like the next right thing — not something radical. But from the outside, it can look game changing. But something game changing in the market still has to be managed and delivered appropriately. Users are simply too unforgiving of mistakes.

Apple did the next right thing — for them

So let’s go back to Apple and the iPhone. Apple makes hardware. Apple has been doing direct manipulation devices for years. Apple serves consumers. Apple has already done impressive industrial design on their hardware. Apple already has a reputation for and commitment to and know-how to design really usable software. Apple also reinvented itself and mainstreamed music delivery with iTunes. Apple has an infrastructure, third-party partnerships, and a model for selling little things through downloads to the general public.

And what was happening in the industry: content and applications of all types — video, games, text, social networking, maps — was already available on the Web. People were already searching on existing smart phones and getting addicted to them. Nationwide connectivity was reliable. And devices and downloads were now pretty fast — so performance was not much of an issue.

So was the iPhone a radical transformation? Was it an incredible innovation? From the perspective of the industry and sales, yes. But from Apple’s point of view, wasn’t the iPhone just the next right thing?

The secret sauce of innovation may be ready to ship  in your organization. The question on the table is: what is your company and what can your company do that is the next right thing for your customer, your overall skill set, your product commitments, and your corporate identity?

Or are you willing and able to radically reinvent yourselves over and over and over? Innovation comes from an organization that can leverage all their resources to deliver a leap in value and delight to the target customers.

And to find that value and delight — well, of course — we come back to user-centered design.

I was coaching a firm that provides HR expertise. They have a number of different services and information resources, but in the end their value proposition is that they have knowledge that will keep you, the small business owner, out of trouble. Which makes for an interesting design problem: if your value is something so intangible, how do you package it and sell it to your customers?

Since I was coaching them through Contextual Design, customer data was part of the answer, of course. We tell people that you can design anything you like with Contextual Design—as long as it has a customer—and it’s true. But most of our clients are either designing a tangible product of some sort or designing an internal business process. This team needed a much broader solution.

So when we started to vision our design solutions, the team didn’t just vision software solutions. They envisioned services, processes for delivering those services, procedures, marketing plans, and communication mechanisms—as well as internal and customer-facing software systems to support all them all.

Which presented a challenge for the next phase of the project. A software system we can design and describe using the User Environment Design (UED). How to define these other elements of the vision? We needed to provide enough detail so the business could see the impact—could see what they would have to put in place to deliver these new services.

To deal with this, we designed a method to define services based on contextual data. For this company, the service description included the following:

• Service descriptions. Each service got a title, a short descriptive summary, then a list of the roles required to implement that service and the parts of the online system useful to support the service.
• Process definitions. Each new process that was part of the vision was described. Elements of the process definition were a title, short description, and services supported by the process. Then the process steps were described, each step including the roles involved in performing the step, the system support used by the step, and the documents needed for the step.
• Roles. Each new role created by the vision was defined. Roles were given names, descriptions, the services supported by the role, key skills required to perform the role, and primary activities of the role.
• Documents. Each document required by the vision was summarized with name, description, and required contents.

What this allowed us to do was to define the service and process elements of my client’s vision at a high level. The client could easily see what new roles and skills they would have to staff for; what new documents would have to be created; and what processes would have to be defined and implemented to enable the services we had envisioned.

We normally use user data to design products, or systems, or web sites—but the data is much more powerful than that. No product or system stands alone—bring in the right people and the data will help you design processes, services, marketing messages, and all the support structure you need to make your system successful.

Over the years I’ve learned innovation and product development are like that, too. 

In my twenty-plus years in corporate technology research and development, and now working with a wide variety of clients, I’ve observed the same pattern: companies really have a hard time figuring out what to make.  The front end of development – the cradle of innovation – is indeed fuzzy.  Much fuzzier than is needed – or is healthy.

This problem is not new, even in high tech.  I recently re-read my old copy of “Developing Products in Half the Time” from 1991, and although the examples are dated, the premise rings true: companies spend lots and lots of time, effort and money in the front end of development.  Much more, in fact, than they know, since the wasted effort at this stage is hard to measure.

In a recent Businessweek cover story, Michael Mandel lamented “The Failed Promise of Innovation in the U.S.”.  In his article, Michael cited a raft of statistics showing a disturbing lack of real world impact for many of the highly touted innovation breakthroughs of the last decade, including alternative energy, genetic research, and next generation internet technologies.  But I suspect it’s precisely the failure to manage the innovation process that results in the poor return on investment many companies find in advanced technologies.

Actually, I think there is probably nothing wrong with America’s competitiveness in technology, or the pace of technological advance.  Instead, it’s this front end struggle with how to reliably translate investment in advanced technology and “research” into profitable products and services that people want and need.

My experience definitely resonates: poor front end execution is a big problem.

It’s strange how the concept of execution gets linked almost solely with operations.  The image of the “good manager” – the General Electric archetype – is typically associated with running mainline corporate businesses, taking advantage of efficiencies, optimizing and streamlining operations, squeezing improvement from the supply chain, and so forth.  In contrast, the term “manager” is almost a dirty word in popular innovation circles.  You almost never hear about execution in research, or advanced development, or design.

Don Norman alludes to this lack of execution in several of his books.  In “The Invisible Computer,” he describes what he calls a “human centered process” for product development, starting right from the ideation stage in the fuzzy front end.  While I like the way he ties technology, marketing, and user experience together, I’m not sure completely reorganizing the company is a realistic solution for better front end execution.  There are lighter weight ways to get things done. But Norman’s call for a holistic design process in the front end resonates – he even cites Contextual Design as an example of a development process that brings all three legs of innovation together. 

In my previous life, I worked to establish an innovation process based on users within a large company’s technology research organization – and now I work with clients doing the same thing with Contextual Design.  The experiences throughout are remarkably similar.  A funny thing happens when you introduce a stepwise process in the front end – people really value knowing what comes next.  While there can certainly be a good deal of doubt initially that a “process” (bad word, after all) can speed things up rather than slow things down, it’s almost like a relief for most people that they don’t have to argue about what steps to take next.  Teams we work with tell us having a way to structure conversations about ideation and prioritization based on real-world data is a huge time saver.  The trick is not to be too rigid in order to not kill creativity – but that’s a topic for another post.

I’m not saying that Contextual Design is the only way to create new products.  But I am saying that knowing what to do – or having a set of ways to know what to do – saves time and energy in a crucial part of product development. 

Putting one foot in front of the other is the only way to walk – or run.

Since 1992 InContext has used its Contextual Design methodology to design innovative solutions. InContext delivers strategic market characterizations, personas, new product concepts and design for consumer and business software, devices and consumer products. We take a holistic view—ensuring our solutions work for the users, the technology, and our clients’ business goals.

The Contextual Design methodology developed by InContext is a customer-centered design process taught in universities and used in companies worldwide. The techniques rely on extensive field data as the foundation for understanding users’ needs, tasks, and processes in order to design solutions that work.

InContext is looking for Work Practice Designers (User Researchers) who have a strong interest in design to be based in Concord, MA and Chicago, IL. They will work in highly collaborative cross-functional teams on a wide variety of client projects representing different user activities and technology platforms. Candidates must be passionate about creating products, systems, and websites that really meet the needs of users.

Good design begins with understanding how people work on a daily basis, which is why our Work Practice Designers are trained in Contextual Design. Work Practice Designers will participate fully in all phases of the Contextual Design process, including field interviews with end users, data interpretation, work modeling and consolidation, visioning, storyboarding, system design, paper prototyping and final design documentation.

All candidates must have:

Basic skills

• Bachelor’s or master’s degree in the following or related fields: the social sciences and humanities, especially anthropology or psychology, or basic sciences like biology
• 1-3 years of relevant industrial experience in one or more of the following areas: human-computer interaction, business analysis, information systems, user research or other related fields, product management.
• Willingness to travel on a regular basis, occasionally on short notice

Communication skills

• Ability to present and communicate design ideas to clients
• Ability to represent complex information simply in graphical format
• Special consideration will be given to candidates who speak more than one language: Japanese, Chinese, German, Spanish

Personal skills

• Quick and task focused: Must be able to work quickly under short deadlines, handle multiple tasks.
• Collaborative: Must be able to work in a highly collaborative team environment with clients.
• Clear thinking: Ability to quickly grasp diverse, sometimes complicated domains without previously having worked with them.
• Professional presentation: Should present well in formal and informal settings.
• Strong interpersonal skills and the ability to interact successfully and professionally with end users and clients.

Job locations include Boston and Chicago.  While relocation is not currently available, we offer an excellent benefits package, competitive salary and an opportunity to learn from industry leaders.

Interested candidates must send a resume, a writing sample, a cover letter and salary requirements to careers@incontextdesign.com.

InContext is an Equal Opportunity Employer.

Interaction Designers (Boston and Chicago)

Since 1992 InContext has used its Contextual Design methodology to design innovative solutions. InContext delivers strategic market characterizations, personas, new product concepts and design for consumer and business software, devices and consumer products. We take a holistic view—ensuring our solutions work for the users, the technology, and our clients’ business goals.

The Contextual Design methodology developed by InContext is a customer-centered design process taught in universities and used in companies worldwide. The techniques rely on extensive field data as the foundation for understanding users’ needs, tasks, and processes in order to design solutions that work.

InContext is looking for Interaction Designers with interaction and visual design skills to be based in Concord, MA and Chicago, IL. They will work in highly collaborative cross-functional teams on a wide variety of client projects. Candidates must be passionate about using customer data to create solutions that really meet the needs of users.

Good design begins with understanding how people work on a daily basis, which is why our Interaction Designers are trained in Contextual Design. Interaction Designers will participate fully in all phases of the Contextual Design process, including field interviews with end users, data interpretation, work modeling and consolidation, visioning, storyboarding, system design, paper prototyping and final visual design.

All candidates must have:

Basic skills

• Bachelor’s or master’s degree in graphic design, fine art, or interaction design
• Significant relevant coursework in the social sciences and humanities, especially anthropology or psychology, or basic sciences like biology
• 3-5 years of demonstrated interaction design experience
• Experience designing web or client-based applications (not merely web page design)
• Experience with the following (or similar) prototyping and design software: InDesign, Dreamweaver, PowerPoint, Photoshop, HTML, and CSS
• Willingness to travel on a regular basis, occasionally on short notice

Communication skills

• Ability to present and communicate design ideas to clients
• Ability to represent complex information simply in graphical format
• Special consideration will be given to candidates who speak more than one language: Japanese, Chinese, German, Spanish

Personal skills

• Quick and task focused: Must be able to work quickly under short deadlines, handle multiple tasks.
• Collaborative: Must be able to work in a highly collaborative team environment with clients.
• Clear thinking: Ability to quickly grasp diverse, sometimes complicated domains without previously having worked with them.
• Professional presentation: Should present well in formal and informal settings.
• Strong interpersonal skills and the ability to interact successfully and professionally with end users and clients.

Job locations include Boston and Chicago.  While relocation is not currently available, we offer an excellent benefits package, competitive salary and an opportunity to learn from industry leaders.

Interested candidates must send a resume, a link to your online portfolio, a cover letter and salary requirements to careers@incontextdesign.com.

InContext is an Equal Opportunity Employer.

Read here for more information and instructions to apply.

Since 1992 InContext has used its Contextual Design methodology to design innovative solutions. InContext delivers strategic market characterizations, personas, new product concepts and design for consumer and business software, devices and consumer products. We take a holistic view—ensuring our solutions work for the users, the technology, and our clients’ business goals.

The Contextual Design methodology developed by InContext is a customer-centered design process taught in universities and used in companies worldwide. The techniques rely on extensive field data as the foundation for understanding users’ needs, tasks, and processes in order to design solutions that work.

InContext is looking for Work Practice Designers (User Researchers) who have a strong interest in design to be based in Concord, MA and Chicago, IL. They will work in highly collaborative cross-functional teams on a wide variety of client projects representing different user activities and technology platforms. Candidates must be passionate about creating products, systems, and websites that really meet the needs of users.

Good design begins with understanding how people work on a daily basis, which is why our Work Practice Designers are trained in Contextual Design. Work Practice Designers will participate fully in all phases of the Contextual Design process, including field interviews with end users, data interpretation, work modeling and consolidation, visioning, storyboarding, system design, paper prototyping and final design documentation.

All candidates must have:

Basic skills

• Bachelor’s or master’s degree in the following or related fields: the social sciences and humanities, especially anthropology or psychology, or basic sciences like biology
• 1-3 years of relevant industrial experience in one or more of the following areas: human-computer interaction, business analysis, information systems, user research or other related fields, product management.
• Willingness to travel on a regular basis, occasionally on short notice

Communication skills

• Ability to present and communicate design ideas to clients
• Ability to represent complex information simply in graphical format
• Special consideration will be given to candidates who speak more than one language: Japanese, Chinese, German, Spanish

Personal skills

• Quick and task focused: Must be able to work quickly under short deadlines, handle multiple tasks.
• Collaborative: Must be able to work in a highly collaborative team environment with clients.
• Clear thinking: Ability to quickly grasp diverse, sometimes complicated domains without previously having worked with them.
• Professional presentation: Should present well in formal and informal settings.
• Strong interpersonal skills and the ability to interact successfully and professionally with end users and clients.

Job locations include Boston and Chicago.  While relocation is not currently available, we offer an excellent benefits package, competitive salary and an opportunity to learn from industry leaders.

Interested candidates must send a resume, a writing sample, a cover letter and salary requirements to careers@incontextdesign.com.

InContext is an Equal Opportunity Employer.

Interaction Designers (Boston and Chicago)

Since 1992 InContext has used its Contextual Design methodology to design innovative solutions. InContext delivers strategic market characterizations, personas, new product concepts and design for consumer and business software, devices and consumer products. We take a holistic view—ensuring our solutions work for the users, the technology, and our clients’ business goals.

The Contextual Design methodology developed by InContext is a customer-centered design process taught in universities and used in companies worldwide. The techniques rely on extensive field data as the foundation for understanding users’ needs, tasks, and processes in order to design solutions that work.

InContext is looking for Interaction Designers with interaction and visual design skills to be based in Concord, MA and Chicago, IL. They will work in highly collaborative cross-functional teams on a wide variety of client projects. Candidates must be passionate about using customer data to create solutions that really meet the needs of users.

Good design begins with understanding how people work on a daily basis, which is why our Interaction Designers are trained in Contextual Design. Interaction Designers will participate fully in all phases of the Contextual Design process, including field interviews with end users, data interpretation, work modeling and consolidation, visioning, storyboarding, system design, paper prototyping and final visual design.

All candidates must have:

Basic skills

• Bachelor’s or master’s degree in graphic design, fine art, or interaction design
• Significant relevant coursework in the social sciences and humanities, especially anthropology or psychology, or basic sciences like biology
• 3-5 years of demonstrated interaction design experience
• Experience designing web or client-based applications (not merely web page design)
• Experience with the following (or similar) prototyping and design software: InDesign, Dreamweaver, PowerPoint, Photoshop, HTML, and CSS
• Willingness to travel on a regular basis, occasionally on short notice

Communication skills

• Ability to present and communicate design ideas to clients
• Ability to represent complex information simply in graphical format
• Special consideration will be given to candidates who speak more than one language: Japanese, Chinese, German, Spanish

Personal skills

• Quick and task focused: Must be able to work quickly under short deadlines, handle multiple tasks.
• Collaborative: Must be able to work in a highly collaborative team environment with clients.
• Clear thinking: Ability to quickly grasp diverse, sometimes complicated domains without previously having worked with them.
• Professional presentation: Should present well in formal and informal settings.
• Strong interpersonal skills and the ability to interact successfully and professionally with end users and clients.

Job locations include Boston and Chicago.  While relocation is not currently available, we offer an excellent benefits package, competitive salary and an opportunity to learn from industry leaders.

Interested candidates must send a resume, a link to your online portfolio, a cover letter and salary requirements to careers@incontextdesign.com.

InContext is an Equal Opportunity Employer.

In a previous life, I spent many years as a marketing planner for large computer systems. What this really entails is giving guidance to the R&D, manufacturing, support and other teams about what products to build. I was frequently peppered with questions like, “What databases will the users have?” and “How many concurrent users must we support?” The questions were endless and covered a broad range of issues. Now of course, the R&D folks had every reason to ask me those questions—it was my job to understand how customers used our systems and make sure we designed products that met their needs. But how was I supposed to know that level of detail? And if I answered those questions, why would the engineers believe me?

As it turned out, I could answer those very detailed questions. My secret was Contextual Design—I had met Karen and Hugh and they had coached me and my team for a large project. We had gathered customer data and captured that information in various work models, including an affinity and physical model. So when my engineers came asking questions, I’d say, “let’s look at the data we have and see what it tells us.” Suddenly we were getting answers from our users, not from ‘Marketing’. The engineers loved it. They could get details—and engineers love details. The structured capture of information in different work models provided a language that I used to communicate exactly the level of information different groups in my organization required.

I’ve used numerous marketing processes and many development lifecycles during my career but it wasn’t until I encountered Contextual Design that I fell in love. Yes, I’d call it love because once I learned the process, I’ve stuck with it and used it in some fashion ever since we first met in the mid-1990s. For me that’s a long term relationship—okay, that’s a different blog. Colleagues frequently ask me what it is about CD that hooked me. My answer is simple—the real difference between CD and all other processes I’ve used is the capture of detailed data in work models and how those can be used for communicating to the larger organization. Of course going into the field and gathering appropriate data is important—that’s a no-brainer—but the discipline and structure of having that data captured explicitly in various work models filled a gaping hole I had found with other processes.

The first project I did using Contextual Design provided me with an understanding of how our customers used our large computer systems. I used that data for almost 5 years, answering questions and helping different R&D teams better understand how customers installed, configured and managed their large systems. We found the physical model to be of great use to us because it captured specific information about where these systems were located, in relation to storage, printers and other systems, how they were connected, etc.

We were now able to make informed decisions and choose trade-offs with much more confidence. I was no longer trapped in endless meetings as different people argued for their opinion, based on something they read or heard from a customer. I could now talk with confidence and with the work models we built from user data I was able to easily communicate what I and the team had learned with my executives. We spent much more time discussing how to deliver things rather than debating what to deliver.

An interesting thing happened to me after that. I spent much less time worrying about and investigating what competitors were doing. I didn’t need to. With the customer knowledge I had gained accompanied by the visioning we did, I knew exactly where we could and should go with our product roadmap. If we could execute against that roadmap, we would satisfy our customers and differentiate ourselves significantly. Now I worried about our ability to execute. As long as I could deliver what we knew our customers would need, taking advantage of technology advances and making it all easy for our customers, we’d be golden. My biggest fear was always that a competitor would beat us to market. And unfortunately, that did sometimes happen. I’ll share my thoughts about an organization’s ability to execute another time.

I’d like to talk about a related kind of empathy here – organizational empathy.

In a previous life, I spent a long time inside a big company, applying design research and user centered design to create next generation technologies and solutions for our mainline businesses.  My team and I were part of a centralized technology organization, and it was part of my job to “manage” the technology transfer process. 

It was tough.  We felt a lot of the time like we were pushing the proverbial rope.  Our internal customers didn’t know about – and often didn’t want – new things, or even to change at all.  We lived The Innovator’s Dilemma – our company’s customers and investors rewarded us for more of the same, but we knew we needed to create new products and businesses for long-term survival.

As a new manager there, I remember experiencing the same frustration that I’d experienced as a younger researcher:  Why won’t anyone listen to us?  Don’t they get how cool this stuff is?  Don’t they see they need to change?  Over time, we bred a pretty nasty case of “us versus them”.

Silos were a problem for us.  And tons of innovation management ink had been spilled about silos and how to avoid them – and it seemed like I read it all at the time.

The Porter crowd said that silos come from unclear company strategy.  Maybe, I thought, but I couldn’t do anything about that. Patrick Lencioni, one of my favorite authors, said that the way to cure silos is through shared goals and common reward and recognition.  Well, that sounded good, too, but that too was out of my control.  Plus, it seemed like there was something more to it.

Over time, we developed ways to work around the silos.  One of the best ways I found was to lend people to our development organizations to help them implement the new technologies we were transferring.  Of course, this was a blatant bribe because these organizations were always short of people.  And it worked, but not for the reasons I expected.  It turned out that the researchers who had spent time in a development organization came back with a deep understanding of what made our output valuable – or not valuable – to our customers.  Having lived life as a developer, they learned to see our technology organization as a developer did… and it was sometimes not pretty.  We learned that no one cared about papers, presentations or knowledge.  The lingua franca of marketing was user testimonial.  For development, it was proof of technical concept and working code.

But I also learned much deeper lessons that I apply even to this day.  I realized that the silo problem was deeper than well-defined strategy, common goals, or shared rewards and recognition could solve.  The problem is that different disciplines, like marketing, finance, software development, etc. are all driven by different cultures.  They speak different languages and have deeply rooted ideas about what good work is.  And these cultures start to be formed when people are still in school.  Engineers, designers, accountants, marketers all get acculturated to their professions’ value systems in school, and it gets reinforced by the largely functional nature of organizational design.  The disciplines’ cultures are further reinforced by the kinds of people who are naturally attracted to each profession – people get attracted to different fields because their personalities and world views are compatible with the existing or perceived culture of that profession.  Look at people who enter engineering school – they’re qualitatively different than people who go to design school.

The big lesson for me was that to cross organizational boundaries, I needed to encourage my researchers to truly understand – to empathize – with the way other departments thought, acted and worked.  Lending people out to other groups turned out to be a happily coincidental way to develop organizational empathy in my team.  It wasn’t just about the bribe – it turned out to be about changing the culture of my own organization.

The people who did this best really adopted the mindset of our internal customers, and later sought out rotation programs or outright transfers, but not everyone got it.  Those who tried to use understanding as a means to manipulate – like the stereotypical used car salesman – had much less success.  People are good at detecting authenticity, and I found that this organizational empathy had to come from the heart.

One of the things I like best about Contextual Design is that it supports the development of organizational empathy. Joining right alongside our clients on design teams, we gain a real understanding of the constraints, values, and approaches driven by the customers’ organizations – and organizational cultures. As a result of CD’s intense teaming experience, we usually find that empathy develops amongst the all of the team members—and among the organizations they represent.

“People know everything—everything—about what they do. They just can’t tell you.”

This is the central insight of Contextual Design—and sometimes the hardest for people to understand. Every classic requirements collection technique depends on the idea that you can ask your customer—or your business user—what they need and get a response you can use to drive solution definition.

But people focus on doing their life not watching their life. Surveys, focus groups, and interviews can capture users’ most recent complaints—but not the details of everyday life. Why? Because life is habitual, unconscious, and unfolds autonomically. So if you ask the customer, people can’t tell you what they do or what they want because it’s not part of their consciousness to understand their own life activities.

So what to do? Don’t ask your customer what they need or want or like. Instead—go see for yourself. Go to the field.  Talk with your users about what they are really doing while they are doing it. Then, you can see what people need—you can see what people are doing—and in the context of real life—people can tell you what is happening.

Read More…

This is the central insight of Contextual Design—and sometimes the hardest for people to understand. The whole assumption behind requirements gathering is that it is possible to ask people what they want, what they need, or how they work and get a reliable answer. But this just isn’t so.

I was recently talking to a portfolio manager—her company had decided that they were going to re-implement their intranet portals on a new platform. Reasonably, they wanted to gather requirements for the new portals. The business analyst sat down with this woman, a clearly competent portfolio manager, and asked her: What do you want? What does a portfolio manager need? She found herself totally speechless. She had no answer—even though she does the work the portfolio portal is supposed to support. She didn’t know how she used the portals, she didn’t know what she wanted in the future, and she didn’t have any “requirements.” But the business insisted on getting the requirements—the analyst needed to figure out how to provide them—it was a requirement to provide requirements. So requirements would be provided, portals would be built, and she said, “We all know few will use them.”

Every methodology invented for designing the right thing starts with gathering requirements. Requirements gathering is the single most difficult part of the process because if you don’t get it right, you don’t build the right thing—or the most desirable thing.

Every classic customer data collection technique depends on the idea that you can ask your customer—or your business user—and get a need or requirement that you can reliably build your solution upon.

• Surveys start with questions and expect reliable answers. But surveys depend on the user understanding the question, being aware of their own behavior, being able to articulate the behavior or need, having a reliable, unchanging opinion, and then being able to put a number on it. Or worse, being able to list it in an open-ended question.
• Traditional interviews seem better, particularly if they are one-on-one—more amenable to probing and interaction. But the interviewer usually comes in with their questions, their burning issues that they want resolved based on discussions with the design team, marketing, or business. And they too, depend on the user understanding the question, caring about the issue, being aware of their own behavior, and being able to articulate the behavior or need or motivation. Open-ended questions again assume that the person spends their time thinking about what they need, do, and want.
• Focus groups start with questions developed by a business group to answer business questions. Focus groups also assume that people can answer the questions. But in this setting the group members influence each other—on the good side, they may remind each other about some issues that otherwise might have been overlooked. Often one person dominates the talk or influences the flow of the conversation. But everyone knows that they have signed up to give their opinion, so they will produce one. After all they do the job—how could they not know what they do or want? Everyone can always find something to say!

In the end, designers need design data. They need to understand what people do, where the glitches are and where people have had to create work-arounds. They need to find the opportunity for delighters and gotcha’s. They need to see the inefficiencies and the huge holes in how things are done. They need to understand what is going on with people.

People make their work work. People make their life work. People use whatever technology or solutions they have because people focus on doing their life not watching their life. Life is the center of people’s life, not requirements or needs or technology. People using a pen talk about what they are writing, not the pen features. Indeed, the pen features only matter when the pen leaks or breaks!

So surveys, focus groups, and interviews will capture the most recent complaints that are still top of mind—but this is not where significant value is to be found. Value can be found in the details of everyday life. But even though people know everything about what they do, they just can’t tell you—because the doing of life is habitual and unconscious and simply unfolds autonomically.

Consider driving. Most of us know how to drive—we are experienced drivers. So I can ask you, “What do you do when you drive?” It will sound like a reasonable question. You will give me an answer: “I get my keys, and go to the car, open the door, get in and start it and back up and, well, then I go.” 

Anyone can give a high level description of what they do—but they don’t have the details.

• How do you hold the key?
  • This matters for keyfob design, as I unfortunately found out when I kept locking my new car every time I held the fob.
• Where do you put your cups and phones, how do you grab them, what do you need in your line of sight—without getting in an accident, please!
  • This drives design of the interior of the car, where storage and outlets are located, and these decisions affect the rest of the interior.
• How do you change gears? At what speed do you turn the corner?
  • This drives understanding how to design the controls of the car.
• What distracts you when you drive? What are you paying attention to—really—when you drive?
  • This guides the design of displays and automatic driving features coming into cars these days.
• What gives you the feeling of power, control, delight…?
  • This drives the aesthetic design and even the sound that is produced on acceleration.

 And if you doubt that little things matter, a personal story:

When I was in my 40’s transition I had to get a convertible—of course! So I went shopping with my husband. We went to look at the first Miatas, and I looked around while he went to get a salesperson to test drive. When he returned I said, “Let’s go—we aren’t getting this car.” Why? The door handle required that you put in one finger lengthwise to open it. “I’ll break a nail,” I said. They lost a sale over a handle design. 

These low-level details of what people do are what designers need—believe me I wouldn’t have been able to tell car designers gathering requirements to be sure not to break my nails! Armed with the details of everyday life, at work and home, designers will find what can delight users and make their lives easier.

And if you get these details wrong? The big ones and the little ones? At worst, you lose the sale. Or your internal businesses system will fail to be adopted. Indeed you might even go out of business! Scan Design in New England went out of business because they put a broken new invoicing system in place and ran out of cash before it could be fixed.

At best, what are the consequences of bad design? You continuously irritate people every time they use the big function that they do value.

Getting the requirements right is just hard. What makes it harder is that people really do want to do the right thing; like my portfolio manager and her analyst. People want to build things that people buy and adopt. But to do that, designers, managers, and C-level people need to understand that—

 “People know everything—everything—about what they do. They just can’t tell you.”

Even “requirements” techniques like rapid prototyping or Agile or co-designing possible screens with a user or business stakeholder assume that the user’s gut feel accurately reflects the most important things to build. But does it?

By the time an application or screen is built, someone—not the customer—decided what is best to build. Usability testing in any form can fix 10-12% of the little, annoying things at best—it doesn’t challenge the whole concept, or reveal the fundamental needs or value that the product could support but doesn’t.

So what to do? Don’t ask your customer what they need or want or like. Instead—go see for yourself. Go to the field. Talk with your users about what they are really doing while they are doing it. Then, when life is happening in people’s real life context, people can comment on it, people can react to events in their life, and you can see what works, what doesn’t, what is inefficient, where the delight might be, where the opportunity lies, and what value can be brought into people’s lives. You can see what people need and—in the context of real life—they can tell you.

In the end, this is the core secret of Contextual Design’s success—Don’t ask your customer—instead go into the field and see what is going on. Then the Contextual Design process helps a team use that design data and validate ideas with users. But without the right data—no organization can get the requirements right.

See the comic story of Don’t Ask Your Customer

I came to this conference to present our new research on how mainstream homeowners think about the environment, how they make decisions, and what might affect a change in their behavior. You can see the presentation here. Meeting the people was fun, and introduced me to this energized population creating the emerging technology to meet our energy challenges. Many of the products on display had no user interfaces at all. But that didn’t mean that they weren’t designing to change people’s lives.

Smart meters and tools and the associated Smart Grid are seeking to reduce energy consumption within buildings to help the utility flatten out its peaks. If we use energy more efficiently and evenly utilities avoid building new plants. But to do this means changing people’s behavior.

“It’s 3 pm and you are drowsy, so you want to go out for your Starbucks. If that cup of coffee cost $45, would you get one?” asked one presenter. I loved this because it made the issue real. If we charged a LOT for energy we would probably change our behavior. But as Michael Oldak from the Edison Electric Institute said, “We aren’t going to raise the rates in this country to the levels of Europe. The elderly, the poor, and the sheer level of increase in cost will keep us from doing something so dramatic.”

If we really changed laws to impact the cost of energy, maybe mainstream people would change. After all, Green IT is real because of economies of scale: actions like using virtual machines to reduce the number of servers a company needs does add up to big money. And replacing thousands of CFL’s (compact fluorescent lights), saving a few degrees on the temperature, and installing light sensor switches across a whole physical plant adds up to large savings. But for mainstream people in homes, as we found, the inconvenience to cost ratio drives most people to stick with convenience. The potential savings measured at best in $50 and $100 sometimes even $500 increments simply doesn’t jump the cost threshold that grabs awareness. In other words, saving money is not a good enough argument until the money is BIG money. And if it costs BIG money to achieve energy savings—well then, it won’t happen. They just won’t get that new furnace or won’t insulate.

Convenience in life is what matters: I’m home NOW so turn on the air, I need clean clothes NOW not when energy peaks are low. My need NOW offsets my thought of a few cents more for energy for this hour—such is the nature of the human being.

With Smart Grid technology utility companies are poised to step past the energy meter and come into your house—if you let them, of course. Technologists hope to get people to reduce energy without much direct human action and by creating devices that put my energy consumption right in my face. We have the technologies to do this—but will it work for people?

“Imagine this world,” I tell Sue, a young 26 year old friend of mine:

“All your appliances, your thermostat, and all your energy-using products talk this new technology language called Zigbee. The Smart Energy Meter on your house can talk to them and to the utility. When the utility sees that people are starting to use too much energy (which might cause a brownout) the Utility Watcher starts talking to everyone’s Smart Energy Meter.

“Did you set your thermometer at 68 instead of 74 in the summer? I’ll raise your temperature for a while.

“Are you doing laundry? I’ll turn off the heat and let it fluff for a while.

“Refrigerators running? I’ll shut them off 5 minutes in every hour.

“Washing the dishes? Maybe we’ll just turn that off until nighttime.

“Lights on for safety? No matter, let’s dim the lights.

“Radio, TV, music… well—you get the idea.

“Good, the Utility Watcher says, satisfied. I’ve reduced consumption 15% and that means we won’t exceed capacity.”

“WHAT!” Sue says. “THEY ARE GOING TO TURN OFF MY REFRIGERATOR! THEY ARE GOING TO TURN OFF MY LIGHTS? MY TV? What if I’m home? What if I need to get my laundry done to go out? What if it’s dark at the front door? They’d better give me a big HOME button to push that overrides it all!”

“Well,” I say, “you can control it and set preferences. You can also buy all these devices. You can have a decorator-designed device for your wall or table that gets red when you are spending lots of money or using lots of energy. Then you can jump up from your TV show and turn things off yourself.

“And Google has a plan. “How many of you know how much energy you consumed in the last 15 minutes?” asked Ed Lu from Google. “We are making an app so you can see your energy consumption real time. You will always know what you are consuming so you can plan your energy consumption activities for off-peak hours. Just like you manage your phone minutes or bank account, you’ll manage your energy. And you can have an iPhone app, of course, to turn things off remotely.”

“WHAT!” says Sue. “I’M NOT GOING TO RUN OUT TO SOME WEBSITE AND CHECK MY ENERGY EVERY 15 MINUTES! YOU HAVE GOT TO BE KIDDING! But maybe turning up the heat 30 minutes before I get home would be cool.”

Sue does check her energy bill regularly, as do other mainstream users. Being cost-conscious, if it gets too high, she turns out more lights. “But I’m not thinking about energy all day long! Why would anyone think I want to think about energy all the time?” she says.

I love engineers and work with them every day of my life. They are great for inventing how to do cool things like getting all these appliances and devices to talk to each other. And for some odd reason my favorite hardware at the conference were these funky monitors from Regen you put on the top of buildings that help all the HVAC’s in that building coordinate, flattening peak usage building by building. Cool!

But real change happens when cool technology meets real people. The technology has to be stable enough and reliable enough for regular mainstream people to use. What I learned at the conference is that Smart Grid technology is ready. But that means it is time to start designing how these technologies can be put effectively into people’s lives.

Technology that works is the material of design—it is a tool of the designer. But alone, it is not sufficient. Designers need to understand what people are really doing, valuing, what affects their behavior and choices, and how they do their real tasks. Then we can figure out how best to fit this smart technology into people’s lives.

This week’s Wall Street Journal highlighted that the stimulus package is pushing the Smart Grid and appliances that can talk to it. So this technology is coming to your home now.

Connectivity Week taught me that it is time for some real user-centered design.

Sure, that whole Easter Bunny realization was a downer, but over the years I’ve come to really like this feeling—almost treasure it. Why? Because it means I’m learning something new and non-trivial.

Larry Keeley calls it reframing the problem, Stephen Covey calls it a paradigm shift, Weird Al Yankovic just says that everything you know is wrong. Whatever. All I know is that whenever it happens to me, it means more creative ideas… and more passion! So I seek it out for myself and for the clients I work with.

In a previous life, I was an engineer in a large company’s centralized technology research organization. Our job there was to figure out what technologies would be important in several years’ time, create them, and transfer them to the businesses. And it was a creative place, a real dream for a geek like me. There were like-minded engineers everywhere and we had remarkably wide latitude to work on stuff that really interested us. But I became restless. There was creativity, to be sure, but it was rooted in technology. Not quite “if you build it, they will come”, but there was definitely something missing. It was like we were innovating inside a box that was defined by the technologies we worked on.

About the same time (and purely by accident, but that’s another post!), I became interested in user-centered design. I wanted to learn more, so I went to CHI98 in LA… and I noticed two things right away: there were definitely more hugs than at the IEEE gatherings, and there was an emphasis on design thinking and driving innovation from users that I’d never been exposed to before.

So I hired an anthropologist.

Well, the story is a tad more complex than that, naturally. But the bottom line was that my team started going out into the field to collect data about people who might someday use the technologies we were working on.

And that’s when I got hit by a big reframe.

Because I realized that my engineering experience hadn’t equipped me to deal with the information we were collecting. Or more precisely, I wasn’t prepared for the mental approach involved. Up to that point, I tended to see the world through the lens of hypothesis testing: we have some idea, we go test it, we accept or reject our hypothesis. We do more experiments.

But my new anthropologist friend was talking about “grounded theory,” which says that rather than gathering data to test hypotheses, we gather data to generate hypotheses. She kept telling us to forget what we thought the solutions were and just go observe our customers with a focus on the problem we were trying to solve. And hypothesize in the moment. She wanted us to realize that the initial technical solutions we’d jump to often limited our thinking. To be more creative, we’d have to think outside of the box. Even if it felt like jumping without a parachute.

And you know what? Our engineering teams started coming up with more and more creative ideas by setting aside the technical solutions at first. We already knew about technology, but by immersing ourselves in our customers’ realities as well, we started seeing connections between technologies and needs that we hadn’t seen before. Some of the most creative ideas came from field studies without pre-existing technological solutions. In my favorite study, we examined how families communicate and it eventually helped lead to an entire set of applications and infrastructure equipment around immediate content sharing. We had no idea where this might lead at first, but understanding the behavior allowed us to “twist” existing technology to meet real, but non-obvious market needs in a new way.

Over time, I learned to let go of my hypothesis testing mindset and let induction take over. It wasn’t exactly like everything I knew was wrong, but it was a new way of thinking… a paradigm shift from hypothesis testing to hypothesis generation. It was a little disorienting at first, but my fellow researchers and I got used to ideas coming from user data, rather than ideas being validated by user data.

Over the years since then, I’ve learned that steeping the design teams I work with in customer data is one of the best ways to produce those reframing, paradigm-shifting moments. Teams often find that the most important question isn’t “what’s the right solution?”—it’s “what’s the right question?” You can almost see the “a-ha” moments. Jaws drop, sometimes literally.

I guess that’s why I love taking teams through Contextual Design so much. Just being around when a team experiences one of those moments is priceless. Usually—as I’ve experienced personally—it’s followed by a burst of creative ideas—and a burst of passion.

There are a lot of interesting aspects to agile development, but I want to start by focusing on the core—the irreducible minimum, if you will, of agile development. It seems that everyone has their own idea of what aspects of agile to try. The purists (and consultants) will tell you about stand-up meetings, pair programming, and a hundred other new and unknown processes. Businesses trying to adopt agile take a more limited approach—often just breaking their task list into small chunks and closing frequent baselevels. This cautious approach is understandable—you can eat an elephant if you take it one bite at a time—but if you trade off the essentials, the process just isn’t going to work.

The essential core of agile is fast iterations tested with user feedback. Everything else is there to make that core work better, faster, or in a more organized way. Throw away everything else if you must but don’t trade off this core. Let me explain why.

Fast iterations are the basis of all agile development—that’s what makes it agile. The theory is in a changing world with unclear requirements and disruptive technology we can never be certain that our plans will work out in practice. So we never do too much without feedback—we do a little, check our progress, redirect if necessary, do a little more, and so on.

This is a fundamental way of managing risk and the more risk, the more fundamental it is. The avionics for the space shuttle were developed using an iterative approach because, they said, the waterfall model could not be used due to the “size, complexity, and evolutionary nature of the program”. [Madden and Rone, “Design, Development, Integration: Space Shuttle Flight Software System”, Communications of the ACM, Sept 1984] This also keeps the developers honest—at regular, frequent intervals they have to show that they are producing measurable value.
But of course, there’s no point in doing fast iterations if you don’t check your progress. And for a system that is to be used by people, that means checking with your users—most especially the direct end-users of your system. This feedback corrects errors early, ensures that you’re delivering real value, and reveals mistaken assumptions and approaches.

In some ways, the early development of WordPerfect—the first widely successful word processor on PC’s—illustrates agile development perfectly. The developers, Bruce Bastian and Alan Ashton, worked for the City of Orem, and their offices were downstairs from the secretaries and administrators their new word processor supported. They’d take a new kit upstairs, install it, see how their users responded, run back downstairs with a list of problems and new ideas, and have another kit ready in a few days.

But few of us live downstairs from our users. It’s tempting to want to get feedback on the cheap—identifying some kind of user surrogate instead of the real end-users. Maybe the Product Owner can pretend to be the user—though he works for our company and doesn’t do the work himself. Maybe we can hire a user to work for us—even though that means they’ll no longer be doing the work and come to share the development group’s outlook. (One agile group who tried this approach said, “They are just too nice to us.”) Maybe we can just do demos—even though user feedback in demo situations is notoriously unreliable. None of these options for feedback on the cheap are good enough, in the end. There’s no substitute for checking in with real users.

Later I’ll talk more about various aspects of agile development and how that fits with the organizational product development process and with user-centered design. But those are details. In the end, agile development always comes back to these two things—iterate quickly, check your progress. If you do these well, you won’t be going too far wrong.

When I was first putting teams together as a young manager, I remember wondering about how to build cross-functional teams. Of course, I knew cross-functional teams were Good Things™. But I really had no idea how to start. Around that time, I volunteered for an initiative that I thought would be highly creative and teach me something about team building. Our team was tasked with redesigning a key business process and it was made up of highly talented members with diverse backgrounds—one guy was a twenty year finance guru, another was a longtime supply chain manager, a couple of us were developers and engineers. We even had a cognitive psychologist on the team.

What looked like a fun and interesting extra assignment turned into a nightmare and the bane of my existence for nearly a year. Our team bickered like there was no tomorrow. Meetings were endless, and I didn’t think we’d ever agree on anything. People spent most of their time trying to convince—or bully—other team members into seeing things their way. When we finally delivered and implemented, I remember feeling like we should have been able to do more with less—more creativity, less stress and strife.

I was lucky to learn a valuable lesson from this mercifully temporary assignment.

Cross-functional teams are best made up of cross-functional people.

Oh, I’m not saying that teams made up entirely of domain experts can’t be functional. But what I realized then, and have lived by ever since, is that you greatly increase the odds of good teaming and group creativity by assembling teams of people with diverse backgrounds. I’ve found that teams assembled this way are both more creative and efficient—and just more fun—than teams of experts.

In his wonderful book, “The Ten Faces of Innovation,” Tom Kelley calls these people “T-shaped”. They have a deep expertise in one area, but much broader, shallower knowledge about lots of other areas. In other words, they know a lot about a little AND a little about a lot. Kelley claims that T-shaped people are excellent cross-pollinators on a team, bringing in novel ideas from far and wide to enhance innovation.

I agree with Tom in almost every respect, but I have a little different take on what makes these people such great teammates and innovators.

Actually, I think the key is empathy.

I remember when I learned Spanish. In my naiveté, I thought that learning another language was like word mapping. Figure out what you want to say in English, translate each word to Spanish, and there you go, yo hablo Espanol. This worked great until I ran across words that represented cultural concepts that just don’t translate… like, the Spanish concept of “manana.” This little word represents an entire set of cultural values around timing, urgency and priorities that just don’t translate to English. If you’ve ever done business in Mexico, as I have, you know what I mean.

At any rate, there is that day when you realize that another language isn’t just another set of sounds that you use to represent the same concepts, they’re another set of concepts entirely, another way of looking at the world. Once I realized this, I was never the same. I “got” it, at a gut level. There was more than one way to think about the world! I was changed and I never looked at anything—most of all world news—the same way again.

I think it’s like that with “T-shaped people”, too. When we get classically trained in any discipline, we get acculturated in that discipline’s view of the world. Engineers look at problems one way, graphic designers another way, architects yet another way. But when you’re exposed to more than one field of training, you “get” that there is more than one way to look at the world.

The people I’ve worked with who’ve had this transformative realization seem to be able to relate to others on a different level. They have what I call “disciplinary empathy”. They can see the world through others’ eyes and appreciate their approaches to problems.

And when people like this get on a team, they spend much less time arguing about which approach to take, what method is superior, whose ideas are best. They realize that there is more than one way to solve a problem, and they seem to be able to synthesize across disciplines easier, coming up with more numerous and more creative ideas.

So when you’re looking for your next design team, look for cross-functional people. Engineers who paint, anthropologists who can code, designers with MBAs… anyone whose background shows that they know there’s more than one way to look at a problem.

Cada quien tiene su manera de matar pulgas. There indeed, is more than one way to skin a cat.

The problem is that any innovative idea is disruptive. If it weren’t, it wouldn’t be innovative. That means it requires the business to do things it’s never done, sell in ways it’s never sold, build a type of product it’s never built, or otherwise act in ways that are uncomfortable, for which it has no experience, or which are outside its business model.

Take for example the iPhone—everybody’s favorite example of innovation just now. A friend recently grabbed me by the arm, as iPhone users are prone to do, to show me the latest cool app he’d downloaded. (It was the ocarina app, showing on a map of the earth where all the people currently playing the ocarina app are located.)

Now, I own a Verizon smart phone. And Verizon has their own branded online store—VCast and Get It Now. But has any Verizon user ever pulled me aside to show off the cool app they just downloaded? No. Do I have any cool apps downloaded? No.

In fact, I’ve tried to find cool apps for my phone a few times. I always give up after five or ten minutes of frustrated hunting around. I can find the apps—each of which is marketed to me with a few lines of unhelpful text, many more lines of legal disclaimers, and a request for $3.99 or more to buy something I don’t even know if I want.

How come Apple can make a market for downloadable apps and Verizon can’t? Yes, Verizon has usability problems, but why haven’t they made solving them a priority? Verizon is used to marketing to consumers, after all.

I think the problem is that to be successful in this market, Verizon has to redefine their business. They have to think of themselves not as a phone company, operating in a regulated market, but as a consumer-products company selling direct to consumers in an open, unregulated, online market. That would require a fundamental rethinking of their business model. And they haven’t yet decided they’re going to do it. And this really is a decision—they’re a large company full of smart people. There’s no question they could do this. But can they make the organizational commitment?

For Apple, it’s easier. They’ve been operating in the consumer-products market for a long time. They got their feet wet in the online-sales business first with computers and then with iTunes, so selling phone apps isn’t much of a stretch. For them, the stretch was thinking they could go into the phone business at all—but they were willing to make the organizational adaptations necessary to succeed.

Most companies find this very hard. To put aside all your organizational history and expertise, to go into a new market like a startup with all the commitment and focus and risk that implies, with no guarantee of success—it’s not really surprising that many organizations can’t bring themselves to do it when it comes to the point.

So if you’re thinking, “My company really needs to innovate. Why can’t we be creative like my competitor?” ask yourself if you’re ready to fundamentally reinvent your business. Ask yourself if you’re ready to experiment with untested business models, new marketing channels, new relationships with your customers. Because that’s what “innovation” will take.

For sustainability advocates in attendance, the “live within our means” trend is looking much better than during the past couple decades. For whatever reason—environmental consciousness or the poor economy—people are consuming less and more carefully. It reminds me a bit of the 70s where “ecology” was big and we started driving fuel-efficient cars because of the oil crisis. But, thinking back, during the 80s the oil crisis faded, the Cuyahoga River had long stopped burning, and our consumption and carefree ways started ramping back up. Fast forward to today. Will the people who are conserving and sacrificing now want to keep that up once the recession is over? What about Al Gore’s Truth, will it become Inconvenient again?

I don’t doubt that a new breed of sustainable lifestyle adherents will likely emerge, but I find it hard to believe that most mainstream people won’t simply want to get back to the party of consumerism once their finances are in order. If this happens, how will industry respond? At Sustainable Brands and elsewhere, I’ve heard serious talk of a resource-constrained future—think of the demands of increasingly prosperous societies on scarcer raw materials worldwide and the real possibility of oil in the hundreds of dollars per barrel. And, to add to the pressure, we can expect increasing government curbs on greenhouse gas emissions and other pollutants. The combined impact could mean deep trouble for unprepared companies and their business managers as they work to survive and emerge from the recession. This prospect helped explain to me why many companies are taking sustainable practices so seriously: they’ve concluded that they must learn to do more, more carefully, with dearer resources—all in the face of increased regulation. And, as I saw at the conference, big brands are taking notice: Clorox going at the mainstream with its GreenWorks earth-friendly cleaning products and Wal-Mart’s commitment to a sustainable supply chain, to name a couple examples.

One conference speaker, Andrew Winston, Green to Gold co-author, argued that companies need to radically rethink and redesign their businesses to be sustainable going forward—product and process tweaks aren’t enough. As if to emphasize Winston’s point, another speaker boldly brought up what he called “the elephant in the room” to brand managers in the audience: can companies realistically continue the pattern of selling more and more stuff as they’ve done in the past? Or will they have to come up with new and innovative ways to deliver value with less?

If a company does decide to fundamentally redesign their business to meet tomorrow’s challenges, how should they begin? Perhaps Mr. Winston will provide answers in his new book due out later this summer. In the meantime, a recent McKinsey Award-winning article in the Harvard Business Review, “Reinventing Your Business Model,” offers guidance on transformative change. The authors begin with the Customer Value Proposition: first and foremost, understand a crucial job to be done by your customer—a fundamental problem that needs a solution—understand it thoroughly in all its dimensions and the full process in how it gets done. Then design a complete and precise response to the problem better than today’s solutions.

Envisioning and designing transformative change from such an understanding of customers is what InContext has been all about for the past 20 years. Our recent research into consumer conservation behavior suggests that redesigning a business for sustainability can pose a particular challenge: mainstream people won’t necessarily be interested in the “green” attributes of a company or its offerings alone. Products must first and foremost do an excellent job of meeting customers’ needs, then people will want them—green is a secondary, feel-good bonus. So, if transformative change for sustainability is in the air, companies would do well to first understand what really matters to their customers, their essential requirements, and the extent to which they’re prepared to take on more sustainable behaviors. Assume nothing—use customer data to change with confidence.

Why does he do this? After a TV show he goes to find out what everyone says (he does this for Lost too). He rereads the description of the shows—even the ones he watched. (He says: “But I missed something and wanted to know what really happened.” But I know that’s not the whole story.) So I ask him: “What’s this about?”

And of course he has no idea.

But later he says. “It’s about extending the experience.”

“What?” I say.

“I like the show but now it is over—you want more. If you read it you can relive it.”

“Why do you tell me what the commentators say?” (Worse, why do I talk about it back?) It’s not like the Galactica people are real people! Why does anyone sit around talking about made-up characters?

“You see, it extends the experience,” he says.

It becomes part of our conversation—and our theorizing on plot. It becomes part of the topics of our shared lives. And it keeps Galactica alive—for a while anyway.

My son takes a picture with his digital camera—he’s a good photographer. He stops on the trail and shows them to his wife. They comment on how good they are.

The digital camera extends the experience of the flower, the cactus, the moment.
They come home and download the pictures—and look at them again—and relive it again—even as they are picking what to keep.

I visit my family in London who I don’t see often. The girls were in a chorus backing up a popular pop band. They pull up YouTube and show me the video of their experience—they tell me the whole story—they share their experience of the event and the music by showing me related videos to illustrate their point.

They extend the experience of their life by re-experiencing on YouTube.

Another secret: I read mysteries. A lot. Until lately I never reread anything. But I have a few favorite authors. I finished all the books by each author but I wanted that exact experience with that tone and those characters and a particular type of humor…
So after 20 years I read them again—in order of course—and I re-experienced what I once enjoyed.

I don’t know why the people writing Television Without Pity write—what is going on when someone watches something so closely that they can tell you each scene? Do they tape it and transcribe? (Who knows? Please explain!) But maybe they just want to extend the experience too.

So my husband and I got to talk about Galactica because they wrote—and I could share my made-up new ending because I didn’t like the real one. And for a little while—our favorite characters lived on.

Reading after a show or movie is not just “being in the know” or “being part of a community”. It’s not just about having something to talk to others about. It’s also about our reluctance to let go of something that is part of our lives no longer—it is about re-experiencing as a human driver.

Design—product creation—is all about finding value. But value, like “re-experiencing,” is hidden, elusive, and deep within the human psyche. The re-creation of human experience is not your usual “requirement”. Maybe we need to journey to the center of human experience to find the next hot product.

My 11 year old son and I were going to a Red Sox game, and since we live near Boston, we decided to use the MBTA subway system—or the “T” as we call it here. The new “CharlieCard” system had recently been rolled out, and I was excited to check it out. (Yes… I already know I’m a geek.) It was a big deal though, because the Charlie system replaced traditional subway tokens with new “Smart” cards.

When we arrived at the subway station, I saw new metal kiosks with touchscreens, standing throughout the entry area. I spotted one that wasn’t being used and guided my son toward it. With curious anticipation, I examined the kiosk. My goal was very simple—or so I thought. I wanted to buy four fares: two fares to go into Boston and two more to return after the ballgame.

To start, I touched the big button “To purchase new CharlieTicket…”
Huh? Why do I have to specify “Subway” if I’m standing in a subway station? And what are “Passes”—are they different from the CharlieCard? I chose “Bus & Subway Tickets.”
Obviously I’m an “Adult”, but is my son considered a “Student”? What age is “Student”? Do I have to buy one ticket for myself and another one for my son because the fares are different? I had to do something—so I picked “Adult.”
Now I’m really confused. How much is a fare? How much is my son’s fare? How the heck am I supposed to figure it out? I scanned the screen desperately looking for something about fare information—but there was nothing. Now I’m starting to panic!

I looked around the station hoping to find an answer and I spotted an attendant, busily explaining the kiosk to other bewildered patrons. He noticed my distress and with an annoyed look, pointed to a piece of paper that I hadn’t noticed before—because it was taped to the upper right corner of the kiosk.

Why is the info taped onto the kiosk? Why isn’t it displayed on the screen? Why do I have to calculate my own fare? Why doesn’t the kiosk do it? From the chart I figured out that four fares will cost $8. (Note: The ad-hoc, hastily taped up charts have since been replaced with the professionally printed ones shown in the photo.)
Now back to the touch screen. Should I choose $10 or $20? If I put extra money on the ticket, will I remember it the next time I ride the “T” or will I lose the ticket? I decided it’s better to get the exact amount, so I picked “Other Amount.”

From there, I entered $8.00, and was instructed to make my payment. I found the correct slot and fed it a $20 bill. After a few seconds, it dispensed my hard-earned CharlieTicket!

Eager to be done with the kiosk, I grabbed the paper ticket and we headed for the turnstiles. As I was trying to figure out how to use the turnstiles (they were also new), the attendant noticed my son—and informed me that I don’t have to pay for him. Children under 12 are free, he said. Boy, that sure would have been nice to know before I bought the CharlieTicket!

Why is this so confusing and difficult?

We could easily blame it on usability problems, of which there are many. You can read an article from the Boston Globe or blog posts by Ashley McKee and Gregory Raiz. They describe in great detail the many usability and basic design problems of the whole Charlie system. While it’s tempting to believe that fixing all these smaller issues will solve everything, it only treats the symptoms—it doesn’t address the root of the problem.

The real problem is much deeper: The system model doesn’t match the user model. What do I mean by this? Well, when a system is built, its creators have a mental model of how they expect people to use it. Naturally, they build and structure the system according to that model, whether they realize it or not. But the user also has a mental model of how they expect to use the system, based on their own experiences. If the models match, the system is easy to use; if they don’t, the system is hard to use. And the greater the mismatch—the greater the difficulty.

This explains why the Charlie kiosk is so confusing and difficult to use. The system’s model of paying for the subway and my model are completely different. The system was designed to support adding money to a ticket or a card—but I think I’m just trying to buy four subway fares. The system wants to know how much money to put on the ticket—while I just want to know how much four fares will cost. The system expects me to reuse the ticket—but I’m going to throw it away when I’m done. And think about the impact of this—how many people do you think ride the Boston subway every day?

To address the root problem, we have to do more than fix the “surface” of the design. It will make no difference if we improve the usability of the interface, reduce the visual complexity of the kiosk, or even modify functions, because they don’t solve the model mismatch problem. To really solve the problem, we need to change the structure of the system and that means thinking differently about interaction design. We have to move beyond just arranging buttons and functions on a screen—we also need to understand people, how they think, how they work, and how they approach the tasks we support.

The system model is the core—it’s the structural foundation that supports the entire system. We should get this right before we start designing anything else.

October 31-November 4, 2009. Anaheim, California, USA.

August 24-28, 2009. Chicago, Illinois, USA.

Places like Facebook changed the nature of social relationships. Lots of people think that is a good thing. But consider my client’s life: She has her college network and LinkedIn for professional stuff, then there is her Facebook for friends and family, and of course the relationships she still maintains in email. Her professional association wants to give her a way to keep up with her colleagues. And now her company is exploring a “rich profile” so she can network at work.

College, professional associations, religious and club organizations, work, work networks, family and friends. Today we can keep up with everyone forever. When is a good thing too much?

My doctoral work was on “Women’s Friendship and the Psychological Sense of Community.” (For those of you who wonder where the basic CD methods came from—this is it!) I conducted field studies with women of all ages to learn about their experience and their behavior. Here are some interesting bits.

Relationships are about sharing life domains

The psychological sense of community—or transcending existential aloneness—is all about finding people to share in the different domains of your life. So, when women have young babies and are trying to figure out how to nurse, how to balance work and home, how to potty train—no matter the profession, women need women to talk to, to advise them and commiserate with. They get together to live life together, nursing, diapering, and walking their babies as they talk about the struggle of new motherhood.

Last week a member of my Temple who is a potter asked if she could come to my studio and bring her work. (I’m a clay artist in my spare time.) “I like your eye,” she said. “I’d like to bring a collection of my work for your critique.”

A couple of years ago my husband found out that she was a potter and told me. We had chatted a bit about connecting at that time. But she is a young woman with young kids and my kids are grown. I work in my studio on weekends and she works in hers during the week between kids. We said we’d get together but we didn’t.

Then she went to a clay workshop I attended and we worked side by side. She saw how I worked and how I critiqued others’ work. So she thought of me—someone at her Temple—when she needed an art communal experience.

It is probably inevitable that I will become friends with this young woman: she is a woman, she is an artist, she could give me an art community, she is Jewish, she is active in the Temple, my husband is the Temple president and I volunteer, she has kids and now that I’m a grandma I’m back to being interested in young kids, I mentor young women all the time. What is happening?

Art/woman/mentor/Jewish/grandma—all the central aspects of my life can be embodied in one relationship.

In friendship, we gravitate to people who share our life domains—but we gravitate more to people who share several overlapping life domains. More interestingly —once we have a friendship relationship in one part of life, the friends start to taking on and sharing other aspects of each other’s life.

We incorporate friends from one life domain into another

My husband and I have a few friends that we met when we first came to Boston. They belonged to our current Temple and were friends of our friends. We also both had small kids and a need for day care so we joined the Temple and together we started to share child care. Each adult took a day and we raised our first kids together.

But they also liked to garden—big time—so we started gardening. We tilled their one acre garden together for many years. When we both moved and didn’t have a big piece of land any more, we both still planted a garden and talked about gardening. Then we formed a Chavarah—a group of 6 couples who meet to share Jewish Shabbath every 3 weeks. And we have been doing that for over 15 years. And so it goes—what starts out as one connection between people becomes many.

In friendship, we incorporate each other into the multiple aspects of our life. Why? Because we feel more understood, and more connected if people are involved through talk and activities in more areas of our lives. We feel less alone in the world.

Through incorporation people naturally consolidate their relationships as they go along increasing their sense of connection. But this drive to consolidate has a side benefit. Life is so busy it is hard to meet our needs for connection and shared activity with a huge array of people. Building our lives around a few close friends is efficient. Incorporation helps us manage the number of people that we need to maintain in our lives.

So what happens when we have all these on-line social networking places? How can we incorporate people from one part of life into another part of life? Does something like Facebook help with that or does it hinder? Are the relationships we have on-line of the same depth? Are they really “part of my life”? If social networking is about maintaining loose social connections why are we putting so much energy into it?

And do social networking places get in the way of the natural pruning of relationships?

Relationships have a natural pruning process

Why is it that people end up with friends within their religious organizations, or associations, or clubs or art classes? These physical places where communities meet represent the things that matter to us in our lives. Place gives us an instant community of potential people to engage in valued activity and to talk with.

Place maintains relationship for us without us trying. We go to work; we work together and build relationships; we see each other at work. So we don’t have to work hard to maintain the relationship—the place maintains it. And then incorporation starts. As a CEO I float on top of my organization so I was surprised to find that my employees regularly go out together, and not just to eat lunches. They run together, knit together, shop together—in other words they met at work and incorporated each other into their lives. But then what?

The drives of their lives took them elsewhere. Travel isn’t very good for a young woman looking for a long-term relationships—so she leaves the job. My admin had to become the main bread winner and changed jobs—eventually moving to another state. Another person moved back to the country of his birth. Wherever we are we build relationships. But the core drivers of our own development and our most intimate relationships take us to new places. And when we leave—we leave relationships behind.

We shed relationships over time. This is not because we have fights and stop talking. Rather this is the natural process of shifting places and shifting priorities in life domains. As my friend said, we weave people into the life fabric of our lives forming the rich colors and texture of life. And then, we change life direction, and we weave them out again.

Place maintains connection. And leaving a place naturally prunes relationships. Place supports life domains and when we change life domains we weave people out so we can weave new people in. We do carry a few relationships with us—but we carry what we can manage and we let the others go. Some people are acquaintances. Some are close. Some are fun mainly in that time and place. In the end, we prune.

Is this sad? Is this a loss? Or is this how we can have intimate relationships of depth and richness throughout our lives with vibrancy and vitality, ever renewing ourselves through new relationships as our life focus changes?

Social network “places” and on-line “places” where people interact about a shared interest let us maintain relationships that might normally be pruned. Problem is participation in each place comes with expectations of participation and relationship maintenance. Why aren’t we responding to those good college friends?

And if on-line places do not allow for incorporation as easily, then we also don’t consolidate our relationships. We don’t take on aspects of each others’ life and the relationship doesn’t deepen.

If on-line places can never be left because they are not physical—we lose the natural pruning process that causes no pain. Today it is easy to see how my client can be overwhelmed because she has no way to let go and focus her relationship commitment. Who knows! Maybe some company will invent a CRM system to manage our personal relationships (PRM)—to tell us when to ping friends so they won’t feel neglected?

Technology has again created opportunity to enhance life—we can keep and find people we lost and want to weave back in, or catch up, or network for jobs. But have we lost the natural way we manage our social relationships? What will happen—will we be rude and just drop people on-line? Will we be forced to spend hours dealing with relationships that might be better pruned? Will we end up building committed 1-2 hour on-line relationship time into every day now competing with face-to-face relationships? Or can we redesign and help people to consolidate and prune their relationships in a more natural way so that they can continue to weave people in and out of the rich fabric of life?

But it’s the keynote that really struck a chord with me. Judith Olson talked about body language and its importance in human interactions. This is underappreciated, I think, among user researchers. Our job is to go out and get information out of total strangers—with very little time for building rapport and trust. How and where we sit, how we position ourselves relative to our users can make our task easier.

I learned this first many years ago now, not long after we started coaching teams. I was coaching a paper prototyping interview, and things seemed to be going along well, except that our user was very tense and I couldn’t figure out why. She wasn’t uncovering major problems in the prototype and she was obviously competent in her work, but she wasn’t able to relax and have fun with the process, which most users do.

Then I suddenly realized she was scrunched all the way over to one side of her chair, completely pulled in on herself. And I realized she was doing this because she was pulling away from my interviewer.

Now, he wasn’t tall, but he was a weightlifter and it showed. He held himself square and rigidly upright. In fact, for a small guy, he took up a whole lot of psychological room. And he was standing right next to our user’s chair. In fact, he was standing in her intimate space, too close for comfort—and it was affecting the interview.

So I got him an armchair and put him in it, which moved him away a bit, put the chair arm between him and the user, and made him a little less intimidating. It moved him from intimate space to social space, a comfortable distance for having a conversation. And our user was able to unwind and work with us a little more naturally.

The concepts of intimate space vs. social space were just two of many that Dr. Olson discussed—the whole talk is worth reviewing. But they give you a simple way to control an interview. Ultimately, you’d like to be in the user’s intimate space and you’d like it to be okay—if you find yourself hanging over your user’s shoulder, close enough to touch, with both of you concentrating on a screen or on a work artifact, hashing out the details of some part of her task—then you know you’re running a good interview. But you can’t just go charging in there.

You also don’t want to start across the table, or across the room. That positioning, all by itself, creates an aloof relationship that won’t help you in finding out about their work. Instead, deliberately position yourself in social space—close enough to talk and look at materials together without being uncomfortable—and close enough to move still closer as needed and as appropriate. And keep your antennae out to gauge your user’s response—everyone has different boundaries and is comfortable with different distances. If they shrink, or turn away, or tense up, back off—and your interview will go better.

I always wonder—if I lived nearby would it pale with frequency? Would the rush of my days take over my perception of awe? Would the thoughts in my mind of have to’s and should have’s and must do’s blind me from miracle?

Do you remember a world without WYSIWYG? Do you remember putting in codes to indirectly say “make this bold?” And do you remember the first rush of moving around paragraphs directly?

Or better yet—think about cut and paste. When I was in college it literally meant CUT with scissors and TAPE into the right place—and COPY to make it look good. Cut and paste, along with delete, utterly transformed the way we construct documents today. We start with something we have—we move things in and out—we delete, we change—and presto, it’s a new creation.

If I try I can feel the frustration of early email. I could send you a note (sort of like SMS) but I could not send you a document. Real collaboration and coordination could not happen simply because we couldn’t send around the file with the right file format. But now we can! Amazing. Email became the center of business work. Was it mainly because of real file sharing? Now we are driven mad because we can’t send larger and larger files easily, and junk in the email, and too much communication.

My mother told stories of the ice man—and I mean the ice man because they had an ice box. Today, we have refrigerators and we don’t need the ice man anymore.

Technology creates miracles big and small over and over and over—but as soon as we have it we expect more and more and more.

Users of technology don’t care what miracles we give them—they take it all for granted—that is why we go cool on the “cool” products of yesterday. And that is why success is about being one step ahead; understanding not just where we need to go now but what will be expected such a short time later.

Watch this video. It will indeed remind you of the amazing revelations that are ongoing. And you’ll laugh too.

I’ve been a long time subscriber and fan of Netflix. I recently decided to get their movie streaming service and ordered the Roku hardware device which connects to my TV. With this device I’m able to instantly stream movies from the Netflix website to my TV. The service is free to anyone subscribing to Netflix. When I opened the package and began reading the instructions for set-up I was astonished to find there were only 7 steps involved to install and begin watching movies.

I’m a big fan of simplicity. I think Steve Krug’s Don’t Make Me Think is a great reminder to us that with technology, just because I can doesn’t mean I should. More features and functionality is not always a good thing. I always rant and rave at the nightmare most high-tech products put us through to use them—how many features on my digital camera will never be touched by me. I eventually figured out how to do the basic things I care about and that’s all I ever use. Perhaps a better example is when I bought a new wireless router last year, I gave up trying to install it after an hour of hopelessly trying to configure and assign a password to the thing. I had to call someone I know and pay them for an hour’s work to get it working. So the wireless router actually cost me $50 more than what I paid for the device and caused me aggravation besides. I thought maybe it was just me—that I was incompetent—not being able to install a wireless router. But I felt better when a friend, who is technically savvy and likes playing with these types of devices, had to call the manufacturer’s support line twice while trying to configure a wireless router for himself.

So when I started connecting the Roku device for movie streaming I was a little skeptical—would these 7 steps be easy and would they actually work? As it turns out they were easy and did work exactly as the documentation indicated. The set up was really only 3 steps; connect the device to the TV and plug it in, connect the device to the wireless router, and finally, activating my service. The documentation and pictures were simple and clear. Everything worked exactly as the instructions indicated. The final and pleasantly surprising step was instructions to use the remote.

The simplicity concept carried through to the design of the remote. Yes, I have yet another remote but this one is simplicity itself—only 4 instructions and I was masterly using the remote. The remote has only 9 buttons of which 4 are arrow buttons and one is select. I can just hear the debates that went on with the development team; everyone having an opinion about what features must be included, especially managers or influential engineers. I’ve spent hours in those debates, and without sufficient user data I could never counter their arguments. Yes, each feature would appeal so some users—but taken all together they become overwhelming and satisfy no one. But to Roku’s credit, they kept the remote simple with just the right functions and no more.

The benefits of keeping the product simple to install, configure and use are enormous. Think about it: low cost of manufacturing, low support costs—few calls, and of course low cost of the product. And then there are the marketing benefits. I tell all my friends how easy it was to set up and use and how great the service is. Simplicity itself can be a key differentiator and yet it is sometimes as elusive as those other whizzy differentiators we all look for. To make the trade-offs and deliver simplicity requires a real understanding about your customer’s behaviors, values and intents. And the only way to get that understanding is go out and spend time with them.

The theme for the night:  to prevent a catastrophe, we have to start using significantly more renewable energy and we have to start conserving right now in a really, really big way. The forum made it clear to me these conservation insiders and adherents are convinced of the path we need to take. But what about everyone else—mainstream people—are they on board? One expert estimated that we all need to reduce home energy consumption by 60-80% to even start making a difference. Are people really ready to make that kind of commitment?

Though 60-80% energy savings is huge, recent advances in design and technology are able to produce homes theoretically capable of this kind of savings (check out Europe’s PassiveHaus standard).  But, how many people are willingly going to pay a premium to build or renovate to these super-efficient standards?  Even if the government provides a subsidy? Our own research tells us mainstream people won’t pay much extra for efficiency—and won’t do it at all if the payback period is too long, let alone put up with the hassles of energy audits and replacing and renovating things for efficiency’s sake. They will, however, make efficiency upgrades for other reasons: replace an old worn out water heater, insulate to get rid of a chill, buy new appliances because they’re fixing up the kitchen. Appliances are now more efficient, but that’s only seen as a side benefit.

Furthermore, studies have shown that buildings frequently don’t perform to the efficiency level to which they were designed—a finding that points to occupant behavior as the critical variable. Even if someone pays for super-efficient construction, they may not attain what they paid for if they don’t change the way they live day to day. The forum moderator related a story that confirms this:  he and his partner live in a neighborhood of three nearly identical newer energy-efficient houses.  All three houses are occupied only by couples, each with similar work schedules.  He went around and looked at the electricity bills for the three houses and here’s what he found for average daily consumption:

His house:     3 kWh
House A:     10 kWh
House B:     20 kWh

The only reasonable explanation he could give for the difference in consumption was variation in occupant behavior: lighting usage, electronics usage, appliances they decide to buy and operate, and so forth. And formal studies reinforce his observation, having shown 200-300% variation in home energy use attributed to behavior. In fact, his house as compared to the others far exceeded the studies’ variation—but he admitted he’s an avowed energy conservation nut and the other households are more mainstream.

So even though technology enables us to move to a high-efficiency future, the real challenge is a human behavior one: getting people to request an energy audit, weatherize their houses, acquire and use efficient technologies, and turn down the furnace a notch. Fortunately for conservation advocates, our data—confirmed by years of behavioral research by others—points toward ways to foster meaningful behavior change.

I’ll discuss some of these ways forward in future posts.