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

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

CDTools has been discontinued

Thank you for your interest in CDTools. We are no longer offering this tool for new purchases or additional licenses. If you already have CDTools, you should have received a communication explaining the discontinuance and our plan for supporting you.

For those of you with licenses for CDTools, we hope you’ve been able to use these tools to facilitate your own exciting designs from customer data, and we hope CDTools continues to be of use to you. Please be sure to follow the instructions in the discontinuance letter and download the latest version of CDTools.

Stay tuned through our newsletter and blog for tips, tricks, and tools that may help you run your projects.

“Where is my iPhone?” she asked, “I have to put the baby to bed.” She is in the bedroom giving the baby a bottle and gently rocking her - while she surfs the web and reads news and email.

“Where is my iPhone?” she asked. It’s Sunday morning and she is reading the news - out in the middle of the desert.

She is checking out Facebook. She is sending email to work. She is calling her sister…

“Look at these pictures,” she says to her husband, “I just took them - isn’t this one cute? That one is great. I need to send an update to the family.” (Once a week she sends out a new baby picture.)

The baby is on her lap. “She loves the iPhone, she loves looking at pictures of herself,” she tells us. “Okay, okay, I’m turning the pages, just a minute.” The baby is staring into the screen - intense, intense wanting. It’s the new generation.

We are playing cards - fun at night - the baby wakes up… “Should we just get her and let her stay up awhile?” It’s illicit, it’s fun, it’s not perfect parenting - but we do it. “Where is my iPhone?” she says - and, poof! Ernie and Bert are playing to the baby, who is holding the phone - intent, intent watching. Crying cause it stops… “Wait a minute, wait a minute - look at this picture.”

A one year old is holding the iPhone and turning the pages to entertain herself… and we almost finish the card game - even the iPhone isn’t a good enough babysitter at 11 pm.

So why does my niece love the iPhone? It has become part of her life. It’s not just the ease of use that Apple is known for - so easy a baby could use it. It’s not just the connectivity to the wireless in the house giving us Ernie and Bert, the New York Times and Facebook. It’s not that it now has pictures like all other phones. And it’s not just lots of apps.

It’s that the iPhone has woven itself into the very fabric of everyday living.

I have clients who say, “How do they do it? We need to ‘think up’ the next rage, too!” What makes the iPhone cool? It’s more than “the pinch” or any one function or feature or design element.

The iPhone has become a life appendage, it is part of life itself, it extends what life can be. It’s the way every element of the product slides right into the spaces that life leaves open and offers delight.

In the space between the moments of real life is the place of real opportunity. Look there.

Shelley has worked with a wide range of industries and systems, including: insurance; financial management; professional information; publishing; medical devices and applications; supply chain management; customer relationship management; school communications; online learning; commercial real estate management; and ERP systems.

Prior to joining InContext in 2000, Shelley held senior management positions in product management, product development, business development, and training. She is a co-author for Rapid Contextual Design and holds a B.S. in Political Science from the University of California, Davis.

Kelley’s experience gathering and analyzing customer data spans large and small software and hardware projects encompassing cross-functional teams. His experience covers many industries, such as high technology, manufacturing, insurance, legal, and consumer.

Kelley joined InContext in 2007 after previously working as a contractor on numerous projects with the InContext team in 2005 and 2006. He previously spent 20 years working at Hewlett-Packard, where he was a marketing manager and business analyst, and where he also used Contextual Design on a variety of projects. Kelley holds a M.S. in Computer Science from Dartmouth College in Hanover, N.H.

Prior to joining InContext, David was a Senior Multimedia Designer at SilverPlatter Education, Inc., where he designed and developed award-winning products for medical education. He holds a B.F.A. in Graphic Design from the University of Lowell, MA.

Prior to joining InContext, Larry spent twenty years at Motorola Labs, where he participated in and led numerous technology research and development projects, spanning consumer cellular telephony, cable and IP television applications and services, public safety and government wireless communications, and most recently, ubiquitous social computing. While at Motorola, he led the successful commercialization of research application and service concepts in these areas, matching emerging technologies with the future strategic needs of Motorola’s businesses and shepherding technology transfer across organizational boundaries. He played a key role in introducing user-centered design methods into Motorola Labs’ strategic technology research, leading to the systematic adoption of Contextual Design and other user-centered methods in future technology ideation and research.

Larry holds a Ph. D. from Northwestern University, and M.S. and B.S. degrees from the University of Illinois at Urbana-Champaign, all in electrical engineering. He holds four U.S. patents.

Here’s the situation: I was coaching a team through the Contextual Design process. Now, this team has two people from my client’s organization on it, both female, both very bright, but very different personalities.

One of the two has a mind like a freight train—totally focused, totally driven, she clamps down on an issue or problem and just drives until it’s solved. She doesn’t get distracted by side issues, and she doesn’t have a lot of patience for fooling around.

The other woman has a mind like a New Orleans jazz band. It’s like there are half a dozen different characters in there, each playing her own instrument, each headed apparently in her own direction, but somehow it all adds up to something coherent. Every problem presented to her suggests five other issues; every solution suggests five other situations where it might or might not work. Not only can she not get through a design discussion without starting a few side conversations along the way, she can barely get through a sentence without being distracted.

Not surprisingly, these two were getting on each other’s nerves in a major way. Ms Focus couldn’t understand why Ms Jazz couldn’t stay on topic and saw her incessant off-topic ramblings as a major obstacle to getting work done. Ms Jazz saw Ms Focus as a control freak who kept shutting her down and didn’t want to listen to her legitimate concerns.

One of the fun things about being a coach is you get to see lots of different people and teams in lots of different situations. And you learn how very different personalities and thinking styles are critical to developing a good design. Yes, these two women each had a legitimate beef. What they didn’t have was an appreciation for the value of the way the other approached the problem.

So, during the course of the week, I had a chance to talk to them about this. They did a paper prototyping interview and afterwards, started to get up in each other’s grill about it. What I said to them was something like this:

“So, Ms Focus. What you’ve got is this great ability to see the main point and stick to it. That keeps you and the whole team focused on the real problem. What you have to recognize, though, is that your ability to stay focused can lead you to overlook problems. There’s always lots of different facets to a problem, and what you do is choose one to pay attention to.

“Now Ms Jazz—what you do is what we call associative thinking. Everything reminds you of something else—every issue or design idea reminds you of five other things that matter if you’re going to discuss that issue. And what happens is that all five things come tumbling out your mouth at once, so you get overwhelmed and frazzled. And yet these are real issues—you’ve got to deal with these links and connections because design is always about making all the different parts fit together.

“So Ms Jazz, what you need to do is give Ms Focus permission to focus you. What she’s good at is choosing among lots of issues the one that matters most right now. If you’ll let her do this, you don’t need to be frazzled.

“But at the same time, the issues you’re thinking about are real and you don’t want to lose them. So Ms Focus, you need to recognize that Ms Jazz is finding real holes in your design. You need a way to capture them as you go, without getting distracted by them, so you can deal with them at the right time.

“How about creating a ‘Jazz Worry List’ on a flip chart? Keep it on the wall, and when Ms Jazz starts doing her associative thinking, you capture her issues on the list. Then Ms Jazz knows they won’t be forgotten—so she can stop worrying and get back to the topic—and you can organize these issues and think about the right time to address them.”

Some points about this:

• By raising the underlying issues explicitly, I took what appeared to be an interpersonal problem and made it a process problem, which could be dealt with by neutral mechanisms.
• By talking to each about their thinking style in front of the other, I was able both to validate their thinking styles and raise awareness of the associated problems. I also gave them permission to talk directly to each other about this in the future.
• By giving them a tangible approach to handle the problem, I dealt with the way the thinking styles were messing up the design process.
• By making Ms Focus responsible for updating the list, I ensured she had ownership in making sure that Ms Jazz’s issues were heard—the list became a team tool, not something Ms Jazz was doing on her own.

How often do you get a chance to fix the relationship between two decent people and give them some tools to improve their collaboration? I’ve been on the road consulting now for 16 years. If you wonder how anybody can stand that kind of life—it’s days like this that keep me going.

As an engineer in the design field, I’m always puzzled by this claim – since good design practice seems to me to echo the very bedrock foundation of science: the scientific method itself.

The two fields – science and design – certainly seem at face value to be light years apart, practiced by people with very different training, values, and personalities.  But the problems faced by designers and scientists are similar, and the parallels between the scientific method as practiced by scientists and good user-centered design techniques are remarkably similar.

To see why, look at the essential components of the scientific method:

• Characterization of phenomena via observation and recording
• Formulation of hypotheses to explain the observations
• Use of the hypothesis to predict new phenomena
• Performance of experimental tests of the hypotheses’ predictions

Even if most normal people readily forgot these steps, together they form the pillars of scientific inquiry and are the very foundation of innovation.

Let’s poke around with these one at a time… I’ll start with Characterization here and talk about other aspects in later posts.

In The Character of Physical Law, Richard Feynman recounts a watershed event in science:

The times after Copernicus were times in which there were great debates about whether the planets in fact went around the sun along with the earth, or whether the earth was at the centre of the universe and so on. Then a man named Tycho Brahe evolved a way of answering the question. He thought that it might perhaps be a good idea to look very very carefully and to record exactly where the planets appear in the sky, and then the alternative theories might be distinguished from one another. This is the key of modern science and it was the beginning of the true understanding of Nature – this idea to look at the thing, to record the details, and to hope that in the information thus obtained might lie a clue to one or another theoretical interpretation. [Emphasis added]

Think about that.  Although he had his own views, Tycho Brahe believed that the truth would follow from setting aside his assumptions and observing and carefully recording what he saw.

So what does Tycho have to do with product design?

Well, the essential questions in product design are what to make, how to make it and how to profit.  “Great debates” often ensue about these questions – arguments rage about what the requirements really are, what features should be included, and what people really will want, use or value.  I saw these arguments every day in my previous life doing innovation in a big company – I’ll bet you see similar arguments in your company as well.

In customer-centered design, our approach is exactly the same as Tycho’s: observe and record.  Characterizing the behavior, attitudes and values of a product’s intended users gives designers data to design from – really no different than Tycho’s carefully recorded data about planetary positions giving Johannes Kepler the data he needed to derive the laws of planetary motion.  In both cases, observation about the natural world yields the raw material for innovation.  In both cases, the imperative is the same: set aside assumptions and record what you see – not in a lab, but in the real world.  There are lots of ways to do this work for customers; our method, Contextual Inquiry, has significant advantages, but is by no means the only way to get the job done.

Now, scientists have a bit of an advantage over designers – an unambiguous language to talk about their observations, namely mathematics.  Observations can be recorded, analyzed and shared amongst scientists using this common language.

Designers face the same challenge: they also need a language to talk about user observations.  Otherwise, discussions about user data devolve into anecdote.  To address this problem, designers have created a number of formalisms to represent user behavior for product design, including process mapping, use cases and personas.  The work models we use in Contextual Design are another example.   Although there are lots of user behavior models out there, none have both the precision and universality of mathematics, and there remains significant controversy about when and how to use these techniques – a topic for another day.

So the first step in user centered design exactly corresponds to the first step in the scientific method: observe and record.  In my next post, I’ll talk about the crucial step in both design and scientific inquiry: hypothesis creation.

One last thought.  Your third grade teacher was probably not Richard Feynmann, but I’ll bet he or she taught you that to write well, you had to first understand your audience.  Remember that?  Product design is no different – you have to understand your audience to do that well, too.

Building today’s systems requires a more intimate understanding of users’ work than ever before. Computers are smaller and more common and interfaces are more powerful. Today, many users of computers neither know nor wish to learn how the computer operates. They merely wish to get their jobs done.

In addition, vendors are under increasing pressure to develop innovative products quickly. To be innovative means to address important needs in new ways. Since existing products cannot act as a model, guidance must come from users themselves.

As the industry has recognized these challenges, practitioners are looking for new ways to involve the customer closely in design. This has resulted in such approaches as Joint Application Design [Wood 89], user-centered requirements analysis [CMartin 88], user-centered design [Norman 86], and many participatory design techniques [Greenbaum 91, Schuler 93] including our own Contextual Design [Beyer 93].

These customer-centered design approaches make the customer, and the understanding of the customer, the center of design activities. The two primary questions such approaches address are:

• How do I understand the customer?
• How do I ensure this understanding is reflected in my system?

Understanding the customer is hard. Design teams need extensive, detailed information about customers and how they work to build systems that support them well. The first requirement on any customer-driven process is to build awareness of the customer into the design team, and continue providing customer feedback throughout the life cycle.

But even given customer data, we have found that it is still hard to build a system in response. It requires a series of conceptual leaps to go from facts about the customer to a system design. How can we turn facts into a system we know will be useful?

Finally, no system is built by a single individual, but the quality of the system is the result of individual actions. How do teams develop the same understanding of the customer, and the same vision for the system? How can we manage the interplay between people to that end?

Contextual Design is our approach to bringing customer data into design through a well-defined sequence of activities. Whiteside, Bennet and Holtzblatt laid the foundations for Contextual Design in 1988 [Whiteside 88]. We have since used and extended this process in developing both hardware and software products, in small groups and large, at multiple companies.

Here, we summarize our experience with customer-centered design. We describe the steps that we have refined through our work on design problems. We describe the reasons for each step, and draw out the implications for managing the design process.

Understanding the Customer

Our first concern is to bring valid, useful data about how people work into the engineering process. The system we provide will support and constrain how people work [Holtzblatt 93]. We need to understand work in enough detail to know what the system must do to support work well, and what innovations will streamline the work.

Finding out about work is hard. Not only are developers building for users doing unfamiliar work, but users themselves have difficulty saying what they do. People are adaptable and resourceful creatures-they invent a thousand work-arounds and quick fixes to problems, and then forget that they invented the work-around. Even the detail of everyday work becomes second nature and invisible.

The users cannot say what they really do because it is unconscious-they do not reflect on it and cannot describe it. The defined policy for an organization is no longer representative because it no longer reflects what is really going on.

Contextual Inquiry

How can we get detailed information about how people work when they cannot articulate it on their own? Holtzblatt’s approach [I] was to adapt ethnographic research methods to fit the time and resource constraints of engineering. The result was the first step of our process, Contextual Inquiry.

Contextual Inquiry provides techniques to get data from users in context: while they work at real tasks in their workplace. In a contextual interview the interviewer observes the user at work and can interrupt at any time and ask questions as an outsider: “What are you doing now?” “Isn’t there a policy for this?” “Is that what you expected to happen?”

Confronted in the moment of doing the work, users can enter into a conversation about what is happening, why, and the implications for any supporting system. The user and interviewer discover together what was previously implicit in the user’s mind. Talking about work as it happens, artifacts created previously, and specific past projects reveals the user’s job beyond the work done on that day.

A contextual interview usually takes from two to three hours. Typically several members of a design team interview several customers at the same site simultaneously. We get a view across a whole organization in half a day.

We recommend that a product’s designers conduct interviews. Great product ideas derive from a marriage of detailed understanding of a customer need with an in-depth understanding of technology. In our experience, the best products happen when the product’s designers are involved in collecting and interpreting customer data This field gathering technique has been extremely successful at collecting detailed data about work practice which is hard to elicit any other way.

• Gather data through interviews with your customers in their workplace while they work.
• Put the people making design decisions in front of the user.

Involving the Customer

What is the best way to involve the customer in the design process? We certainly want to build the best system for them we can. But we also want to optimize both development time and the customers’ own time.

As outlined by Muller in [Muller 93], customer-centered techniques tend either towards having the designer participate in the user’s world, or having the user participate in design activities. We find both approaches useful, but want to ensure the user is as effective as possible in both roles.

When we participate in the user’s world, we want them to show us their world so well that we know it. We want our foot to be sore where their shoe pinches.

Working with users in their workplace helps them in this. Whenever they are working on or describing their real problem, users are much more eloquent than when talking in generalities. The impact of the real situation is much greater.

Conversely, when the user participates in design activities, we want to make them strong participants in the design process.[II]

In our experience, customers are at disadvantage when brought into a design meeting. The user’s unique contribution is their real work experience. Taken out of their work context, they are much less able to represent real experience [Whiteside 88].

Worse, as a representative of the user community, we ask them to discount their own actual experience. Instead of allowing them to stand for “what I need” we ask them to stand for “what all users would want.” They become just one more designer among designers.

Customers are at a disadvantage when building data models or other specialized models with the design team. This requires that they learn an unfamiliar language and translate their experience into this unfamiliar language. Even if we work from the user’s artifacts, the language represents an abstraction of what they do. The user must translate it back into specific instances to understand what it means [Ehn 91a, Holmqvist 91].

Customers are at a disadvantage when brought into our laboratory and asked to work on an unfamiliar problem. Once again we take them away from the context that ties them to reality. We ask them to imagine what their work is like without any of the reminders they use daily to do their work.

Instead, in Contextual Design we build on our users’ strengths by doing all our work with them in their own context, on their own problem. (Or get as close to this ideal as possible.)

If we wish to validate a model of how they work, we do not show and walk through the model with them. Instead, during an interview about their own work practice, we respond to their description of their work by drawing a picture. This picture is one of our models which responds immediately to what they just said about their own experience. It is a conversation aid, not something to be learned.

If we wish to co-design with a user, we take a previously developed prototype to their workplace (as discussed below). We invite them to work through their immediate work problem using the prototype. Users respond directly to the prototype as though it were real and give much better feedback than would be possible in a meeting room [Knox 89].

Even when we must use a laboratory for practical reasons, we recommend that users bring in their own work and try to do it in the lab. Even if we lose the context provided by their workplace, they are familiar with their own problem and it helps them reconstruct the missing context.

• Use your users well. Let their own context strengthen them.

Affinity Diagrams

As an interviewing process, Contextual Inquiry successfully extracts data about customers’ work in detail. However, one developer talking to one user is insufficient:

• The whole team needs to understand what happened with the customer;
• The whole team, including the interviewer, must understand the implications for the design;
• Different people have different perspectives and will see different implications in the data;
• Data from multiple users must be brought together;
• A working team will typically have many demands on their time. Not everyone will be able to go on every visit.

To bring the team together, share the data, and develop interpretations which the team buys into, Contextual Design includes an affinity diagramming process [Brassard 89].

The team, or a subset, sits down together and goes over the transcript or notes of each interview, writing facts about the user, interpretations, design ideas, and questions on Post-Itª notes. After the first round of interviewing is complete (usually 5-8 interviews or 400-600 notes), the team organizes the notes into clusters on a wall. These clusters are named and collected into higher-level groupings. (This entire process is fully described by Holtzblatt and Jones [Holtzblatt 93]).

An effective affinity avoids using standard categories to cluster notes. We ban terms like “usability” or “quality.” This forces the team to think deeply and creatively about the data, and forces the name of the group to represent what is really there.

For example, an affinity we built to understand object search mechanisms has a top level note labeled “The user’s purpose.” The cluster names beneath it tell what the user’s purpose in searching the object system might be: “Find a particular object,” “Understand the structure of the system,” and “Reuse existing objects.” Under each of these headings are the cluster of individual notes defining the category. Later, we could read the affinity, understand these as the user’s three primary motives, and ensure our design supported each well.

Group interpretation allows other members of the team to be brought back into the conversation. On real teams, it is rare that everyone can be in every meeting. By participating in interpretation sessions or in building the affinity, team members can be brought back into contact with the customer and can also provide their own unique perspectives on the data.

When done, we walk the affinity saying what each part is about and brainstorming design ideas for that part. These ideas can be attached directly to the affinity itself. Later, when we pick up these ideas to develop, they will be directly tied to the customer data which sparked them.

An affinity captures our insight into the customers’ work. The cluster names represent this insight and tie it back to data from individual customers through the individual notes in each cluster. The affinity organizes data across multiple customers and shows where the data is weak.

• Interpret customer data together, as a team.

The Think Tank

We prefer to dedicate a room to the team design effort. We are writing down an enormous amount of information about the customer. The affinity diagram and work models (described below) represent everything the team has discovered, structured for easy understanding. Keeping them on the wall means that the team is literally surrounded by their data about their customer.

Given the opportunity, the team will continually return to this data throughout the design process. It is common in our meetings for a team member to gesture or walk over to a part of their affinity to support a design idea. It is hard to achieve this kind of fidelity to the customer when the data about the customer is tucked away, out of sight.

The room also acts as a living record of the design process. A team member or manager who wants to catch up can browse the walls on their own, or another team member can use the walls to tell them what has happened. One manager told us he prefers to use the room to find out how the team is doing-he found it more immediate and more real than a status report or presentation.

• If you want your team to be creative, give them a room.

Work Modeling

The affinity organizes our data in a way which is easy to understand, and captures all the detail well. But to understand the structure customers put on their work, we also draw diagrams.

These diagrams, work models, show the work of a single person or of an organization. They explicitly represent roles, flow of communication and information, work tasks, steps, motivation, and strategy of the work. Where there are problems in the work, they are shown directly on the model. Unlike a list of findings, requirements, or wishes, work models show how all aspects of work relate to each other.

We find four types of work models to be generally useful:

Context Models (figure 1) show how organizational culture, policies, and procedures constrain and create expectations about how people work and what they produce. Context work models represent standards, procedures, policies, directives, expectations, deliverables and other constraints.

The context model shows what part of the work can be changed by introducing new technology, and what changes affect people or organizations who are not customers. Changing their work is always more difficult. Where an organization has standard procedures, we can design the system to support them directly, automating where possible.

Physical Models (figure 2) represent the physical environment as it impacts the work. To the extent they can, people structure their environment to support the work; then they work around any problems put in their way by limitations in the physical layout, location, hardware configuration, or technology. Physical work models show the physical space and systems that affect the work.

Physical models reveal whether the work is split between locations and the system could simplify work through direct communication. They reveal whether the work involves moving around, and whether the system must also move or must provide artifacts that move. And they show the range of hardware, software, and network platforms that the system must support.

Flow Models (figure 3) represent the important roles people take on. A role is a set of responsibilities and associated tasks for the purpose of accomplishing a part of the work. Roles may be formal or informal, growing out of the work itself. One person usually fills several roles, and roles can be filled by several people. Each role represents a different type of customer of our system. When a user interacts with a system, they are trying to meet the responsibility their role defines. The flow model shows what is needed and what is supplied in filling a role. Flow models also show the communication and coordination between roles, and the flow of artifacts between roles.

The flow model shows communication across a whole work domain, not only among current users of a system. This reveals new, unrecognized roles that could be supported by a system. It also shows the needs of people who will never be direct users, but depend on the system for information. With this knowledge, the team can build a system which better supports them.

As a language, flow work models say: think about roles. Define what their responsibilities are. Define how each role communicates with others, and what they communicate. You must know these things to understand work.

Someone building a flow model cannot help but ask questions about roles, their responsibilities, and how they communicate. The modeling language itself guides the designer in what to pay attention to. Conversely, anything the language cannot express is easy to ignore.

Other languages, such as data flow diagrams or object models, exist to support other conversations about systems. They make explicit the concepts needed to support these other conversations. For example, data flow diagrams talk about the flow and transformation of data. These other languages do not support or guide the conversations we want to have about work.

This is why we introduce new modeling languages, despite the large number that exist. Thinking about work is difficult; thinking about how a system supports work is difficult. The languages we introduce in work models and in user environment design below, tell the designer what to pay attention to at each point in the process. No existing language does this for us.

We do not find that introducing new modeling languages confuses design teams. Our languages are simple-teams doing design work pick them up in a few minutes. We find it more powerful to introduce these languages than to make a mapping from an existing language to the concepts we are trying to express.

• Let modeling languages help you. When you must, invent new ones to say exactly what you need to say.

Work Re-design

Working with specific customers gives the team an understanding of the work of those customers. However, we want an innovative design which transforms work in new ways, and which is useful to all our customers. How do we invent such a transformation? How can we ensure we have transformed the work usefully?

This is a new conversation. Up to now we have been talking about the work as it is; now we talk about the work as it will be, when our new system is in place.

This is not a conversation you can avoid. Every system changes the work of its users. It is best to think about and design the effect you want your system to have explicitly.

We make this conversation explicit through abstract work models (figure 5). We gather all the same kind of models together: all the flow models, all the physical models, all the context models, and the sequence models which address each task. Then we build new models of each type, removing the particular details of each customer’s work and revealing its underlying structure. These abstract work models show the aspects of work that our system will support. Anything the team chooses not to represent will not be supported by the system. This abstraction allows us to meet the needs of a whole market by building on what we discovered from individuals.

Our best ideas for how to improve the work often come from seeing how a particularly thoughtful person or group has solved their own problems. We build this solution into our abstract work models and our system, so all customers can take advantage of it.

Once we have this consolidated model, we study it for problems and inefficiencies. We develop an abstract work model which brings together data from all customers, keeping good ideas, fixing problems, and using technology to combine and remove steps. When done, we have a statement of how our users will work, if we can implement the system to support it.

We validate our re-design of the work by checking it against the data from customers we have visited and through Contextual Inquiry with new customers. When interviewing new customers, we look for aspects of their work our re-designed work model cannot account for. These refine and extend the re-designed work model.

Making the work re-design conversation explicit ensures we do not do silly things unintentionally. For example, in creating a presentation, ideas move from slides to handout notes and back again as the creator tries different approaches to presenting the ideas. So a presentation system should support modifying slides and notes in parallel. Providing a notes facility which does not allow the slide to be changed, as some commercial systems do, is not enough.

We verify any design idea against the re-designed work model to ensure that it fits into the users’ job well. We use it to see that the new work practice our system will support hangs together. We anticipate new problems our changes may cause, and prevent them.

Taken together, abstract work models are a coherent statement of who our customer is. We use this statement throughout the rest of the design process.

• Design the way you want to change your user’s work on purpose, or you will do it by accident.
• Your customers are your best source of ideas. Steal from them where you can.

We test the design with paper prototypes, inspired by Kyng [Kyng 88, Ehn 91]. These are rough mockups of the user interface drawn on Post-It notes and paper. We take the prototypes to the users’ workplace and ask them to pretend it is a system and to work with it. They are trying out their real work using the prototype, so they can react as they would to a real product. We observe and probe in the same way as a contextual interview.

We do not have to tell our users what level of detail they should respond to-the roughness of the prototype does that. If we present a prototype running on a computer, they respond to details of the look and the layout. If we present a hand-drawn prototype on paper, they respond to the structure and function in the system.

We start with very rough prototypes and encourage users to explore, trying to accomplish a task of their own. When they ask if the system does something we design on the spot: “Yes. How would you expect it to work? Show me.” The user sees that the design is incomplete and open to change, and is drawn into the design conversation. (This requires designers to run the interview, to respond appropriately and to design with the user.)

This kind of rough prototyping tests our user environment design. We can see whether the structure and function we provide is useful. Users can respond to the prototype without learning the user environment language.

The user environment design successfully predicts how users will react to a given interface. Where an interface is unfaithful to the design we have found that users reject it. For example, one interface we tested merged focus areas in the user environment design. The users’ comments indicated they were rejecting it because the interface mixed unrelated work, just as predicted by the user environment design: “I don’t want to know all that-take it away!”

As the user environment design stabilizes, we start to care more about the user interface. We build more careful prototypes, and in our customer interviews ask our users to live with the limitations of the system we designed. Finally, it becomes useful to build and test running prototypes that can evolve into the real system.

• Structure your system first. Then make it real in the user interface.

Iteration with Customers

Customer iteration is a powerful team design technique. When we can produce an idea, develop it, prototype it, test it with customers, and validate, modify or discard it within forty-eight hours, we can stabilize a design very quickly.

When team members advocate different design solutions and the best is not clear from the customer data, it is often more efficient to prototype and test the alternatives than to try to reach consensus in the team. Team members let go of ideas more easily when they see users react badly to them than when another team member rejects them.

We use customer iteration from work modeling through system delivery. We visit new customers after building abstract work models to ensure the abstraction holds for them. We build rough prototypes of user environment designs to test that our system structure works. And we prototype the user interface and early system versions to ensure we are being true to our design and have not broken it in the implementation.

Furthermore the development process itself is iterative (as recognized by Boehm [Boehm 86], Booch [Booch 86], and others). The insights we gain from working with users on prototypes cause us to modify our understanding of their work and our re-designed work models. We get quickly to an initial system design for a small part of the problem, but return to earlier steps to incorporate new information and to expand the system to new areas. The quick design of a part of the system gives the team a sense of accomplishment.

• Iterate with your customers. Iterate, iterate, iterate.

Conclusion

One participant in our design process said to us afterward, “It was cool, but it was also structured. I always knew what to do.” Along with producing good results, this should be the test of any design process: it should make people feel that they can be creative and move rapidly, but also that, at every point, they know what to do.

Too often, a methodology feels like a straight-jacket. Structure need not conflict with creativity-in providing a clear path forward, the right structure should set people free to be creative. Too often, this does not happen. When we combine customer-centered design with creative team processes, it does not have to.

Footnotes

[I] Contextual Inquiry was developed by Karen Holtzblatt in 1986. Sandy Jones assisted in developing the first course on Contextual Inquiry in 1988. Since then, Holtzblatt and Beyer have built on Contextual Inquiry to address the full design process.
[II] We are indebted to the work of Pelle Ehn, Kim Madsen, and others at Aarhus University for inspiring our approach.

References

[Beyer 93] H. Beyer and K. Holtzblatt, “Contextual Design: Toward a Customer-Centered Development Process,” Software Development ‘93 Spring Proceedings, February 1993, Santa Clara, California.

[Boehm 86] B. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer. 21(5), 61-72, 1986.

[Booch 86] G. Booch, “Object-Oriented Development,” IEEE Transactions on Software Engineering. SE-12, 1986.

[Brassard 89] M. Brassard, Memory Jogger Plus, GOAL/QPC, Methuen, MA, 1989.

[Carter 91] J. Carter Jr., “Combining Task Analysis with Software Engineering for Designing Interactive Systems” in Taking Software Design Seriously. John Karat (Ed.), p. 209. Academic Press, NY, 1991.

[Ehn 91] P. Ehn and M. Kyng, “Cardboard Computers: Mocking-it-up or Hands-on the Future,” in Design at Work, J. Greenbaum and M. Kyng (Eds.), p. 169. Hillsdale, NJ: Lawrence Earlbaum Pub. (1991).

[Ehn 91] P. Ehn and D. Sjšgren, “From System Descriptions to Scripts for Action,” in Design at Work, J. Greenbaum and M. Kyng (Eds.), p. 241. Hillsdale, NJ: Lawrence Earlbaum Pub. (1991).

[Greenbaum 91] J. Greenbaum and M. Kyng (Eds.), Design at Work: Cošperative Design of Computer Systems. Hillsdale, J.J.: Lawrence Erlbaum Associates, 1991.

[Holmqvist 91] B. Holmqvist and P. B. Andersen, “Language, Perspectives and Design,” in Design at Work, J. Greenbaum and M. Kyng (Eds.), p. 155. Hillsdale, NJ: Lawrence Earlbaum Pub. (1991).

[Holtzblatt 93] K. Holtzblatt and S. Jones, “Contextual Inquiry: A Participatory Technique for System Design,” Participatory Design: Principles and Practice. Aki Namioka and Doug Schuler (Eds.), Hillsdale, NJ: Lawrence Earlbaum Pub. 1993.

[Keller 92] M. Keller and K. Shumate, Software Specification and Design, John Wiley and Sons, New York, 1992.

[Kensing 91] F. Kensing and K. H. Madsen, “Generating Visions: Future Workshops and Metaphorical Design,” in Design at Work, J. Greenbaum and M. Kyng (Eds.), p. 155. Hillsdale, NJ: Lawrence Earlbaum Pub. (1991).

[Knox 89] S. Knox, W. Bailey, and E. Lynch, “Directed Dialog Protocols: Verbal Data for User Interface Design,” in Human Factors in Computing Systems CHI ‘89 Conference Proceedings, May 1989, Austin, Texas, p283.

[Kyng 88] M. Kyng, “Designing for a Dollar a Day,” in Proceedings of CSCW’88: Conference of Computer-Supported Cooperative Work (pp. 178-188). Portland OR. New York: Association for Computing Machinery.

[CMartin 88] C. Martin, User-Centered Requirements Analysis. Prentice-Hall, Englewood Cliffs, N.J., 1988.

[JMartin 92] J. Martin and J. Odell, Object-Oriented Analysis and Design, Englewood Cliffs, NJ: Prentice Hall, 1992, p121.

[Muller 93] M. Muller, D. Wildman, and E. White, “Taxonomy of PD Practices: A Brief Practitioner’s Guide,” in Communications of the ACM, V36 N4, June 1993.

[Norman 86] D. A. Norman and S. W. Draper (Eds), User Centered System Design. New Jersey: Lawrence Erlbaum Associates, 1986.

[Pugh 91] S. Pugh, Total Design, Addison-Wesley Publishing Limited, 1991.

[Schuler 93] D. Schuler and A. Namioka (Eds.), Participatory Design: Perspectives on Systems Design, N.J.: Lawrence Erlbaum Associates, 1993.[Seaton 92] P. Seaton and T. Stewart, “Evolving Task Oriented Systems,” Human Factors in Computing Systems CHI ‘92 Conference Proceedings, May 1992, Monterey, California.

[Whiteside 88] J. Whiteside, J. Bennett, and K. Holtzblatt, “Usability Engineering: Our Experience and Evolution,” Handbook of Human Computer Interaction, M. Helander (Ed.). New York: North Holland, 1988.

[Wood 89] J. Wood and D. Silver, Joint Application Design, John Wiley and Sons, New York, 1989.

One of the most difficult obstacles for the beginner in object-oriented techniques is simply getting started: where do the initial objects come from? Given this set it is easier to go on, but how are these first objects identified? This is the first step of object-oriented analysis (OOA) and the most difficult.

Our approach to the question grows out of our experience with customer-centered design.[I] We were dissatisfied with existing heuristics for OOA, feeling a better-defined process was needed. Customer-centered design requires designing the system as a whole to understand its impact on its users’ work. With a customer-centered approach to system design it was surprisingly easy to move to an object-oriented implementation.

We believe the system design step is key to getting started on analysis and design of the implementation. Here we show why, and describe the approach we take to system design. We show in some detail how our approach generates an initial object model.

The Problem

To analyze the underlying issues in the identification of objects in OOA, we will take one example from Rumbaugh: the Electrical Distribution Design System case study in Object-Oriented Modeling and Design (p433). This example is convenient because the book is popular and generally available. Rumbaugh’s approach is careful and ordered, and he makes a point of separating true requirements from design decisions disguised as requirements. We can expect this example to be cleaner than might be usual in real life.

Rumbaugh defines the front end of the software life cycle as follows:

Analysis: A precise, concise, understandable, and correct model of the real-world. Models the real-world system so that it can be understood. The successful analysis model states what must be done, without restricting how it is done, and avoids implementation decisions. (p148)

Design: The high-level strategy for solving the problem and building a solution. System design includes decisions about the organization of the system into subsystems, the allocation of subsystems to hardware and software components, and major conceptual and policy decisions that form the framework for detailed design. (p198)

One requirement for the proposed system is: “The system must permit portions of a design to be locked for periods of extended work. These extended duration locks permit work that may last for days or weeks, in contrast to the ordinary database transactions that complete in a matter of seconds.” So several people are expected to work at the same time, and to keep them from updating the same design and losing each other’s changes we introduce locks to keep others out. (Though we pick out this one requirement, almost any of the functional requirements would serve for illustration.)

What kind of a requirement is this? Is it a statement of user need, a statement of what must be done, or a design to implement the need? An alternative design might lock nothing, and provide for merging diagrams. Another might make all updates visible to every user immediately. So this requirement embodies a design choice. Why was this choice made, and no other?

Taking each alternative in turn, it seems clear this is not a statement of user need. The user need behind this requirement might be stated, “multiple people shall use the system simultaneously without getting in each other’s way.” But this is too vague to base a system on. What does it mean to stay out of each other’s way? Is it acceptable to lock a design indefinitely? Would simultaneous update be frustrating? Is merging diagrams possible, given the kind of updates people make?

Then is this a statement of what must be done? It could be considered a statement of what the system must do. But the lock is not part of the real world. We cannot walk around these people’s offices and see locks. Analysis is supposed to model the real world, so where did these locks come from? It seems that in saying what the system is to do, we must start from an implicit system design. This requirement describes one aspect of that design. But where did this design come from? What design activity supported its creation?

If it is a design, is this requirement really describing an aspect of the “design” phase of development, and is it out of place? It says nothing about how locking is implemented. “Design,” as defined above, makes decisions about the system implementation. It does not determine basic features the system will deliver.

The above definitions of analysis and design put us in a bind. We can state requirements so exactly that we make design decisions, without the support of any explicit design activity. Or, we avoid making design decisions and state requirements so vaguely we cannot know how to meet them.

Design choices come from design activities. If this requirement embodies a design choice, some design activity must have preceded writing the requirements for the system. Let us call this implicit design step system design-the activity which determines what the system must do as a whole, and how it will fit into the work of its users. Typical requirements capture some user needs and some parts of the system design, without making the whole design explicit.

When did this design happen? How was it produced? How is it represented?

The statement of requirements does not represent a design. It is only a list of parts. An architect cannot design a house using a list, but must use a floor plan. An electrical engineer cannot design a circuit from a list, but uses a circuit diagram. In the same way, a software engineer cannot design a system from a list-we must have a way to represent the system. This representation must show the whole system, the parts, and how the parts relate to each other. This representation makes the system coherent.

System design must precede analysis, because, as we have seen, the requirements embody this design. But the standard software life cycle models, of which Rumbaugh is only one example, include no such step. Why is system design not recognized?

System Design: The Missing Step

In looking for answers to this question, we found Keller and Shumate’s book, Software Specification and Design, extremely enlightening. Figure 1 shows their description of the system development process, slightly simplified.

Here is our system design step, explicitly called out. It is a separate step that precedes software requirements analysis. Keller and Shumate in their book on software, cover all the shaded areas including both Systems Engineering and Software Engineering. By this model, development of a software product does not start with “Software Requirements Analysis.” The necessary first steps are “System Requirements Analysis” and “System Design.” (And, of course, system requirements analysis itself depends on understanding the user needs the system is to meet.) Removing the hardware component of the system does not remove the need to design the system as a whole before designing the implementation.

The analysis and design phases of software engineering, as defined above, only cover the portions of the figure labeled Software Engineering. In fact, there are two preceding steps: one to understand the users’ needs, and one to design a response to those needs. This is why requirements specification is still something of a mystery-the system design step is hidden.

This is also why identifying initial objects is a mystery. Object-oriented software requirements analysis does not describe the real world. It describes the system design, an invented response to user needs. The objects identified by the analysis model are those found in the system design, not those from the real world.

This framework explains our example above. The statement that work may last for days or weeks describes a user need. The decision to use locks is part of the system design. The lock is a part of the solution, introduced to handle a specific need. Software analysis will identify the lock as a potential object for the implementation.

The traditional terminology for software development confuses the system design and software analysis steps. This clarifies an ambiguity in Rumbaugh’s definition-how can analysis model the real world and also state what the system must do? If the analysis model includes a new concept such as a lock, it is not modeling the real world. In Keller and Shumate’s framework, deciding what the system will do is the task of system design, a separate step.

Because of this confusion, current approaches to system development do not support system design well. As a result, it happens informally and is captured indirectly, as in our example. Non-traditional approaches, such as Jacobson’s Use Cases, come closer to considering the whole system design, but do not represent the design explicitly.

To design systems that work, system design must be an explicit step. To be a step in the software engineering process means that it must be driven by the results of the previous step, understanding the user. There must be well-defined formalism for recording the design. And there must be a clear way to drive software analysis and design from the system design.

Our Approach to Formalizing Design

In our approach to customer-centered design, we made system design an explicit step and developed a representation for it. The system design is constructed from detailed user data and verifies that we meet our users’ needs well. (How user data drives the system design is described in more detail in Beyer ‘93.) It also acts as the basis for the implementation. Providing an explicit representation of the system design makes object-oriented analysis easier.

Figure 2 shows the design of a simple mail system. It is organized into focus areas. Each focus area collects everything necessary to one part of the work-the functions users need along with the objects they work on to perform a particular activity. These “work objects” represent those objects users are conscious of, manipulate, and think about in performing their work. They do not represent objects in the implementation-there will be other objects, necessary to support the implementation, which are not shown because users are not conscious of them.

Arrows show how the user can move between activities in the system as they perform their work. They do not represent flow of control or data. They show how the system supports the users’ shift in attention between activities in their work. (This formalism is described in Beyer 93 and Holtzblatt 93).

The system design structures the system and describes how it will meet user needs. The next step, object-oriented analysis, pulls objects directly out of our system design formalism. The following discussion shows the details.

Entity Object Derivation

We find it useful to consider three distinct types of objects in a system’s object model: entity objects, which represent static data, interface objects which define the user interface, and control objects, which define system processing. This division of objects is similar in essence to many others’-the model-view-controller paradigm of Smalltalk (Goldberg), Jacobson’s ObjectOry (to whom we are indebted for our terms), Normand’s division of objects into “core,” “adapter,” and “interface,” and Berard’s identification of “interface” and “design” objects.

The initial entity objects of the analysis model are the work objects of the system design. Work objects may appear in several focus areas. Analysis brings them together in a unified definition, as in the single definition of the Message object in figure 3. (In the figures, we have shown only a few focus areas for clarity.)

Services of the entity objects correspond to the functions performed on the objects in the different focus areas. Here, the Send function becomes the Send service on the Message entity object. Attributes and relationships of the objects are derived from the function and purpose of the focus areas-e.g. the Display Status function implies that a message has a status attribute.

Interface Object Derivation

Products usually need to run on several user interface platforms. We also want to separate the user interface code, which is subject to frequent change, from more stable parts of the system. For both reasons, we separate the code which is specific to a user interface platform from that which can be common across all platforms.

A common approach is to clearly identify the part of the object model specific to all platforms, and distinguish it from the part which implements a specific platform user interface. These two parts of the system communicate only through objects which hide the details of each from the other. (See, for example, the functional core adapter in the Seeheim model [Pfaff 85]).

In our model, these intermediary objects correspond directly to the focus areas themselves. Because a focus area supports a coherent task, each focus area maps to a coherent part of the user interface, such as a window, screen, or pane. User interface design determines which. In the object model, each focus area generates an object which interfaces between the platform-independent part of the system and the implementation of this part of the interface. The implementation can change from window to pane to screen, without any of the rest of the system being affected.

In figure 4, Composition implements the Compose Message focus area. It mediates between a user interface implementations-either Motif or character-cell, in this example-and an entity object, Message. (A complete model would show additional objects and services.) The user interface objects know nothing about the implementation-they only know what service they invoke in Composition. Core objects know nothing about the interface-they only receive messages from Composition. Composition is an intermediary encapsulating all state having to do with the organization of the user interface, without being specific to any platform.

Control Object Derivation

Control objects represent processing done by the system. The initial set of control objects correspond to hidden focus areas, which have no associated user interface. The function of the hidden focus area defines services. State information needed to track the progress of the work defines attributes. As the details of the system implementation are fleshed out during software design, additional control objects will be identified.

In our mail example, the Send function uses store-and-forward semantics. Our system design indicates this with the hidden Send Mail focus area. The Send service on Message objects creates a Send-In-Progress control object representing that the message has been sent but not yet received. This object has Send and Update Status services, and a Status attribute to indicate whether the message is pending, has been rejected, or has been sent. This design separates the algorithms used to implement store-and-forward from the message itself. These algorithms can change independently from the implementation of messages.

Once the system is designed and initial objects are identified, existing object-oriented approaches will serve to complete the design of the implementation. The above example shows how a system design can drive such object-oriented design.

Conclusion

The above reasoning leads us to the conclusion that today’s most common framework for thinking about the phases of software development is flawed. The steps we believe necessary are: understand user needs in detail; design a system to meet those needs; analyze the design to understand how it may be implemented; design the implementation in detail; build; and test. The system design step has no place in the traditional framework.

The description of software development which fits this framework most closely is that of Keller and Shumate. They make it clear that the critical decisions about what the system will do happen during system design. But this step is not generally made real or explicit. It is hidden, confused with other steps, and poorly supported by current approaches.

Making system design real for software is a large project. Our customer-centered approach is one example of making it a real and concrete step. Other individuals and organizations have also recognized system design as an activity and a discipline. The Association for Software Design has been formed to find ways to make the design step an accepted part of software engineering. Companies are starting to recognize design skill as critical to the development team and distinct from traditional software engineering.

System design ensures that the system works well. It is also the basis on which the rest of the development process builds. The software life cycle must make room for it.

Footnote

[I] Contextual Design, developed by the author and Karen Holtzblatt.

References

[Berard 93] E. Berard, Essays on Object-Oriented Software Engineering, Volume 1. Prentice Hall, 1993.
[Beyer 93] H. Beyer and K. Holtzblatt, “Contextual Design: Toward a Customer-Centered Development Process,” Software Development ‘93 Spring Proceedings, February 1993, Santa Clara, California.
[Goldberg 83] A. Goldberg and D. Robson, Smalltalk-80: The Language and its Implementation. Reading, MA: Addison-Wesley, 1983.
[Holtzblatt 93] K. Holtzblatt and H. Beyer, “Making Customer-Centered Design Work for Teams,” Communications of the ACM, (forthcoming).
[Jacobson 92] I. Jacobson, Object-Oriented Software Engineering, A Use Case Driven Approach. ACM Press, 1992.
[Keller 92] M. Keller and K. Shumate, Software Specification and Design, John Wiley and Sons, New York, 1992.
[Normand 92] V. Normand and J. Coutaz, “Unifying the Design and Implementation of User Interfaces through the Object Paradigm,” ECOOP ‘92: Proceedings of the European Conference on Object-Oriented Programming. Utrecht, the Netherlands.
[Pfaff 85] User Interface Management Systems, G.E. Pfaff ed., Eurographics Seminars, Springer-Verlag, 1985.
[Rumbaugh 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, N.J., 1991.

Published in Software Development ‘93 Fall Proceedings (August 1993)

Eli has provided solutions as a team manager, a project manager, and a developer in multiple markets including Publishing, Healthcare, eCommerce, Marketing, Computing Systems, and Storage. He has led the creation of repeatable, reliable processes at companies such as Iron Mountain, Upromise, Sun Microsystems, and a variety of startup companies where entrepreneurship required speed and flexibility.

Eli holds B.S. degrees in Computer Science and in Biology from the Massachusetts Institute of Technology.

Or, you have the germ of an idea you think is fundamentally new, and will create a whole new market. How do you develop it into a real design? How do you work out the details so that you have a coherent, workable specification for something that will set the market on fire, given that no one has ever seen this kind of thing before?

In our work with organizations around the country, we have seen product teams struggle with both these issues. We specialize in coaching cross-functional teams in customer-centered design-the design and development of systems starting with understanding customers in their workplace and involving customers continuously throughout development. People who are not working from customer data often tell us that whatever merit our approach may have, it can help in neither of the above situations. Customers can’t give you totally new inventions; customers can’t imagine what their lives might be like if you gave them a tool they’ve never seen before. One company we know is proud of not allowing designers to talk to customers, because talking to customers would stifle innovation.

This attitude has always struck us as odd. How can you know where to innovate if you know nothing about your customers? How can you know whether anything will work in practice if you don’t develop it with your customers?

What makes creativity work?

The Invention of the Spreadsheet

Let’s look at an example of creative design in software as a test case. Arguably the single most creative act in software design was Dan Bricklin’s creation of the spreadsheet. This invention created an entire market out of nothing, spawned dozens of look-alikes, opened computer use to an entirely new set of people, and changed the way we approach whole classes of problems. How did he do it? [I]

Bricklin’s background was in interpretive systems and in typesetting and word processor design-he worked on the software that became WPS-8. In the early 80’s he decided to go to business school, and in class after class he saw people struggle using spreadsheets to represent business problems. Apple was coming out with their first computer about this time, and as he sat in Aldrich 108 he began to daydream about the possibilities of the new technology.

A heads-up display, with a keyboard that moves-the display shows an accountant’s spreadsheet and as you move the keyboard, your focus shifts from cell to cell. Typing enters numbers and formulas and the formulas immediately recalculate the values in cells as you type.

The vision was there. Then came the reality of making it work. The Apple II couldn’t give you a heads-up display, or tie keyboard movement to screen position, so Bricklin made do with the Apple’s display and cursor keys (after trying and rejecting the joysticks as input devices). Throughout the development process Bricklin worked with his user community. He talked to the professors in each of his courses; he had people try the new tool on their own problems, testing as many different kind of problems has he could.

He never lost sight of his users and he never lost sight of his major competition: the back of an envelope. If people could do their thinking on the back of an envelope faster than in his tool, they’d never use his tool. Setting up and manipulating a spreadsheet had to be fast and natural.

Lessons learned

What can we take from this story about how to encourage creativity in software design? Lessons that jump out at us, and which are borne out in our experience, are:

• Creativity comes from putting the technologist in the middle of the users’ problem. Bricklin was primed with knowledge of technology, especially interpretive systems (key to the idea of recalculating formulas) and visual representations of data (from the word processing work). And by going to business school he put himself in the world of his future users.
• A creative idea jumps out as a whole, not as a string of incremental features. It may take longer to sort through and refine, but the initial flash of inspiration delivers the whole package. Inspiration is holistic, not analytic.
• Creativity starts with a wacky idea. Heads-up displays, moving keyboards-these aren’t close to commercially available even now, ten years later. Maybe they’ll never be available. Maybe they aren’t even a good idea. And yet, intermingled, was an idea that could be implemented and would change the world. Bricklin didn’t just have the idea, he dared to go for it.
• Despite this, the creative idea is obvious-after it’s explained to you. Of course you can put a spreadsheet on the computer-computers add and subtract, no surprise there. Bricklin says programmers couldn’t understand what the excitement was about. It was the users who saw that there was a new thing in the world.
• Creativity is driven by stealing ideas from customers. Spreadsheets pre-existed VisiCalc by centuries-introducing a computer took the drudgery out, transformed what people could do, and radically changed how business people work today.
• Creativity doesn’t stand alone. It requires development with users. Iteration with users and trying to solve different real problems with his tool was critical to working out Bricklin’s ideas. Even focusing on the competition-the back of the envelope-was a way of concentrating his user focus.

Roadblocks to Creativity

Put the technologist in the users’ world-this is simple. So why aren’t more organizations doing it? Why do organizations put process in place which stifle creativity? In our work, we’ve seen how organizations create mind-sets which prevent them from being creative:

People separate “requirements gathering” from system design. There’s a myth in the industry that these are separate activities. They’re not. Creative design is an immediate response to recognizing a need and the knowledge of a technology that addresses that need. Separating these activities across organizations or people stifles creativity every time.

People think about product design as a list of features. They think about a new version in terms of what features to add. They think about their competition in terms of what features the competition has that they don’t. Teams we work with generally start with ideas for specific features, each responding to a single customer problem. These can only lead to incremental change and “feature creep.” Working with customer data to represent the customer’s whole work situation allows a team to respond with a synthesis that represents a wholly new approach. The management of one team was astounded at the change in the product design after working closely with customer data: “we thought you’d never get out of the box.”

People are scared to let their engineers talk to customers. Some are afraid of letting an unwashed engineer talk to an actual customer. Some think their engineers’ time is too valuable, or that talking to customers is someone else’s job, or that customers shouldn’t see ideas which are still tentative. (In one organization, product marketing blew a gasket because we were going to take paper mockups out to customers. Paper!) Eight years of experience taking engineers to the field shows that they are perfectly capable of working with customers. Customers love to talk about heir work and try out new designs-even when they are in paper (in the above case, they wrote an article in their internal newspaper about how their supplier came to share their newest ideas).

People are scared to work together. Bricklin combined multiple skills to see the opportunity. Products today are build by teams which could combine the diverse skills of their members to address a problem, but organizations structure themselves in ways that keep people apart. They break projects into separate units, assign “ownership” of units to individuals, define “architects” who can make decisions by fiat, define “hand-off” from one group to another, all so people won’t argue. This also means that each part of a system can benefit from the creativity of only one person. People can contribute to a common effort-if they are willing to tear down the walls and work with each other as people. One person we worked with asked the team to help him manage his tendency to dominate the meeting. This helped him to monitor himself, and gave the team permission to modulate his behavior.

People are scared of new ideas. It’s ironic in an industry with as much turnover as ours, but that’s what we see. Individuals won’t put new ideas on the table: “It’s different, and no one else is thinking of it, and maybe it’s silly after all.” Teams won’t allow themselves to pursue new ideas: “Management has all these expectations, and it’s not in our charter, and if they find out they’ll ax us.” Organizations won’t adopt new ideas: “We are in a competitive market and can’t possibly spare the resources to pursue something that is untried.” No one can take a risk if it’s not safe to fail, and new ideas are always risky. One team we worked with was so bound up in worrying about management, they arranged a meeting with their division head. He was incredulous: “How could you think I wouldn’t support this? I depend on you for new ideas and direction.” They went back to their team room energized and started planning how to drive their organization.

People don’t want to find out their ideas don’t work. This gets especially bad when deadlines loom: “If we go find out about the customer, either we will discover new things or we won’t. If we don’t, we’ve wasted our time and we have no time. If we do, then our design will be broken and we have not time to fix it. So let’s not find out anything.” Going to customers early helps engineers let go of existing ideas, and make room for new ones. This can be fast-we sketch out a part of a system, mock it up, test it with users, and interpret the results within 48 hours. We’ve watched any number of engineers return to their teams ready for new ideas after having watched users recoil from their pet idea in horror, or dismiss it as irrelevant.

People don’t respect their customers. Some groups are invested in being experts. Taking orders from users is hard for them. You hear it in their language: “they don’t know how to use the system right,” “they don’t even get trained,” “bad user on device,” “people can’t tell you how to use a new technology.” People make reasonable trade-offs between learning tools and doing their real work. The short cuts people put in place let them get their job done. People have figured out how to live their lives and do their jobs. One team started out sure that certain cards their customers used were clumsy and unnecessary. After studying the work, they discovered the cards supported eleven different forms of communication. This was incredibly efficient, and the team switched to designing ways to support the communication directly.

Learning to Be a Rainmaker

So, if current organizational practices don’t work for creativity, what will? It may not be possible to call down the lightning, but is there a thunderstorm and a bare hill to stand on?

First, put your designers in the data-put them in front of real users while they work. Second, get the fear out of the organization-make it safe to go beyond the accepted ways of thinking. Define creativity as part of your charter-which means that ignoring turf and challenging the business that is currently making money is also part of your charter. Third, define a clear process that starts with real customer data and takes you to a shipping product. Customer data is your touchstone throughout the process.[II]

Customer-centered design is old. It’s been tried and found to work for decades-for as long as people have designed products for others rather than themselves. What’s new is that customer-centered design is now being defined, formalized, and moved into standard practice. Teams which have taken on a customer-centered approach are opening new avenues to creativity.

Footnotes

[I] Our thanks to Dan Bricklin for telling us this story.
[II] Our approach to customer-centered design is described in “Making Customer-Centered Design Work for Teams,” K. Holtzblatt and H. Beyer, Communications of the ACM, October 1993.

Published in IEEE Software 11.5 (September 1994): 106.

I coach design teams in the use of Contextual Design, a customer centered design process. When I first started this work I thought it was about how to talk to customers and use customer data effectively. But not surprisingly effective design for the customer also hinges on effective face-to-face communication inside a team.

As an observer of work practice, I have wondered why meetings are so dreaded, indicted as time wasting and considered a place where work does not happen. I have watched the development of meeting running tools to control agendas; identify clear owners and action items; formalize asking and refusing requests; and “encourage participation” through electronic voting and simultaneous individual, often anonymous, input. I have pondered the structure of “teams” which rarely work together as a team; management’s concern for clear owners of system parts, defined responsibilities and identified decision-makers to resolve conflict. I have swooned at the reams of linear text produced in the attempt to communicate a design clearly and explicitly and the review structures put in place to find out what is in them and whether they are complete.

How much of our practice comes from our difficulty talking about design in face-to-face settings? Are we creating structures and tools which limit interaction because we have trouble interacting? Are we thereby losing the coherence of our design and the best use of our people?

I am convinced that delivering a coherent system in a competitive time-frame based on understanding the customer is absolutely necessary and completely dependent on multiple people working together in a room. Here are some of the things I have learned about human dynamics and successful face-to-face team design.

Understanding is Slippery

From beginning almost until it is built a design feels like air; the understanding of the customer is air; agreements are air (that is why lawyers are so intent on “exact” words); what people say hangs in the air and is gone. What you hear from what I say is invisible to me; what I understand about what you say is hidden from you, even if we nod. Consider: The team agrees upon a design approach. They agree on the customer’s problem. They agree on a function to implement .They talk in the hall or in a meeting or on the phone. They nod, say yes and are happy. They do the agreed upon work.

“But you didn’t do what we agreed to! ”
“Yes I did! What do you mean? It’s exactly what we said!”

The team goes on a customer visit. They send around mail describing the important things. They debrief in a meeting. They have a breakthrough. They write a list of functions to implement.

“Why is that function here?” someone asks.
“The customer needs it — we talked to big company number one”
“Well my big customer would hate it.”
“My big customer must have it this way.”

Who is right? Where is the understanding of the customer?

And where is the team’s understanding of the design — on a white board, on a napkin, in the head of the lead architect, in the thick specification they are meeting daily to understand or in the unfinished one they are coding to?

Even when people get along and succeed in reaching agreement in the moment they can lose track of what was meant over time. They may search their individual notes which do not capture their shared ideas. They may call for design and requirements documents which are often hard to understand. Usually they resort to talking to people for clarification and buy-in, making the rounds one by one.

All the conversations about customers, requirements and design are slippery, happening over time and often on the fly. These conversations are the very stuff of product design. But hanging on to a shared understanding among multiple people from moment to moment is hard. So conversations happen over and over and over again.

Creative Thought is a Chain of Reasoning

People in a design meeting often feel like they are on an endless path going no where. They can leave frustrated and incomplete; angry or resigned.

Moving from customer data to a design is like moving through a set of implications. One person’s thought in a design meeting for a presentation tool might look like this:

• Make a customer observation: The slides being used in a presentation are different from what was handed out. The presenter is showing an idea in parts building it interactively as they teach one part of the idea at a time. The handouts have the final point all together.
• Hypothesize what it means: Presenting in parts maintains audience attention and makes understanding easier. But the notes to take home just need to capture the final understanding achieved acting as a memory jog for later.
• See the implications of that on how the system is impacting the work: Not everything handed out to the audience corresponds to a slide to be shown. Not every slide shown will be included in the handouts. Having to create two sets of slides or extra slides for presenting versus handouts wastes space and causes logistics problems for the user when printing or running the slide show.
• Generate a set of design ideas: Provide a print function to select slides to show versus hand out; or provide a function to code each slide for presentation only; or provide a grouping function to group different slides for different purposes
• Compare each one to a set of internal design criteria, knowledge about the system being built, other customer data and company politics: Selecting one by one is too time consuming. Tying the function to printing ignores people who run the slide show from the computer. Coding slide by slide lets the user do it in the moment as they have the intention. Letting users group slides afterward in a different view allows them to change slide shows without having to find the slide inside the show. Grouping can be used for any purpose including the creation of new slide shows out of parts. If I make the group in the outline view the user won’t have to wait for the graphics display of the thumbnail view. If I give a thumbnail peephole upon request users can use it as a browser, selector and text creator.
• Pick a design solution: Make the outliner a browser with an optional thumbnail view and allow users to create groups to print or show there.

This line of reasoning [I] shows up in a design conversation this way: “Well if the customer is doing that — we ought to put a text-based browser with optional thumbnail access into the product.” Where did that come from? The thought chain is fast and invisible so a challenge is likely. But what is being challenged: the customer observation (what happened in the field), the interpretation of the meaning of that observation (a conversation about the customers intent in their work), the implication for the system (a conversation about how the work might be changed by the system), the design chosen (a conversation about good design principles and how completely it addressed the work). Or is the challenge really because others in the room could not follow the line of reasoning. It all sped without bringing others through the reasoning process.

The chain of design reasoning is invisible even to the generator of it. Often teams members have to go over and over the points, recovering the chain of reason each picking up on a different link in the conversation. They argue with each other, not knowing they are talking about a different link in the chain. The originator feels unheard, misunderstood and irritated that they just can’t get it. Unable to end, they keep trying to get the others to see their “very simple and obvious!” point.

What’s This Meeting About?

The best thing about having multiple people in a room is they listen from many perspectives catching holes and creating new ideas. The worst thing about having multiple people in a room is they flag holes and generate ideas. Consider:

A customer observation reminds Joe that we don’t have function for it. This kicks off a function conversation which reminds Jane of an implementation problem they didn’t resolve upon which the function is dependent. This kicks off an implementation conversation. But the proposed solution shows Jim that doing it that way would constrain a function supporting another part of the customer work. This stimulates talk to resolve the inconsistency and Bill concludes that they do not have the customer data necessary to make the decision which stimulates a planning conversation for another customer visit. When multiple people work face-to-face they keep tugging on the direction of the meeting because of associative thinking. Their ideas can be good but the experience is exhausting; the team starts many things and finishes none. They called the meeting to talk about one thing and ended up talking about another, resolving few of the issues raised. There may be many good ideas but no one has closure or a sense of moving forward.

Associative thinking means the system is likely to hang together because people are examining the implications of all that is said. Each point made reveals holes in the customer understanding, inconsistencies in the design, and new possibilities for supporting the work. Multiple people listening from multiple perspectives means more will be seen and caught. But without a way to deal with associative thought, a design meeting can be destroyed. Giving up, teams may assign one person to resolve the issue alone and report back. But when the team reviews it associative thought happens again. Do they dare tangle again or do they let a hole slide for fear of the chaos?

Making Team Design Work

Understanding is slippery. Design thinking moves rapidly from conversation to conversation and associative thought drags the conversation from here to there. People get angry and irritated. They roll their eyes, tap their pens and walk out. People get frustrated and throw barbs at perceived offenders. They may refuse to meet or insist on clear agendas which allow for no deviation. People feel unheard and unvalued and slowly stop participating or simply push harder! People complain about meetings. They design in twos and threes for teams of 8-30.

But the problem of team design is about how people think not who people are; its a work problem not a people problem. Here’s what we do:

Make conversations concrete and separate them: use a separate graphic representations for each conversation in the design thought chain. This gives each conversation a language and a place and holds the team’s ever evolving agreement and understanding over time.

A good picture, or formalism contains in its symbols the key concepts and distinctions necessary for one unambiguous conversation. A picture has the advantage of being synthetic by nature; it represents parts and relationships between parts. It lets people see the whole design or understanding at once. If it is big enough, all in the room can see them. (We use pictures the size of flip charts and tables.) Diagrams makes understanding tangible and therefore able to be modified, discussed, saved and interacted with. Taken together the diagrams let a team see and separate their thoughts in a design chain as they traverse it.

Stay on the mainline conversation: start the meeting by identifying which conversation is dominant. At any point in the design process one conversation is the true center of the design work. Let a moderator keep the team on the mainline conversation.

Now each conversation is separated from the other by its symbols and by being on a different piece of paper in the room. The location of the page becomes the place (in front of the diagram) for a group to do work on that conversation. Having a physical place helps keep the team on the mainline conversation; the moderator stands in front of it. Everyone has a tangible reminder of what they are talking about. Change in the topic can be deliberate as the moderator listens for a shift in conversations and the team gravitates to a different a diagram. Staying on topic and moving quickly through a chain of reasoning both become possible.

Make room for associative thinking: give team members PostIts. Whenever a thought comes let people raise it. Knowing the mainline conversation and all the other design conversations the team can tell what conversation the idea belongs to. If it is mainline, pursue it; if not, write it down and stick it to the right conversation. (With the person’s initials for later reference. A neat result of this is that everyone feels heard and learns to self-monitor.)

Having all the design conversations physically represented in the room provides a place to put those associative thoughts so they can be addressed later when that conversation becomes the mainline. Nothing is lost and system coherence and completeness is gained.

Why It Works

When creative people are working together they usually design over an idiosyncratic or formal drawing which represents the flow and results of their shared thought . They create one “drawing” between them representing their conversation and their understanding. And they naturally move to another piece of paper or place on the chalkboard when changing their topic.

We have borrowed the informal practice of creative thinkers, defined a set of diagrams that represent the conversations in the thought chain and spread them over the walls of a meeting to support the natural flow of thought. This strategy gives the team a way to manage their meeting and a place for all their thoughts whenever they may occur.

Revealing design thought publicly and physically has allowed us to solve some of the problems of design meetings. The diagrams become the team’s conversational tool. The team learns to attend to their conversations and manage the flow between them. The team creates a living record of their shared understandings which can be returned to time after time leaving a trace of the origins of their designs from customer data. The team can stay on topic and manage associative thought without blaming each other for disrupting the meeting. And everyone has a way to be heard.

Does all this writing seem like it would bog down a design meeting? Losing track of the conversation at hand and the resulting interpersonal chaos slows teams down much more. Our inability to manage ourselves in a face-to-face design meeting is pushing teams away from the quickest and best means of using our human resources: group talk. Structure of the right kind frees us to think productively and creatively. It allows multiple people with multiple perspectives and multiple contributions to work together. We work faster, we work better, and we have more fun. What do we have to lose?

Footnote

[I] No claim to great design ideas here. Checking the line of reasoning with the customer is much of what Contextual Design is about, but that is for another column!

Published in interactions, July 1994, Vol. 1 No. 3, p. 17.

Designing products well requires a clear and detailed understanding of how people work. However design teams are not usually expert at understanding work, and there are no generally-accepted techniques for representing how people work appropriate to design. Without support for thinking about the customer, design teams tend to focus on the technology and the system delivered. In this paper, we describe the modeling techniques we have developed to represent work and show how they support product design activity.

Introduction

Any system [I] a design team delivers, in its function and its organization, structures the work its customers [II] do. This imposes the responsibility on designers to ensure they structure the customers’ work well. This requires a shift in the focus of design conversations to customers’ work and the work practice envisioned for a new system. The core challenge of customer-centered design is to enable this shift.

To understand how a system should structure the customers’ work requires discovery of the detail of how they currently work, both with and without technological assistance. Seeing behind the detail reveals what customers are fundamentally trying to accomplish, and uncovers the underlying strategy and structure that drive the work. These fundamental motives are not prone to change, but the means of achieving them can be modified and enhanced. The strategy and structure that people use to organize their work indicate what work styles are natural and can serve as an effective organization of the system. Innovation comes from recognizing these fundamental motivations and natural work styles, and enabling them more directly through the use of technology.

Typical design teams are not used to conversations about the nature of people’s work, how to re-design that work, and the role of a system in supporting the re-designed work. Most designers are not trained to understand the multiple dimensions of work practice. They are not in the habit of having explicit conversations about work practice as part of the design process. Enabling teams to do this work requires that they develop the skill and the language for these conversations.

So design teams need a language for work: an explicit representation of work practice, allowing them to record their understanding and communicate it to others unambiguously. The language acts as a “place” for the conversation to happen. It externalizes the team’s understanding, so it can be checked with each other and against the data. And it provides the symbols and syntax necessary to express important insights about the work.

In this paper, we present the language of work we have developed for our customer-centered design process [1]. This language allows us to express the rich detail about work needed to drive a design. It represents the concepts we have found, through practice, to be necessary to effective design. Using these basic concepts teams have taken on new ways of seeing work and have extended these concepts to develop other work models and variants of these to suit their problem.

We will present the language itself, and place it in the context of the design process by showing how the understanding of work it supports contributes to design.

Aspects of work relevant to design

Many aspects of work may be of interest for study and discussion depending on the purpose of the inquiry. An anthropologist, a sociologist, a psychologist, or a time-and-motion expert might each choose a different set of distinctions as important to their work. But for system design, we have identified four aspects of work which matter: intent, structure, strategy and concepts. We find out about these by looking behind the detail of work as it is done.

By intent we mean the purpose or motive that makes accomplishing a task desirable, independent of the means used to achieve it. The intent may be explicit, known and describable. Or it may be implicit, not enunciated by the customer as something they are trying to accomplish. We use “intent” instead of “goal,” a more traditional term, because “goal” implies a specific, achievable end state [2]. Often the motive driving work is not so definite. We studied a secretary who answers her boss’s electronic mail by typing his written responses into the system. Her explicit stated intent is to answer the boss’s mail. This intent is in service of a higher-order intent of making him more efficient in communicating with others. But she does not give this work, which usually amounts to typing in his written responses from paper copy, to a lower-level secretary, though she could. Through conversation, this led us to an additional implicit intent: to keep informed of what is happening in her boss’s job by monitoring his mail. “Keeping informed” is not a goal to be achieved: it is a state to be maintained.

Our study of work shows that an intent may exist in the work as a means of achieving other higher-order intents. For example, a user is searching through menus looking for a function to change line spacing. But this whole search is part of a larger set of activities in which he modifies font size, margins, and spacing. His larger intent is to give the content of each page a single theme. But this intent is driven by his structure for the brochure as a whole, in which each page expresses a single idea and the whole brochure has a distinctive, consistent look. This intent is driven by his desire to put his unique stamp on the booklet, while meeting his customer’s requirements. If we focus only on the specific behavior, we might improve the UI to make the line spacing function easier to find. But if we understand the higher-order intents driving the work we can respond with design changes that support them more directly.

The most fundamental high-level intents change very little over time. There is little we can do that will get rid of this designer’s desire to produce distinctive work. However, we can change how they accomplish this high-level intent. So we can address the desire for a consistent look through an apply-style function, which takes the style information from one page and applies it to another in a single action. This replaces all the lower-level intents driving the use of separate functions with a single function to meet the higher-level intent.

Several commercial products have provided such a copy/apply style function. This simplifies the customers’ work by eliminating the number of things they must think about to achieve their intent. The higher we go in addressing intents, the closer we get to addressing the fundamental work our users are doing, and the more creative we can be in our designs. The higher we go, the greater the impact we have on the work.

The impact we have on the work is limited by the scope of our project. If we have license to redefine the procedures by which people do their jobs, we can have a large impact on the work and can address high-order intent directly. If we are delivering an information system our ability to change the process it supports may be much more limited. If we are selling a product to a market, we are limited to changes that will be recognized as beneficial and accepted by our customers. Customers must be able and willing to make the transition to the new way of working.

Taken together, these collections of low-order intents comprise a strategy for accomplishing a higher-order intent. A strategy provides a pattern for doing work, breaking it down into manageable units. We have found that there are only a few underlying strategies to any given work task, so we can describe them even for a large market. When customers start work with a particular system, it is this strategy they are attempting to implement and that they expect to see reflected in the system. They do not necessarily plan their strategy explicitly. As they react to particular work situations, they may hypothesize what each next step should be. Or, they may have developed effective habits for similar situations, and apply it automatically. A strategy unfolds as we observe the details of how people work, seeing the steps and abstracting from them the patterns that guide the work.

Understanding the customers’ strategy guides design by showing the flow of work from action to action. The system should provide the function, access to function, and access to different parts of the system needed to support this pattern of work. By looking at the strategies of different customers, we can recognize the most effective strategies and build them into the system, making them available to all. By making strategies explicit, we can discover problems in how they are accomplished and build fixes into our systems. When the need to accomplish an entire intent is eliminated by our system, the strategies to accomplish that intent are also eliminated.

To implement strategy people put physical, organizational, or conceptual structure in place. People structure their world physically: certain tools ready to hand, organized for easy access; support material visible as necessary; less frequently used tools, material, and storage locations further away. For example, in every case of creative work we have studied, the first step involves collecting tools and reference material together to support creation. The intent of this step is to structure the environment to support the work of creation, so all the necessary materials are ready to hand. Or again, one company has as strategy for achieving their business goals to encourage community and communication between people. To implement this strategy, the company has structured their physical environment to support community. Communal break areas and reading areas encourage “hanging out” together. Work areas consist of communal places surrounded by individual offices.

Physical structure also shows where customers have to work around their environment to create structure meaningful to their work. A system can build in structure that matches. So, for example, a restrictive office environment requires a design team to hold impromptu meetings in hallways to get their work done; a restrictive file system directory structure requires users to invent elaborate naming conventions to represent meaningful relationships between files.

Physical structure gives hints for how to structure the system so that coherent activities are supported coherently, functions that are needed together are available in the same part of the system, and frequently used function is easy to access. As we support more of customers’ work on-line, we can harvest data about the structure necessary to the work and support it in the system directly, allowing users to work as they expect. Physical structure also implies strategy and intent which themselves drive system design.

People also structure their world organizationally: they partition the job among themselves to give everyone clear responsibilities which allow them to work usefully in parallel. They define expectations of how people will work, what they will do, and how they will coordinate in producing the result. In the work of developing software, we find there is always someone maintaining the integrity of the system-ensuring that the right code is included with each system baselevel to make a usable system. This person may be recognized by the organization with a job title and defined responsibilities, or it may be an entirely informal role. Either way, it is a common structure explicitly or implicitly put in place to get the job done.

Communication and coordination become part of the work any product must consider. A product which treats work as done entirely by individuals will fail. The different responsibilities show what types of work the system must support and how they are organized into coherent activities. The system can then respect the bounds of these jobs, so that it supports the work as people do it, or deliberately choose to change the structure of work to make work more efficient.

People structure their world conceptually: they make conceptual distinctions between parts of the work. These distinctions help people think about their work and how to do it. In software development we have the concepts module, version, change, baselevel, release. These concepts become the “matter” of the work-they are what people work on. Programmers work not only on modules-usually made real in the file system-but also on coordinated modifications to sets of individual modules (a “change”). A “change” may not be real in the configuration management system they are using (it is in some), but it is real in their talk and in the work.

When people work with a system, they expect to identify concepts they are used to manipulating. If concepts in their work and language are real in the system, it matches their expectations and allows users to do their work directly. If the system introduces new concepts they should not conflict with users’ existing concepts and terminology, or should be sufficiently close to the users’ expectations that they are easily learned.

These fundamental aspects of work-intent, strategy, structure, and concepts-are hidden in the detail of everyday actions. To reveal these details, we find that designers must study work as it is actually performed [3]. People do not spend their time thinking about the structure and implications of their work-they just do it. Even when a process is written down as policy, this rarely reflects what people really do, and is not sufficiently detailed to define what they do on a daily basis.

Designers can study the details of how people currently perform a task to abstract the key aspects of work from the details. From this understanding of work, designers can build an effective system. They need not duplicate current actions exactly in the system, but the details give us important clues to the natural structure and organization of work. Making the discussion of work the center of the design effort moves a team away from focusing on technology and re-centers that focus on the customer. Our approach to customer-centered design makes this conversation possible by defining a graphical language about work.

The four faces of work

We have found four perspectives on work to be useful for design. They model work with simple drawing techniques that describe the most basic aspects of work relevant to design: the culture and physical environment it takes place in, the pattern of human interaction and communication, and the basic tasks and steps involved in getting the work done. We provide separate modeling techniques, work models, to represent work from each perspective: context, physical, flow, and sequence models, respectively. Keeping the perspectives separate allows the designer to understand each aspect of work and think about design implications separately. Looking across the models allows the designer to integrate the four perspectives and understand the work as a whole.

The context model

Expectations and constraints may be embodied in business practices, such as compensation structure, reporting requirements, or the budget planning process. It is easy enough to discover explicit cultural effects. More challenging is to uncover their effect on the work, which may not be what is intended. An explicit statement that the organization values teamwork may be rendered moot by a compensation structure that rewards individual achievement. Prescribed procedures for doing work may not match what happens in practice. An organization may be demoralized by exhortations to “work smarter, not harder” with no support for changing work practice. Uncovering these effects requires looking behind the words of the explicit culture, to understand how it interacts with the work as it is actually done.

Distinctions: In the context model we describe the influencers who affect or constrain work. These may be an individual or formal group in the organization. It may be a collection of people who are not a formal group but thought of together (”management”). It may be external influencers such as the customer (and possibly multiple customer organizations), government regulatory bodies, standards groups, or competitors.

We represent the extent of the effect on the work: whether essentially everything about the work is affected by this influence or whether the influence is more partial. So the Food and Drug Administration influences the work of food and drug companies through its reporting and testing requirements, but this influence does not constrain everything about developing the food or drug product. On the other hand, everything an assembly-line worker does is affected by the requirements of the assembly process.

The context model represents the nature of the influence on the work. We represent the direction of influence (who is primarily affecting whom) and how pervasive it is (whether this is an influence of one individual or group on another or whether it is more pervasive across an organization). We also represent push-back-in real situations it is rare that influence is all in one direction.

The following kinds of influence tend to be relevant to design:

• Standards and policy which define and constrain how work is done or what can be used or bought, or the lack of such standards as a policy. So many companies define a standard PC configuration which they will support. Other companies live with standard procedures defined by themselves or imposed on them by customers or by the government.
• Power, both formal in the organizational structure and informal through people’s networks, expertise and history. Power shows up in who has the right to decide who will do what in their work and the extent of autonomy a person can have. So one boss sets up his secretary’s computer environment, limiting her ability to recover when anything breaks down. In another organization, reimbursement for expenses is controlled by administration, which enforces the requirements for filling out paperwork and can choose to allow exceptions.
• The values of a company or team: what they stand for that produces a set of expectations about how people will interact and work. So one organization has the expectation that a project will be completed the same way as it was the last time, resulting in a feeling that innovation is not welcomed.
• A group’s own sense of identity, the way in which what they do is affected by how they think of themselves. So one UNIX shop held that they did not need to do formal up-front analysis and design because “we don’t do process.”
• People’s emotions about what they do including fear about being laid off or getting in trouble for raising issues, or people’s pride in what they do. So knowing that email could be read by management led people in one organization to discontinue its use.
• The idiosyncratic style, values, and preferences of an individual or team create a work environment that circumscribes others. So one boss will not use the computer, forcing his secretary to handle all his email communication; another likes to play with technology, changing her secretary’s system out from under her.

Questions for Design: Each work model focuses designers on a different set of issues-each answers certain questions designers must ask to make design decisions. The context model enables a conversation around questions such as the following:

Is there anything in the context that we want to support so as to enable the culture (e.g. set up standards or enforce policy)?

Is there anything here we want to discourage because we want to foster a different way of working (e.g. open communication or equal power)? Since any design embodies assumptions about culture we should do it on purpose, taking account of the consequences of our actions.

What do our customers want and what will they buy? What do those who make the buy decision think important? If tools are considered worth spending money on but training is not, spending effort on improved training may be a waste of time.

What will resonate with customers’ values and identity? ®sthetics might be essential to a product for design shops. This might drive the entire focus of the product’s design. What aspects of the context are changeable and what do we have to accommodate, given the system under design? Government regulations, for example, can usually be treated as unchangeable. Internal climate may or may not be changeable, depending on the scope of the project.

Physical work models can be drawn at different scales: the overall work environment, an individual work place within that environment, or a single work artifact. The work site may be structured as an open “bull pen” with supervisors’ offices around the outside. It may consist of many individual cubicles dividing up a large room. A person’s workplace may be an entire building or buildings, if they are maintaining equipment. It may be a car or airplane if they work on the road. Within a work site there are places to do work, which may be offices, labs, work benches, or work stations. The work itself may involve creating or using artifacts which have their own structure.

An understanding of the physical environment is incomplete unless it includes how people respond to the environment by restructuring it. Do people accept the workplace as it is, or do they work around it? If the environment consists of doorless cubicles, do they put things in front of the door to gain a measure of privacy? Is an artifact used as intended, or do people change its use to suit their work?

Distinctions: Physical work models of a site or of a work place represent the following distinctions:

The placesin which work occurs: rooms, work stations, offices, and coffee stations.

The physical structures which limit and define the space: sites, walls, basements, desks, file cabinets, and other large objects.

The nature of the space itself-small or large, primary or secondary workplace, private or open, cluttered, or empty space available for changing work activities.

The hardware, software and other tools (calculator, rolodex, in basket, measuring tools, Post-Itsª, printer, fax) that are present in the space which support the work or seem related.

The communication lines by which people coordinate with others in doing their work: phone, network connection, beepers, fax, PA system. We show network connections not to model the network per se but to emphasize who is connected to whom, and therefore what communication among people we can automate.

The work objects that people create, modify, and pass around in support of the work-folders, spreadsheets, to-do lists, bills, ID cards, approvals, piles of stuff.

The layout of the tools, work objects, movable furniture, and walls in relationship to each other to support specific work strategy.

The access given by hallways, passages, and distance between users and work objects, tools, other groups, and other sites. This supports visualization of movement between places and the extent of movement necessary to get a job done.

A work object is the thing that is created, manipulated, and used in doing the work. We model work objects to show what people think about when they work and how they think about it. The work object reveals the assumptions, concepts, strategy, and structure that guide people in working with it. We model work objects if they intimately support the work or if we are studying the process of creating the work object itself. Work objects might be to-do lists, forms, documents, spreadsheets, physical objects under construction (circuit board, car, airplane).

Physical work models of an individual work object show: Information presented by the object, such as the content of a form (e.g. a doctor’s name, nurse’s name, patient’s name, and diagnosis). Parts of the object, which are distinct in the usage such as page, kind of page (table of content vs. title page), headline, or figure in a diagram. Structure of the parts, explicitly in the object as given, and implicitly in its usage: the division of a form into a section for the doctor’s use and a section for the nurse’s, the grouping of cells in a spreadsheet to represent part of the data for a single purpose, or the way some people use the top of a day within a calendar for meetings and the bottom for reminders. Annotations which indicate the informal usage of the object beyond that allowed for by its explicit structure: Post-Itsª stuck to a document, highlighting, and notes written on the side of a report Physical characteristics of the object: color, shape, number, nature of attachment (folder, paper clip, staple). Additional work distinctions that are reflected in a work object and that matter in its creation and use: past, current, and future in using a calendar, structure and content which repeats in a report from month to month, x-height and caps height in page layout.

Questions for Design : Taken together, physical work models show how the work structures and is structured by the physical environment. They give us hints about how customers organize their work to get things done and connect with others. Physical work models ensure we do not forget what our customers’ work environment is like. Our clients are often surprised at the “primitive” technology of their customers compared to their own. Physical work models give us ideas for how to structure the system and how to present it so that users can make natural hypotheses about system behavior (as in the desktop metaphor). Some of the questions stimulated by physical work models include:

How is work limited by the physical environment? The team’s charter determines what must be considered a limitation that must be accommodated, and what is open for change in a new system.

What are the strategies that the layout implies? Corporate strategy for how work should be performed is implied by the layout of a site. For example, we can infer from the nature of conference rooms in most organizations that they act as “meeting space” not “work space”-they are not dedicated to any specific work and have none of the supporting material for specific work in them. At the individual level, one person’s strategy for accomplishing work can be inferred from their layout and use of their space. So the collection of telephone, rolodex, and calendar in one corner of a desk implies that they are strategically placed to support communication and coordination with others.

What social interaction supports the work? How do we ensure that computer technology does not result in isolating people from each other? How is separation or interaction fostered by the current environment-do people hang out in the hallway or crowd into one office to work together? Does the real work happen in a common lab, with individual offices essentially unused? Can we create virtual communities with appropriate structure and communication mechanisms given what we know about actual communities, boundaries, space, and access?

What networks exist or are possible? Personal computers on the desk have a very different impact on the work if they are networked than if they are not. Computers linked into a network make it possible to automate communication between people and to provide on-line access to information; standalone PCs are individual tools. What other communications technology is appropriate and should be considered as part of a solution (beepers, fax, etc.)?

What needs to be easily accessible in doing the work? Proximity implies what is important in supporting the work and is therefore kept nearby.

Do people have to move around to do the work? Is this something they object to and put off for as long as possible? Or do they make excuses to go out when the work does not strictly require it? Is the work itself entirely mobile? How does mobility restrict the tools which can be effectively used?

Models of work objects support discussion of the following questions:

If the system is to support creating the work object, what does it need to support: what kinds of information should it present, what parts, structure and distinctions should it allow manipulating? What physical characteristics matter, and how can they be supported? What specific distinctions are used in manipulating the object, and how can we build them into the system?

If the system does not create the work object, how does it fit into the work the system does support? What strategies are implied by the work object and its use which the system might support?

How is the object used in practice? Is it written on, annotated, or otherwise used as a support to the work beyond its explicit function? How will these usages be supported by the new system-if the work object is automated, can the on-line version be annotated? Can we eliminate the object altogether, and if so can we account for its usage as well as its explicit purpose?

The flow model

All significant work is accomplished by multiple people cooperating to achieve a result. To understand the structure of work, we must understand how work is coordinated among people and the patterns of communication between people that get the job done. The flow model allows us to look at and represent these patterns independent of time order so that we can support and optimize them.

Distinctions: Work is partitioned into roles: named collections of responsibilities organized to accomplish a coherent part of the work. When people cooperate to do work, they separate the responsibilities, explicitly or implicitly. “You write the paper,” they say. “I’ll review it.” Some responsibilities naturally go together: the writer might be responsible for researching the literature, as well as producing the initial text. The reviewer might be responsible for checking consistency with other writers, as well as factual accuracy. Other responsibilities are naturally distributed among people. It is ineffective for someone to be their own reviewer, so this responsibility is usually split from the writer.

Roles are not the same as job titles. A job is an organization’s formal definition of responsibilities to the organization. We find that people always add their own idiosyncratic structure around this. So a manager may also be coach, first line help, and system maintainer; a secretary may also be organizer, conscience, and taskmaster. The important roles in accomplishing work always exceed formal job definitions-some of the more creative job definitions, such as Apple’s “software evangelist,” give explicit recognition to roles that are usually implicit. Roles also break down the work to a finer level of detail than formal jobs. I may be writer on one document, reviewer of another, and coordinator of still another. One person can play several roles and the same role will often be played by several people, however people do not share roles the way they share responsibilities. Rather, several people may independently play the role and act together to discharge the responsibility.

We often find it useful to represent several people or roles as a unit, a group. We do this when the existence of the group affects how work is done. We may cluster roles this way when the group as a whole has common goals or is taking action together. We may be showing that outside people interact with the group as a unit, or has the same interaction with all the members. We can also show the interaction between a group member and the group as a whole.

Roles interact to get work done. The communication and coordination that make up this interaction are represented as flow. Flow may consist of informal talk and coordination, or it may consist of passing work objects. Representing flow between roles in an organization gives us a bird’s-eye view of how work in that organization is done. Work objects are the “things” of the work-they are thought of and manipulated as if they were real. A work object may be physical, such as a document or message. It may also be conceptual-for example, if a design conversation is thought about as though it has members, a history, attributes (public or private) and an existence separate from any one member or topic, it may warrant representation as a work object.

The communication topic represents the detail of the talk or coordination represented by a flow. These are actions as opposed to work objects, such as talk to set up meetings, arranging for review, asking for help.

On occasion we represent a place that people go in and out of in order to get their work done, if it is central to the work of coordinating and collaborating. This is often a meeting room or communal space such as a coffee area. It may occasionally represent a logical place, such as for the storage of data.

Questions for Design: The flow work model supports the following conversations about the design:

What roles will we support and how? What roles are central to the work? How are they supported in our system? Do we keep these roles as central in our system, or do we enable their responsibilities to be distributed to more people? If we distribute responsibilities do we over-burden other roles?

What is the appropriate clustering of function and the function central to the role? Describing a system only in terms of its function or the tasks it supports obscures the appropriate structure to support a role. Role is the central organizing principle of work: tasks and functions exist to support the work of a role. Understanding the roles a system will support structures the system we deliver.

How do we ensure each user can easily perform their different roles? This applies to users who perform several roles and must switch between them and to those who perform only one role and do not want to be confused by extra function.

What are the patterns of sharing and communication that we need to support? Are people handing work off to each other or reviewing work in multiple passes? How do we support such interaction in our system? What additional informal communication do we need to account for?

What does our support or automation of a role do to people’s jobs? Are we eliminating a job in eliminating a role? Would we free people to do more interesting work? Or would it be better to enable the job than to automate it?

What is getting in the way that we can overcome? How do we coordinate the multiple technologies for communication (email, telephone, fax, beeper, paper mail)? How do we limit the amount of interruption and the volume all these sources of information cause?

How do we support the movement of information and work objects into and out of other work places and how do we support communication from that place. If work is done in a group, how do we support the group’s work place?

The sequence model

The sequence model represents the steps by which intents are achieved. A sequence model can describe work at varying levels of abstraction, from the overall sequence of actions across an organization to the detailed steps of interacting with the UI of a specific system. Depending on the granularity of the view, modeling the steps in their exact sequence will reveal different aspects of how intents are achieved. At a high level we might model the hand-offs between group playing different roles. For example, a change request review board reviews incoming requests and passes accepted requests to a development group; the development group distributes them for completion; the developer gives the completed module to a configuration management group to build and test. At the individual level for the same task, we can model the actual steps that a person takes to create the module including when he receives the requests, when he asks others for help or review, and when he hands it to configuration management. This permits us to see work on a single module in its relation to the organizational process. At the UI level, we represent menu picks, dialog boxes, and other interactions with the system’s interface.

The sequence model is most similar to flow diagrams or task analysis [4, 5], but is unique in stating the intent and trigger for the sequence.

Distinctions: In the sequence model, we state explicitly the intent the sequence is intended to achieve. Secondary intents will be embedded in this primary intent, and they are named as they are identified.

A trigger causes a sequence of actions. It is the notification to the user to take action. Triggers we have seen include the height of a stack of paper on a desk, the arrival of mail, receiving a request, seeing a misplaced line of text in a document.

A step is the action or thought preceding an action. In an actual sequence model a step represents what actually happened. As we step back from the actual steps and look for purpose and strategy the steps become more abstract. They move away from specific behaviors toward fundamental purpose.

Arrows connecting the steps indicate order, loops, and branches. These reveal strategic and repetitive patterns of work. When the customer must make a decision about how to proceed we show that as a branching path. The order gives us an access road map to ensure smooth transitions between tasks and allows us to see what steps could be combined or skipped without serious violation to the users’ conception of what is going on in their work.

Questions for Design: The sequence model shows the particular steps needed to achieve some task in the work. Examination of the sequence model addresses the following questions about the design:

What is the underlying strategy of a person, team, or group in doing the work? How does each step contribute to this strategy? The strategy is implicit in the steps of the work and the intents they address.

What are the fundamental tasks of the work? Of all the possible ways people might approach the problem, which do they choose? At any decision point, there are many decisions that could be taken. But when we understand work from its underlying intent and strategy, we discover that only a few decisions actually will be taken in any particular case. This representation allows us to design to the actual nature of work rather than designing a set of features to solve all possible problems. The result is systems that are simpler to understand and easier to build.

What functions and clustering of functions are needed to support the work? The sequence models tell us how to cluster the function supporting a task to give the system a coherent structure, with convenient access between the parts of the system. The other work models place the tasks in a meaningful context and show how they relate to jobs done by people. This allows us to design the system as a whole, to support the work as a whole. It allows us to see the underlying intent of the work and support it directly, rather than addressing individual problems by providing individual features.

What are the triggers that notify the user to start a work task? When we automate work practice which is currently manual, we take away the physical triggers that start work happening. For example, if the trigger to read my mail is that the stack of mail has gotten precariously high, what happens when mail goes on-line? What is the trigger to deal with the backlog of mail if unread messages are decorously hidden away in a folder in a window in the mail application? To support the work well, we need to replace those triggers which are necessary to get work started. At the same time, we need to ensure our triggers do not disrupt the work. A stack of paper is a gentle, persistent reminder that there is work to do. A flashing icon, a beep, or a dialog box are all insistent demands that work be attended to now. We must ensure that our triggers match the importance of the work as the user sees it.

What gets in the way? We often discover that the user is completely derailed from their intent by the need to work around some problem. This is the first and easiest opportunity for re-design-making the work more efficient by eliminating and streamlining steps. The second opportunity for re-design is by changing the steps to a new process to achieve the intent. The third is to eliminate the intents themselves by addressing higher order intents directly.

Conclusion

Each of the above work models presents a different perspective on the work. These perspectives interlock: a role has responsibilities and undertakes tasks to discharge these responsibilities. The sequence models show how these tasks are accomplished in detail. The responsibilities and manner of accomplishing them are driven by organizational context and culture as shown on the context model. The work represented by the sequences is done within the work environment described by the physical environment model, and is done with and to the work objects represented by the individual work object models. When we step back and look at the models together, we see all the different aspects of the work and how they relate to each other.

Work models are built by first observing, inquiring into, and representing particular instances of work. Each work model shows work as it is and any problems that impede the work. Once we have a set of each type representing a cross-section of the customer community, we can build an abstraction of each type, and for sequence models, an abstraction for each intent. These abstraction make the underlying patterns of work across customers explicit. These abstractions can be documented on-line and kept as part of the project’s working documents. At the same time, it captures the variation between customers by showing any unique structure or details put into practice by each customer site. We can then decide the kind of work we want to support. We can take a good idea for approaching the work implemented by one of our customer sites, and build it into the system to make it available to all. We can streamline the work, removing extra steps and taking advantage of technological possibilities. From this re-designed work practice we can design a system that supports our new work practice and drives the design of the user interface and system implementation. Our customer-centered design approach provides techniques for all these steps.

Work models shift design teams to considering work as the center of design activities. They do this by providing a graphical language and representation of work. Any language, in the symbols it provides, chooses concepts to emphasize and concepts to ignore. If a symbol is provided for a concept, we can talk about it; otherwise the concept can only be addressed with difficulty, by indirection. The graphical languages used for design can provide only a limited set of symbols. If a symbol is provided in this small set we are almost forced to think about the concept it represents, if only to choose not to use it. If such a limited language is to guide design, it must contain exactly the necessary concepts for effective design. Additional concepts will distract; missing concepts will limit the resulting design. The right language allows us to have effective conversations, rich in detail where the detail is important, but abstracting out aspects which are unimportant to our purpose.

The four views of work described in this paper give designers four perspectives to take when looking at any work situation. Each perspective incorporates its own set of distinctions about work relevant to that perspective. Most people are not trained and do not naturally see the structure, strategies, concepts and relevant dimensions of work in the context of customers and systems. Certainly such training is not typically part of a design and engineering curriculum. These work models embody the knowledge we have developed over years of working with customers, teams and systems. Using these modeling techniques helps a team see rich aspects of work relevant to design. The multiple models encourage the team to explore each aspect of work separately and coherently before trying to understand them all together.

Modeling the work makes a team’s understanding of their customers’ work concrete. It gives them something which they can create, touch, talk about, and collaborate in making. It turns the conversation about work, which is nebulous, into a conversation around an explicit model so that all members of the team can refer to the same external representation. Because the conversation is grounded in an concrete representation based on real customer data, teams find it easier to agree on how the customer works, what in that work should be re-designed, and how the re-designed work practice should be supported by the system.

When used as part of the design process, models such as these drive the team’s understanding of the customer. These models cause the design conversation to shift from technology to the customer. These models become the content of the design conversation, the agreement among the team that all team members can refer back to, the touchstone for testing design ideas, and the historical record of the design conversation. They are the linchpin of understanding the customer, and so of customer-centered design.

Footnotes

[I] Throughout this paper we will use “system” to mean both software or hardware products sold to a market and also whole systems of hardware, software, and procedures designed for internal use within a corporation.
[II] Throughout this paper, we will use “customer” to indicate those who depend on a system in some way, and “user” to denote those who interact with it directly.

References

[1] K. Holtzblatt and H. Beyer, “Making Customer-Centered Design Work for Teams,” Communications of the ACM, October, 1993.
[2] S. K. Card, T. P. Moran, and A. Newell, The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates, Hillsdale, NJ, 1983.
[3] K. Holtzblatt and S. Jones, “Contextual Inquiry: A Participatory Technique for System Design,” Participatory Design: Principles and Practice . Aki Namioka and Doug Schuler (Eds.), Hillsdale, NJ: Lawrence Earlbaum Pub. 1993.
[4] M.D. Phillips, H. S. Bashinski, H. L. Ammerman, and M.F. Claude, “A Task Analytic Approach to Dialog Design” Handbook of Human Computer Interaction , p835. M. Helander (Ed.). New York: North Holland, 1988.
[5] J. Carter Jr., “Combining Task Analysis with Software Engineering for Designing Interactive Systems” in Taking Software Design Seriously . John Karat (Ed.), p. 209. Academic Press, NY, 1991.

Because system design is so intimately involved with how people work, designers need better approaches to gathering customer requirements. The current interest in participatory design, ethnographic techniques, and field research techniques grows out of the recognition that traditional interviewing and surveying techniques are not adequate to design today’s applications. These new approaches seek to improve requirements definition by creating new relationships between designers and customers. [I]

It is the relationship between designers and customers which determines how well the design team understands the customer problem. This includes not only the overall relationship between design team and customer community, but the individual, minute-by-minute process by which a single designer works with a single customer to understand their work. It is by understanding each person in the context of their work that the team comes to understand the whole work problem. [ii] Through face-to-face interaction, customers and designers define together what the proposed system must address, and what patterns of work the system must account for. What is the character of the interaction which allows this collaboration to occur? How do we help members of engineering teams create this relationship with their customer?

For nine years, we have brought design teams to the field to gather customer data for their own design problems. The design teams have been made up of engineers, marketing professionals, writers, managers and the other people commonly found on engineering projects. The teams have used Contextual Inquiry, our field requirements gathering technique, to get the detailed perspective on the customer that they need.

We have not found it necessary to have experts in field research on the team (in contrast to others [iii]). We have been able to evoke the appropriate behavior in team members by giving them a model of relationship which they can act out of with no more than a day of training. A familiar model of relationship suggests roles, attitudes and behaviors which people can act out of naturally. It allows a designer to get reasonably good data on their first interviews, and to continue to improve their skills with practice.

In this paper we describe the relationship we create through Contextual Inquiry. We show how to tailor the relationship so that it fits the needs of design, and describe how the interaction between a designer and customer works in practice. Finally, we suggest ways that a closer relationship between designer and customer supports a larger collaborative relationship between the design team and the community they support. (Here we focus on creating the right relationship between designer and customer. A specialist in field research would also provide knowledge of work and social structure. We discuss how to make this perspective available to design teams elsewhere. [iv])

The Designer as Apprentice

The fundamental problem in the relationship between customers and designers is to enable learning: how do designers learn enough about customers’ work to design well? What kind of relationship allows customers to impart deep knowledge about their work?

Looking outside the computer field, the relationship between master craftsman and apprentice stands out as a useful model. Just as an apprentice learns a skill from a master, designers want to learn about their customers’ work from the customer. This traditional relationship underlies the model of relationship we depend on in Contextual Inquiry. The critical aspect of the relationship are:

Teaching ability is not needed. Craftsmen, like customers, are not natural teachers and teaching is not their primary job. But they do not need to be-the master craftsman teaches while doing. A master does not teach by designing a course for apprentices to take. Nor does a master teach by going into a conference room and discussing his skill in the abstract. A master teaches by doing the work and talking about it while working. This makes imparting knowledge simpler for several reasons.

Teaching in the context of doing the work obviates any need for formal presentations or course materials. It obviates any need for the craftsman to think in advance about the structure of the work they do. As they work, the structure implicit in the work becomes apparent because both master and apprentice are paying attention to it. It is easy for the master to pause and make an observation or the apprentice to ask a question about an action. Observation interspersed with discussion requires little extra effort on the part of either master or apprentice.

Similarly, customers do not generally have the skills to talk about their work effectively; this is not their job. But customers can talk about their work as it unfolds. They do not have to develop a way to present it or figure out what their motives are. All they have to do is explain what they are doing: “I’m entering edits from my marked up copy here… I’m working in 200% magnification so I can really see how things line up. It doesn’t matter that I can’t see all the text in this magnification because I’m not checking for continuity or natural flow of words; I’ll do that in another pass later…”

Seeing the work reveals what matters. Even if the master were a good teacher, apprenticeship in the context of on-going work is the most effective way to learn. People are not aware of everything they do. Each step of doing a task reminds them of the next step; each action taken reminds them of the last time they had to take such an action and what happened then. Some actions are the result of years of experience and have subtle reasons; other actions are habit and no longer have a good justification. Nobody can talk better about what they do and why they do it than they can while in the middle of doing it.

This holds true for customers as well. They are not aware of everything they do or why they do it; they become aware in the doing. [v] In one case, we observed someone sorting his paper mail. He was able to tell us exactly why he saved, opened, or threw out each piece, because he was in the process of making that decision. Another time, a research scientist came to the end of a painstaking series of mechanical calculations, turned to us, and said, “I guess you’re surprised that I’m doing this.” He was surprised at how inefficient he was, once he stopped to think about it. But it is not natural to stop work to think about it; the apprentice relationship provides the opportunity to do so.

Seeing the work reveals details. Talking about work while doing it allows a master craftsman to reveal all the details of a craft. As he works, he can describe exactly what he is doing and why. As master or apprentice observe a pattern or principle in action, they can point it out immediately.

Talking about work while doing it protects the master craftsman from the human propensity to talk in generalizations. Customers do this, too. Rather than remember all the details of a task or event, they mix up many similar events and then talk about them in the abstract as though they were all one. This abstraction is divorced from any of the reasons for one action over another, and may not match any real instance at all. A design built on such generalizations may not meet anyone’s needs. Even when generalizations include detail, it is made-up detail-nothing is more detailed than an organization’s software development policy manual, and there are few less reliable guides to how that organization actually develops software.

Every action a customer takes and every object around them helps them talk about what they are doing in detail. One customer said he would not use the book index to find the solution to a problem: “It’s never in the index.” He was unable to say what he had looked up or how he had come to this conclusion. All his bad experiences with indices were rolled up into a simple abstraction: it’s not there. But when we watched him looking things up, we could see the kind of terms he was attempting to use and why they did not match the terms in the index. The environment itself reminds customers what to do: in another case, a customer was unable to describe how she made her monthly report. When asked to create it, she pulled out her last report and started filling in the parts-the old report was her reminder of how to produce the next one.

Seeing the work reveals structure. The apprentice learns the strategies and techniques of work by observing multiple instances of a task and forming his own understanding of how to do it himself. This understanding incorporates the variations needed to do the task well. The master craftsman can communicate techniques and strategies without articulating them.

In the same way, designers observing multiple events and multiple customers learn to see the common strategies underlying the work. Once they understand the basic strategies, they can start to imagine a system that would support those strategies. For example, a basic pattern in coding is: work on the code, test it, see the results. Identifying bugs to fix leads back to working on the code. But this pattern holds true not only for code, but for creating analysis and design models and automated tests as well. We uncovered this pattern by observing multiple people working on multiple systems of varying complexity. We could then structure the CASE system we were designing to facilitate movement through this cycle.

The apprentice can learn from the master’s experience. Every event serves as the starting point for discussing similar events in the past. In this way apprentices learn from experience gained by a master before their apprenticeship started. A particular occurrence or task reminds the master of other interesting times this event or task happened. If the event is reasonably close in time, the story is concrete and detailed-it is the re-telling of a particular event, told while the master is immersed in doing the same activity with all the triggers and reminders doing that activity provides. (Orr describes similar activity among modern-day technicians for similar reasons. [vi])

Designers typically have less time to spend with their customers than the years needed for an apprenticeship. But in the same way that an apprentice can learn from the master’s experience, designers can learn about events that occurred in the past. Events that occur while the designer is present remind customers to talk about events that happened previously. The artifacts of work-papers, forms, notes, clipboards, and so forth-trigger conversations about how they were used, how they were created, and how their structure supported their use in a particular instance. In one case a customer describing how she learned a feature told us “I looked it up in the documentation.” But when we asked her to look it up again, she was able to show us: “I looked the function up in the index and scanned the section. I saw this icon in the margin which I recognized from the screen, so I read just this paragraph next to it. It told me all I needed to know.” The documentation provided the context she needed to recover a detailed story.

Ethnographic and field research techniques [vii, viii, ix, x] seek to provide rich detail about customers by taking designers into the field. Apprenticeship provides an attitude of inquiry and learning to adopt while in the field. It recognizes that the customer is the expert in their work and the designer is not. A designer taking on the role of apprentice automatically adopts the humility, inquisitiveness and attention to detail needed to collect good data. The apprentice role discourages the designer from asking questions in the abstract and focuses them on on-going work. And the customer can shape the designer’s understanding of how to support their work from the beginning, without having to prepare a formal description of how they work or what they need.

Building on Apprenticeship

While apprenticeship defines an attitude for designers to adopt, their motive in observing work is not that of the apprentice. While apprentices want to know how to do the work, designers want to find out what a system might do to support the work. This leads to changes in the relationship. The designer must be responsible for seeing work structure. A master craftsman teaches his apprentice how to do the work. This is what he is expert at. But a designer must understand structure and implication: the strategy to get work done, constraints that get in the way, the structure of the physical environment as it supports work, the way customers divide work into roles, and the recurring patterns in their work, and what all this implies for any potential system. The customer is not an expert in seeing work structure, and does not naturally articulate it. [xi]

For example, we once asked a secretary how she started her day. Her answer was “I don’t know-I just come in and get started.” It was first thing in the morning and she had just arrived at the office, so we asked her to go ahead and do as she would any other morning. She unhesitatingly started her morning routine, telling us about it as she went: “First I hang up my coat, then I start my computer. Actually, even before that I’ll see if my boss has left something on my chair. If he has, that’s first priority. While the computer’s coming up I check the answering machine for urgent messages-there aren’t any. Then I look to see if there’s a fax that has to be handled right away-nope, none today. If there were, I’d take it right in and put it on the desk of whoever was responsible. Then I go in the back room and start coffee. Now I’ll check the counters on the copier and postage meter. I’m only doing that because today’s the first of the month…” Her morning routine has a definite structure-first she checks all her communication mechanisms to see if there is an immediate action that needs to be taken, then she starts the regular maintenance tasks of the office-but this structure is invisible to her. It does not even occur to most people as a topic of conversation.

The job of the designer is to recognize work structure. The detail which the apprenticeship model makes available and the dialog it encourages makes it easy to see work structure and reveal opportunities to improve work with technology.

The designer must articulate their understanding. An apprentice can learn the structure of work without articulating it, by simply copying what they see. But if designers do not articulate the structure they see to the customer, they cannot get their understanding corrected. The system they build based on their inaccurate understanding will not be useful. The apprentice proves they understand by doing the work and being corrected. Designers cannot afford to find out they do not understand by building the wrong system. Even iterating prototypes will be a long and difficult process if the basic understanding of the work is wrong. Better to find out immediately, by sharing it with the customer.

Any system is based on a chain of reasoning starting from a work observation and leading to an aspect of the design. [xii] Designers will build different systems, depending on how they understand their customers’ work. In working with one user of an accounting package, we learned that they kept a sheet of accounts and account numbers next to their screen. Here are some interpretations of what this observation might mean, and what it might imply to our design:

• Perhaps account numbers are necessary but hard to remember, and all we need do is make the cross-reference easier. We could put the cross-reference between numbers and names on-line.
• Perhaps numbers are unnecessary, a holdover from paper accounting systems, and all that is needed is a way to refer to an account uniquely. We could get rid of account numbers altogether, and identify them only by name.
• Perhaps compatibility with paper systems is necessary, but referring to accounts by name is far more convenient. We could keep the numbers but allow names to be used anywhere numbers are used.

Which of these designs is best? It depends on which interpretation is correct. The only way to ensure an interpretation is correct is by sharing it with the customer. We fail in the entire purpose of working with customers if we do not share and validate these interpretations. An apprentice does not have to do this, but the apprenticeship model provides a natural context for sharing observations of structure and interpretations of their meaning.

The designer’s job is to improve work. An apprentice is assumed to have no skills or knowledge relevant to the work at hand. The designer constantly thinks about ways to improve the work with technology. Designers know about technology, have skill in applying it to real-life problems, and naturally respond to the customer’s activities by designing improvements to them.

These are not digressions because the designer’s purpose is to improve the customers’ work. The apprenticeship model allows both designer and customer to introduce design ideas as the work suggests them. The customer can respond to the idea while doing the work the idea supports. There is no better time to get feedback on an idea. The designer expands their understanding of the work in this way-if the idea does not work out, there is some aspect of the work the designer is not accounting for. And the customer enters into the design conversation-the customer learns what technology can do and how it might be applied.

This gives the customer the power to shape the initial perspectives that will result in a full design eventually. Any iterative technique (such as rapid prototyping) will enable customers to shape a design. But any iteration of a design can only make small modifications to the initial structure. Involving the customers in the initial discussion of work structure can lead to radical alterations of system purpose and structure.

The designer has a specific focus. The apprentice learns whatever the master knows-the master determines the content. But the designer intends to support a specific kind of work. They need to guide the customer in talking about this part of their work.

One team we worked with was designing an information system supporting scientists. They needed to understand scientists’ behavior in pursuing a scientific inquiry, but did not need to know all the scientific knowledge that guides an inquiry. Had their goal been to replace the scientist, perhaps by creating an expert system supporting the scientists’ decision making, their focus would have been different. They might then have had to understand how to encapsulate scientific knowledge, but they still would not have needed the theory behind it. The designer’s focus scopes the information they need.

The apprenticeship model allows designer and customer to guide the conversation into areas of work that are relevant to the design. The customer, by revealing all the aspects of their work, broadens the view of designer beyond their entering assumptions. The designer, by focusing on particular aspects, draws the customer’s attention to the parts of the work they can affect in their design.

Using the apprenticeship model as a base, designer and customer can develop an interaction which allows them to explore and understand the customers’ work together. The customer is the expert in their work and how to do it; the designer is the expert in seeing the structure of work and the technology available to support it. Although the designer is not an apprentice, the model is an effective form for interacting with customers.

Apprenticeship in Practice

In practice, the customer might work for a while, with the designer looking on. The customer is immersed in the work, thinking about content (as usual). The designer, as apprentice, looks for patterns, for structure, and for things he or she does not understand. At some point the designer makes an observation or asks a question. This interrupts the flow of work. In order to respond, the customer has to stop working, step back and think about it.

A simple question gets a factual answer. But a question about the structure of work starts the customer thinking about structure: “So the first thing you do is check for any urgent communication, no matter what form it might have come in?” This question suggests a way of thinking about the work. It makes a previously implicit strategy explicit, and invites a conversation about that strategy.

The customer now responds at two levels: first, he or she addresses the question and a conversation about the work ensues. When the conversation winds down, the customer returns to doing work and the designer returns to watching. The question also affects the customer in another way. It is also an example of seeing strategy where before there were only actions. Customers soon learn to see strategy, and start interrupting themselves to make observations about the work they do. When one or the other has another observation about the work, they interrupt it again. This cycle underlies the entire interaction.

Maintaining the apprentice relationship requires attention to the interaction. Otherwise customer and designer may fall back into more traditional patterns for requirements gathering. Fortunately, the underlying master/apprentice relationship is a natural one, and is not hard to maintain as long as the participants pay attention to common pitfalls. Here are some of the pitfalls to watch out for.

Falling into other relationship models. Having apprenticeship as a model gives designers a way of behaving that replaces the behaviors they would naturally use otherwise. But because other relationship models exist, and are habitual, designers must recognize when they have fallen into them and how to get out.

Interviewer: Designer and customer start to act as though there were a questionnaire to be filled out. The designer asks questions which are not directly related to on-going work, because on-going work has ceased. The customer answers the question, then falls silent, waiting for the next. The best solution for this is to go back to on-going work, which effectively prevents this question/answer interaction.

Expert: The designer becomes the customer’s assistant in understanding how to use a tool. This is particularly troublesome when the designer helped design or build the tool the customer uses. Start the interaction by explaining that you are not there to answer questions. Then, if you fall into the role during the course of the interview, step out of the role explicitly: “I’ll never understand the problems with our system if I spend the whole time helping you. Why don’t you go ahead and do what you would do if I weren’t here, and at the end I’ll answer any questions you may have.”

Personal friend: Working together on understanding the customer’s work results in a close, personal interaction. This intimacy comes from the sense of mutual discovery, and from the attention the customer receives from the designer. However, this intimacy can lead to conversations which naturally grow out of such a relationship, but are irrelevant to the design focus. You need to keep your focus on the design issues, and refrain from making or following up on comments which are not relevant.

Talking in the abstract. Even though designer and customer are in the customer’s workplace, with the customer’s work all around, it is easy for the customer to start talking in the abstract. The designer needs signals indicating that the customer is talking abstractly, and return them to actual experience.

If the customer is leaning back and looking at the ceiling, he or she is almost always talking in the abstract. This is the position of someone who is not allowing the reality all around him from disrupting the conception he is building in his brain. Someone talking about real experience leans forward and usually points at some representation of what they are talking about. Words indicating the customer is generalizing are another signal. If the customer says “generally”, “we usually”, “in our company”, he is presenting an abstraction. Any statement in the present tense is usually an abstraction. “In our group we do…” introduces an abstraction; “that time we did…” introduces real experience.

The best cure is to pull the customer back to real experience constantly. If the customer says “we usually get reports by email” ask, “When was the last time that happened?” Never try to get more detail by asking what will happen next; this requires the customer to respond with a guess or an abstraction. Instead ask about real event in the past.

Retelling a past event is hard because so much of the context has been lost. People are prone to giving a high-level summary of past events devoid of the detail we need. Most people will start telling a story in the middle, ignoring what went before. Then they will skip whole steps as they tell the story. Listen for missing steps and back the customer up as necessary.

For example, when one customer started talking about how they dealt with a report:

“When I got this problem report I gave it to Word Processing to enter on-line-”

“So you just handed it on automatically as soon as you got it?”

“No, it was high priority so I read it and decided to send a copy to the Claims department.”

“How did you know it was high priority?”

“It had a green sticker on it.”

“Who put on the green sticker?”

“That’s put on by the reporting agency. They make the decision about whether it’s high priority and mark the report.”

“Did you just send it on to Claims, or did you write them a note about why they needed to see it?”

At each step, the designer listens for steps which probably happened but the customer skipped and backs the customer up to find out about them. In this process, the customer walks through the steps in their mind and recalls more about the actual work than they would if allowed to simply tell the story in order.

Tuning an interpretation. Designers worry about biasing the data, and tend to be reluctant to share their interpretations. This is a valid concern, but we have found that customers are not easily led astray in the midst of their work. Customers who are not used to seeing work practice can say what is going on more accurately by responding to an interpretation than by stating it themselves. Open-ended questions give the customer less guidance in thinking about their work than an interpretation, and result in less insight.

In our example of the customer starting her work day, the designer might have asked, “Do you have a strategy for starting the day?” Even though the customer just went through the morning routine, she is not used to thinking about strategy driving ordinary work events. The most likely response would be, “No, not particularly”-or a blank stare. But if asked, “You check for any urgent communication, no matter what form it might have come in?” she can compare this statement of strategy to her own experience and validate it or refine it. She might respond, “Yes, lots of things here are time-critical and we have to deal with them right away.”-simply validating the interpretation, adding detail but leaving it essentially unchanged. In fact, she responded, “Actually, things from my boss are most important because they are for me to do. Messages on the answering machine or faxes might be for anyone.”-refining the interpretation, accepting the broad outline, but adding a new distinction.

Because the customer responds to the interpretation in the moment of doing the work, they can fine-tune it quite precisely. Customers commonly make slight changes in emphasis such as that above to make the interpretation exact. They can do this because they are given a starting point which they can compare with the experience they are now having and adjust rather than having to start from scratch.

Customers may also say “no”, but to be polite may not say “no” directly. Here are some indirect ways customers say “no”:

• “Huh?” — This means that your interpretation was so far off that it had no apparent connection to what the customer thought was going on.
• “Umm…maybe.” — This means “no”. If your interpretation is close, the customer will nearly always respond immediately. A pause for thought means that they are trying to make it fit their experience and cannot.
• “Yes, but…”, or “Yes, and…” — Listen carefully to what follows the “but” or “and”. If it is a new thought, this is the right interpretation and yours was wrong. If it builds on yours, this is a confirmation with a twist or with additional information.

Designers in the field quickly discover how difficult it is to lead a customer in one direction when they are in the middle of an experience which takes them in another. A design is based on interpretations of work; if they are not shared with the customer, the design reflects the designer’s made-up explanations of customers’ behavior. By sharing our interpretations and being honest about interpersonal cues, we take away a valid understanding.

Adjusting focus. The designer has an idea of the scope of system they might create and the kind of work they might support. This focus guides the interaction with the customer, determining what to pay attention to and what to ignore. However, the designer’s initial focus may be wrong or too limited. The designer may find himself dismissing what the customer is saying. Information that is too far out of the designer’s expectations just seems wrong. It is easier to say this customer is wrong or strange than to try to incorporate the new information. Instead, this is an opportunity to challenge existing assumptions. Probe into the detail. Why is this information so different? What is going on? What expectations are violated? Probing leads to an expanded understanding of the work.

Any requirements gathering process runs the risk of being too focused. The result is a well-designed system that does the wrong thing. If designers are vigilant in breaking their own assumptions, they will discover the right scope for their system. The open-ended interaction between designer and customer encouraged by apprenticeship allows designers to discover where their assumptions are wrong.

Partnership in Design

We started with the notion of apprenticeship as a good way to learn about the customer. But applying apprenticeship to the special problems of design leads to a shared design conversation and a partnership between customer and designer. This partnership first affects the initial definition of requirements, but can change the whole relationship between customer and design organizations.

Apprenticeship naturally leads to a participatory approach to prototyping. If a customer talks best about their work while doing it, then a prototype is tested best when a customer uses it to do, or mimic doing, their own work in their own workplace. The customer demonstrates, concretely and realistically, how the prototype supports or fails to support their own work. Simultaneously, they learn what technology can do, and suggest alternative ways to apply technology to their own work. Having been partners in creating the basis for the prototype through the initial apprenticeship, they now become partners in creating the solution.

An organization which builds products for sale can make full use of this model for gathering requirements. Working closely with a single person on understanding their work leads quickly to a sense that they have had a real impact on the design process. The close work with individual customers leads the design team to discover the detail and structure of a work domain they need for their design. Repeat visits to customers with prototypes at increasing level of detail demonstrates the company’s responsiveness while refining the design at every step. The result is a more effective design-and improved public relations.

Organizations building custom software (such as IT departments) can combine apprenticeship and prototyping with putting people from the client organization on the team. They are full members of the design team, which means that they live by the rules the designers live by. The most important of these rules is a commitment to designing from actual, observed data rather than personal experience. As customers, they give the team their special insight, perspective, and knowledge of the client organization’s espoused policies. As team members they learn how to see work and how to apprentice with other customers. They also learn how often their organization’s espoused policies differ from what actually happens. This is a different role from that of “customer advocate” or “customer representative”-they are not the final arbiters of what customers want, and are not solely responsible for taking the customers’ point of view. As members of the team they learn how to apply technology to their problem and become full partners in working out the design.

When design is done this way, the client organization sees how to influence the design team even before the first prototype is developed. We have seen whole organizations transformed through the process-customers want to be interviewed, get excited about the new design, and feel involved in the effort. Customer team members, having learned to see work for the purpose of design, recognize how they can improve their department’s procedures. Some have put together teams using their new awareness to re-design their own business processes.

Apprenticeship is a form of intense listening which leads to mutual ownership and partnership between customers and designers. Agreeing on requirements is easier when design of a new system is done with the customer. Using the apprenticeship model addresses the problem of requirements definition by creating an effective relationship between designers and customers.

Footnote
[I] Throughout this paper we will use customer in the TQM sense as those who depend on a system directly or indirectly. We reserve user for those who actually interact with the system. Designer here means anyone who defines what a system will do, whether their job title is systems analyst, UI designer, or engineer.

References
[i] D. Schuler and A. Namioka (Eds.), Participatory Design: Perspectives on Systems Design, N.J.: Lawrence Erlbaum Associates, 1993.
[ii] J. Whiteside, J. Bennett, and K. Holtzblatt, “Usability Engineering: Our Experience and Evolution,” Handbook of Human Computer Interaction, M. Helander (Ed.). New York: North Holland, 1988.
[iii] A. Monk (organizer), “Mixing Oil and Water? Ethnography versus Experimental Psychology in the Study of Computer-mediated Communication”, panel at InterCHI ‘93, Amsterdam, 1993.
[iv] K. Holtzblatt and H. Beyer, “Making Customer-Centered Design Work for Teams,” Communications of the ACM, October 1993.
[v] M. Polanyi, Personal Knowledge, Chicago: University of Chicago Press, 1958.
[vi] J. Orr, “Narratives at Work-Storytelling as Cooperative Diagnostic Activity” in Proceedings of the Conference on Computer-Supported Cooperative Work, December 3-5, 1986, Austin, Texas.
[vii] A. Clement, “A Cooperative Support for Computer Work: A Social Perspective on the Empowering of End Users” in Proceedings of the Conference on Computer-Supported Cooperative Work, 1990 (CSCW ‘90), p. 223. October, 1990, Los Angeles.
[viii] L. Suchman, Plans and Situated Actions, Cambridge University Press, Cambridge, 1989.
[ix] J. Lofland, Analyzing Social Settings: a guide to qualitative observation and analysis. Wadsworth, Belmont CA, 1971.
[x] S. Garfinkel, Studies in Ethnomethodology. Prentice Hall, Englewood CA, 1967.
[xi] K. Holtzblatt and S. Jones, “Contextual Inquiry: A Participatory Technique for System Design,” Participatory Design: Principles and Practice. Aki Namioka and Doug Schuler (Eds.), Hillsdale, NJ: Lawrence Earlbaum Pub. 1993.
[xii] K. Holtzblatt, “If We’re a Team, Why Don’t We Act Like One?”, in interactions, July 1994, Vol. 1 No. 3, p. 17

Published in Communications of the ACM Issue (May 1995)

See, I’ve been traveling regularly for the business for at least 16 years. And when you go on the road, of course, you have this idealized view of what it should be like—wife, kids, and dog lined up to kiss you goodbye, handkerchiefs waving, maybe a few tears, and so forth.

I pretty quickly got used to discovering that it’s not like that at all, of course. The wife has her own job to worry her, the kids are busy with their lives, the dog is chasing rabbits. What I couldn’t get used to was the way that my wife and I always had a big argument right before I went on the road. Not even a sensible argument—it would be some triviality that got blown out of proportion and left us shouting at each other when I was about to leave and wouldn’t see her again for five days. (“What do you mean your car’s not registered yet?” “I didn’t have time.” “How could you not have time? It was due 10 days ago!” “What difference does it make to you? You won’t be here.” Etc.)

So finally, one day, I hadthis big realization—it’s because I’m going on the road that we’re having the argument! She doesn’t want me to go, I’m frazzled and stressed out, and so a little disagreement turns into a major tiff.

So one day I said, “Hey! Look at us! We’re about to have the ‘going on the road’ argument again! We do this every time!” and she said, “Huh. I guess we do.” So we didn’t. And ever since then, when I’m about to go on the road and we start to mix it up, I look at her and she looks at me and we grin despite ourselves—and we don’t have to argue.

This is the power of getting interpersonal nonsense out on the table. We all have it, just as much in our work lives as in our home lives. But most of the time it’s unrecognized and unacknowledged. We have arguments or feuds without ever understanding why, and the thing we think we’re arguing about has nothing to do with the real issue.

But when it’s recognized, it’s neutralized, even if the underlying issue can’t be resolved. I still travel, and my wife still doesn’t love it. But now we laugh about it instead of fighting.

This works in a business context too. For example, one of the people in our company is charged with being the super-project manager—he makes sure that all the planning and resources are in place for all our projects to happen on time. We call people who can do this well ducks-in-a-row people because they love nothing so much as getting all their ducks in a row, getting things organized.

This means that part of his job is to sit down next to me, interrupt the Very Important Task I’m doing, and force me to think about something that won’t happen for two weeks yet. Not being a ducks-in-a-row person myself, I’m prone to resent this—but he’s developed the habit of starting out by saying with a grin, “I need to do my ducks-in-a-row thing now.” And I grin despite myself, and push the keyboard away, and we have the conversation we need to have.

So next time you find yourself in some stupid argument on your project, ask yourself: What’s the real underlying issue here? Who is scared of what, or upset about what? And then ask: Why not just say what’s really going on?

I’m still testing this page.

With Contextual Design, we provide innovation from a deep understanding of your customers and a proven process for transforming that knowledge into insightful, user-tested solutions.

Where does innovation come from?
People may 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 cell phones — or even telephones. Deeply understanding your customers’ current core needs and behaviors allows you to address them with future technologies, processes, and solutions.
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 process steeps your team in the customer data, and leads them through a structured 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 multiple rounds of iteration is a validated set of your most important requirements, based on actual customer behavior with real concepts. Our User Environment Diagram and Living Specification capture these validated, prioritized requirements, and the structured customer data behind them lets you have confidence that you’re building the right product in the best way.

Innovation for a wide range of applications        (we can link to case studies here or have a sidebar)
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.
Business applications and systems
Customer and enterprise facing web portals
Consumer electronics
Hardware and software products
Information design and delivery

User-centered design gives any sort of development process a powerful boost. But integrating a new approach to design is bound to disrupt established procedures and relationships. Project members have to learn new skills and ways of doing things. Much of the look and behavior of a system won’t be designed by the same people, or in the same way.

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.

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 about the importance of both capturing and interpreting. Read tips on Contextual Inquiry.

What should my questionnaire look like?

That’s right, no guided questions. 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 usually only have to interview 15-30 people to capture requirements, even for an entire market.

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.

• What is the real sales process used within midsize companies’ sales organizations? How well does Sage SalesLogix support it?
• How do different parts of a company coordinate activities in the sales process? How can Sage SalesLogix become indispensable in fostering this coordination?
• What problems are users experiencing with the current product? What is getting in the way? What is the “secret sauce?”

InContext’s customer-centered approach gave Sage SalesLogix the in-depth understanding of their customers’ needs, a validated set of new features, and a product direction that resulted in an award-winning design currently the rave of industry experts.

Delivering Results

The team then developed a three-level strategy for Sage SalesLogix evolution:

• A set of immediate usability fixes to improve the users’ experience of the product
• Functional changes and additions to better support key tasks that could be implemented in the short term
• A longer-term vision for how to transform the sales process through better integration and more complete support of the process

The team selected a piece of the larger strategy to address salespeople’s key issues and worked out the design of this piece in detail, testing the design with users to ensure it met users’ key needs. The validated design introduced:

• Pervasive ability to get to the data desired and take action— Sage SalesLogix contextual filters
• Summarization of key information and status into Snapshots while also providing access to details, for each object type
• Distinct Workplaces to bring key information together to satisfy different roles, intents, and work practices
• Sage SalesLogix developed and shipped these validated functions on their new Web platform. In the Sage company-wide product competition, Sage SalesLogix won best product in their class and across all product categories.

Reviewers of the new Sage SalesLogix implementation have also been excited. From Paul Greenberg - industry observer and author of “CRM at the Speed of Light”:

“SalesLogix 7.5 contextual filters - I saw the newly improved and radically better SalesLogix 7.5 - something that I would recommend for small and midsized businesses. Not only are they using the increasingly popular REST (Web Oriented Architecture) to do things such as scrolling within the browser (rather than the more standard “Next page” paradigm) but what I found really great was their contextual filters. Think about them this way. You have 1000 customer accounts. They encompass 30 states. When you want to use the filters, the only states that will show up are the 30, not all 50. As new states are added, they join the filter list. You get to do filter and use what you need to. This is a great feature that carries over into all categories and tags.”

The Process

InContext and Sage SalesLogix assembled a joint team from both companies. Together, they started by analyzing the current product to ensure no function was forgotten in the transition to the new design. The team then conducted field interviews with 37 users in different organizations and job roles. The interviews were selected to span organizational size, industry, and the different roles that use Sage SalesLogix.

From the field interviews, the team discovered opportunities to better support the work practice of users including findings such as:

• Making lists is a central part of daily work and must be easy
• Much of the sales process happens through email and phone calls. Sage SalesLogix could better integrate and support those activities
• Sage SalesLogix is great because it holds critical business data; therefore getting to the data fast would add extra value
• Lead management helps the work but users need help prioritizing and managing the leads
• Overall usability improvements can increase the efficiency of use and bring valued information directly to the user

• What are people’s roles, tasks, and activities while participating in communities?
• What makes a successful community?
• Can Microsoft host a community that will be trusted? What would make a best-in-class online community?

“Our previous project on the Microsoft.com user behavior revealed overall needs, but we didn’t yet have a clear picture of our potential communities users. We wanted to take a deep-dive into this area and determine how best to facilitate and support them, in a community setting” shared Doug Pyle, Usability Manager.

Delivering Results

After evaluating the data, the InContext team developed recommendations and design ideas for the Microsoft.com team to improve the online communities and create an environment people would trust and want to participate in:

• Let people build real relationships by tracking each other online and supporting offline interactions;
• Enhance the role of experts or stars in a community;
• Make trustworthiness explicit across the community;
• Strengthen the role of information in a community, making it easier to find, maintain, and organize.

The project delivered the results that the Microsoft.com usability team was looking for:

• Grounded customer needs, based on observing customers at work;
• Identified productive direction based on customer perceptions of Microsoft as a community provider;
• Integrated user experience recommendations, incorporating current initiatives and projects at play within Microsoft.

“Now, our designers can immerse themselves in the data and extend InContext’s recommendations with their own ideas.” - Doug Pyle, Usability Manager

The Process

InContext designed a research project using Contextual Inquiry to study users participating in newsgroups, web forums, wikis, Open Source communities, and user group meetings. The detailed field data from these interviews were merged with the previously collected data to inform the final results.

From this data, InContext was able to reveal users’ real needs and desires — what they look for in a community and what they need to trust the information they find. The team used this understanding to make recommendations for improving Microsoft-sponsored communities, including improvements to the sites and new marketing directions.

“Now we know what direction to take our involvement in communities,” Pyle said.

The team learned that users go to online communities for information but judge the community by a sense of personal interaction and relationship building:

• Community is a place to form personal and social relationships.
• Off-line (face-to-face) meetings augment the online community. Community members don’t separate the off-line, real world of communities from the online world.
• Personal Interest Communities are more than just places to find information.
• Trust is critical—and there are clear, identifiable ways to establish trust.

I am not a crunchy tree-hugging green environmentalist. But today environmental consciousness is reaching the mainstream. The average consumer, like me, is asking questions about what it all means for daily life.

I was talking to a rabid green friend of mine.  “If we could produce electricity from renewable fuels or some other ‘non-oil’ means we wouldn’t need to conserve – right?” I said.  Frank looked at me askance!  “We can’t invent our way out of this,” he said. “We have to use less energy.”

Frank is a technologist – but even for him technology is not enough of an answer.

But I can’t live like Frank! He built and designed his own house – tightly sealed through special joint construction. It is entirely heated by a wood burning stove helped by an internal swimming pool heated by the sun (Not sure how that works!).  There is no fan to move the heat. They recycle everything and compost. He rides a bike to and from work – and I don’t know what else.

So I sure hope technology can do something – because like most Americans – that isn’t going to be my life.

But maybe I can do something, I thought. So I started a green experiment.

What about heat?  We live in New England - I don’t change the thermostat much. But somewhere along the line I learned you were not supposed to waste heat when out of town. So I turned down the thermostat whenever I left.

I do, however, have four zones in my house. I don’t have four zones because I wanted to conserve energy – I have four zones because my contractor gave me four zones. I don’t have fancy thermostats because my contractor put in the old simple manual type that turn.  It never occurred to me to ask for something different – that was his decision. In fact, my contractor had more influence over my insulation, windows, heat zones, air conditioning choices, and even my light bulbs which he bought and installed than I did.

I like having the zones because my pet birds need heat. They are in one room and I keep it warm without needing to keep the rest of the house warm when we are away.

Experiment One: I decided to try to become more conscious of the temperature and thermostat setting.

I started by lowering the heat at night and when we left the house in the day. The basement (a zone) wasn’t used much so I put it at 64. When I left for work I turned everything down to 64. And now I turned it all to 60 when we were gone. My home office could be heated when I was working and I could leave the main house lower. I ran around the house moving the temperature up and down many times a day. Why? Because we change location and what we are doing many times a day!

We went away and I left the temperature at 60. But that week I was travelling for five days – my husband wasn’t. When he got back he was “freezing” and turned the temperature up to 72. His theory of temperature is that if it is cold you turn it up past the temperature you want because that will speed it up. So I returned five days later to a house that was steaming – he of course never turned it down.  Lord, we’d wasted heat!  (Note: the emergence of a “waste” value.)

So I’m getting annoyed at my husband for not paying attention to temperature and I’m running around turning the heat up and down – being cold and waiting to be warm – until I become fed up. I just can’t be thinking about the temperature all the time – it is making me obsessed. And for what?  The overall difference in cost is negligible compared to being cold. And being cold is utterly unacceptable. What difference does my little heat experiment make to the invisible world of global warming or energy independence!?  What matters to me is being warm – if I can be warm I don’t care how I get there.  I don’t care if the room is unheated when I’m not there – I only care that if I’m there I’m warm – right away.

And don’t tell me to wear sweaters – you can’t work when your nose and fingers are too cold to focus. Or that I should get fancy programmable thermostats. I have those at the office where I still have a space heater to keep warm. No matter what we do at work we can’t make the heat or cooling work in all the rooms – why would I put those unusable devices in my home?

This is a technology challenge.

Experiment Two: I gave up on heat and I turned to shopping.

I decided to try to become more conscious of what I bought. So I started to look at the stores. How can I be conscious of garbage and plastic when I have no control over it? I looked around and realized that all the packaging is HUGE.  There are boxes inside of boxes. There are boxes that are half full. There is plastic molded around everything ( Isn’t everyone frustrated by that shrink wrap plastic anyway—who can open it!?).  I generate garbage because manufacturers generate garbage. What am I supposed to do - look for things I can buy with little packaging?  Buy only recycled paper packaging?  I want to shop in my regular neighborhood store and, like me, the mainstream person isn’t going to bring in their glass jars and hand-dip the fresh yogurt and cheerios out of a big vat in the middle of the store!

This is a technology challenge.

Experiment Three: I gave up worrying about packaging and turned to light.

What about light bulbs?  I have lots of those in my house. My husband’s light over the closet was burned out and we had no more bulbs.  Ah, an opportunity!

My mother taught me to turn out the lights (Whoops, that “waste” value again.).  So I always turned out the lights. But… well, we won’t discuss spousal behavior.

My husband’s office has two switches on the same panel, one for over his desk and one in front of the closet. He comes in, flips on all the lights without distinction. The closet light is always on even if he is at the desk. This – given my turn-out-the-lights value – annoys me.

So I’m at the drug store and see light bulbs. Okay, what if I just get one of those curly lights for over his closet?  At least then it will waste less energy, and it lasts longer. Changing the bulb – being short – is a pain, and $8 is okay for an experiment.

So I buy one. It says that it is a 65W bulb. But it isn’t really. A light over a closet helps you see to find your clothes. And this light doesn’t actually burn bright for five minutes—there is a lag. When you switch it on it is dull and looks like a night light. Sometimes it doesn’t turn on at all.

My husband is annoyed. He doesn’t want a light that doesn’t light!

Now the lights over his desk burn out and we still have no bulbs and no light over the closet. So I ask him to find some better green lights. Being a good guy, he does it. He comes back with halogen lights. But wait, they look like outdoor lights we put over the garage! They don’t have the smooth glass. “I’m not putting those all over my house,” I say, “they are ugly.”  And how do I know what they’ll do to my art. (Art is best with the white light most like the sun. Do they have “green” art bulbs?) ?

“Let’s just try them in my office,” he says. Now he has a halogen light with the wrong glass over the closet – but at least its bright and turns on fast. He has an incandescent bulb, a curly bulb, and a halogen bulb over his desk. The halogen burns bright white and forms a definite cone of light. The curly bulb – well, it is yellow and dull.  And the incandescent bulb? It is soft, wide-spreading, unobtrusive pleasant light.

Now my green friend tells me halogen isn’t green. But it says right on the box “Energy efficient, longer life replacement for standard BR30 bulbs.”  If that isn’t green how’s a person to know!

This is a technology and a messaging challenge.

Finding the Essential Requirement

My green experiment is not over.  But there is one thing I am sure of – we have a long way to go before everyday people will joyfully use energy-efficient products.

We could go the way of Wal-Mart who decided to make its brand equate with sustainability. Now it only sells energy-efficient lights – whatever that means.  Certainly if you only offer particular products people will have to buy them or go to a competitor. Or, the government could legislate it all.

But what about providing value? That’s the technology challenge.

In Green to Gold, Esty rightly says that environmental concerns will always be a tertiary sales point. What matters is the real value products provide. People don’t care about packaging – we care about what’s inside and the ease of transport.   We care about heat – not the thermostat. If the thermostats can’t be programmed for the life flow of real people we won’t program them.  If they are too hard to use – we won’t buy them. We care about light – and the quality of light. If the lights don’t light – we won’t buy them. And if products don’t make consumers happy our contractors won’t buy them either.

But if product makers can provide real value and reduce environmental impact – well I’d feel good buying that one – if it isn’t much more expensive.

Requirements gathering and design with green consciousness just makes design harder. Even the best and brightest designers confuse function with the technology to provide that function. If we want “heat” we think of the known technologies to get heat – and the way to push heat through the house. But the essential value to the customer is evenly heated rooms when they are present in those rooms. We don’t care about the mechanisms.

The funny thing is that I’ve been going to Frank’s house for over 20 years and I never knew how it was heated until I asked. Because I was never cold!

But old houses and existing houses aren’t built with that in mind. So product companies have an opportunity and a challenge. How can we get and distribute heat so that the whole house is warm wherever and whenever people are present?  How do we get the right kind of light with the right aesthetics?  What is essential to heat and light for people?  How do we provide what is essential and then deliver even more delighters?

We need to look deep inside what people do, and say; we need to look beyond what they are used to and what they expect from products. We need to find the source of core need and core value. We need to dig under the words and existing technologies to reveal the value in the quality of light – how it connects to task or art or the glow of intimacy, for example. Then innovative designers, armed with the essential requirements, will find new means and materials that “live lightly on the land.”

And they’d better. People can’t do this for themselves.

• Autodesk wanted to understand how small to large companies leveraged their design work, usually created with Autodesk tools, for marketing purposes and what tools were used.
• What process do product designs go through to become part of a company’s marketing collateral? How do they make them available for use by their downstream customers?
• What issues do companies struggle with as they provide design models and information to their customers?  What could Autodesk do to facilitate that process?

Delivering Results

The detailed customer data delivered to Autodesk was captured in an affinity model, personas, consolidated sequences and swimlanes. These models provided Autodesk with deep understanding of their target users, how they performed their work and the issues users struggle with as content is passed through the marketing preparation process.

According to Jeff Wright, Director, Content Solutions, “by working with InContext, not only did we learn how to design our new Web service to best address user needs, we also had an impact on how several senior executives at Autodesk think about new product design. There is now greater appreciation at all levels of our organization for the value of the contextual inquiry and design process.”

“I constantly use the data to educate other teams on what our project is about and why it is important for them to support us” said Jun Shim, Autodesk product manager. “The data provided by InContext allowed me to write my Marketing Requirements Document easily and with confidence that I understood the user’s needs. This allowed me to educate the engineers, designers, graphic designers and support teams on the product requirements.”

Autodesk is currently validating the design concepts with users and expects to ship a new tool which building product manufacturers will use to participate in Autodesk Seek. The new S/W capability will enhance manufacturer’s marketing efforts by making detailed product data easy to find and download by potential buyers and/or specifiers.

Previous engagement

In a previous engagement, InContext worked with Autodesk to develop the requirements and new product concepts for Autodesk Seek, a robust new web service that connects architects and engineers with building product manufacturers to enhance design efficiency and streamline designer workflows. This product has now shipped and is available to Autodesk customers.  InContext had provided detailed customer research and then collaboratively developed the new product concepts.

The current project - the process

This follow-on project was focused on the marketing side of the equation.  In other words, how does a company make their product designs, 2D and 3D drawings and associated information available to other companies, thereby facilitating the marketing process for their products to downstream customers?

InContext started with customer research, doing Contextual Inquiry with 40 participants involved in the process of taking design content, 2D and 3D models, and making them available for marketing purposes.  This included design engineers, graphic designers, marketing professionals and website managers.

“The data we’ve received from projects with InContext have consistently improved the quality of our products. We found InContext’s process extremely effective at bringing diverse stakeholders to a shared vision.  Their process is also very effective at kick-starting new projects — they drove us harder than we would have driven ourselves.  At the end of both of our research projects, we had results that led directly into design, with the result that design went much more quickly than starting from a blank sheet” said John Wallace, Senior Interaction Designer.

The InContext team and a cross functional team from Autodesk collaboratively generated new solution concepts through Contextual Design’s visioning process.  This resulted in product design concepts which would allow manufacturer’s marketing efforts to be integrated into Autodesk Seek.