UX Immersions was the smaller conference, focusing this year on the Agile/UX interface and on design for mobile devices. It was a great group of very focused people and, as it was run by Jared’s organization, the whole conference ran like clockwork.

I had my own session to teach but I was able to get around a little and very much enjoyed Jeff Gothelf’s talk on UX and Agile. He calls his approach “Lean UX,” because he’s looking to integrate the UX work as closely as possible to the development work. I think it’s a good challenge: How closely can you get the UX people and the developers to work together? Can you do initial rough sketches together? Can you make a space for user feedback and for design, if you give the developer a way to get started? Can you do all this within the boundaries of a sprint?

I’d love to hear your experience—let us all know in the comments how you’ve done it.

CHI was a joyful zoo, as always. We at InContext presented sessions on Agile/UX, Innovation, and Cool—all well-attended and well-received. Some highlights from the rest of the conference:

One fascinating paper discussed the effect interleaving tasks has on making errors. They showed that for a moderately involved task (setting up an IV drip) the error rate increases when the user tries to program multiple IV devices at once. They were able to reduce the error rate by moving the instructions farther away from the IV device, making quick reference more difficult so that users defaulted to programming one device at a time. Hmm. Where else might interleaving tasks be a real problem? Should we be designing to discourage interleaving in those cases, rather than for convenience?

There was a good paper on social tagging in the presence of other social taggers. When people are given the opportunity to tag content they view online, it turns out they not only copy the tags others have used, but also use tags that extend the meaning others have used. So it’s important to see the tags the community has used, so the community can coalesce around a shared set of terms.

But by far the coolest thing I saw was technology from Seeing Machines that can present a true 3D effect on an (almost) standard laptop with no glasses. The technology uses the laptop’s webcam to track where your eyes are and a special filter over the screen to direct the image to one eye or the other. They say the screen is cheap and light enough to be included in a laptop as standard equipment.

Imagine what the world will be in five years when computers ship with 3D as standard, built into the OS, just as they currently ship with color as standard. And it’s not just 3D movies—the technology tracks where your head is and can present 3D virtual worlds. 3D can be built into the OS interface itself—windows can truly be laid out in the Z dimension. In a few years, we may be moving our heads to peek around a window on the screen and see what’s behind it. Start thinking about how to design for it now—it’s coming sooner than you think!

This intensive, hands-on workshop is for anyone who has a part in defining and designing things people use—products, systems, services, or processes. You’ll immerse yourself in our research data and learn how to intentionally design for Cool.

What makes cool products Cool? To find out, we immersed ourselves in the experiences of everyday people as they used their coolest products. Field data from 90 consumers and business professionals from 15 to 60 revealed a set of concepts identifying the factors that drive the cool user experience.

Read more about the workshop.

“Why can’t we ship a really transformative product”
“How do I get my team to be more innovative”
“My executives expect our products to become more Cool” 

By attending this workshop, you’ll learn:

• How Cool products tap into our experience of joy and delight
• How the Cool Concepts change the way you think about designing products
• The design principles behind the Cool user experience
• What to redesign in your products to increase your Cool factor

Intentionally Design for Cool — Create that transformative experience with your products

This intensive, hands-on workshop is for anyone who has a part in defining and designing things people use—products, systems, services, or processes. You’ll immerse yourself in our research data and learn how to intentionally design for Cool.

What makes cool products Cool? To find out, we immersed ourselves in the experiences of everyday people as they used their coolest products. Field data from 90 consumers and business professionals from 15 to 60 revealed a set of concepts identifying the factors that drive the cool user experience.

The Wheel of Joy and The Triangle of Design articulate the key elements design teams need to consider when designing for cool. Putting them into practice helps infuse your design process with actionable, innovative thinking. The result: products that produce a cool user experience.

The Wheel of Joy represents the what of a cool product. Joy and delight come from accomplishing what you need to in life, connecting to people you care about, expressing your unique self, and simply enjoying sensory stimulation.

The Triangle of Design represents the how of a cool product. Joy in use comes from product design that lets users get directly to their intent with minimal hassle or learning.

Come and learn about intentional design for product transformation.

This two day workshop presents these concepts with examples from our data relevant to business and consumer products alike. The Cool Concepts have been validated with 2000 people surveyed worldwide verifying that we have indeed uncovered the core factors associated with the cool user experience

Who should attend

Individuals or teams who have a hand in defining or designing products or business systems; product managers, designers, developers, marketing professionals, project managers, business analysts, user experience professionals, quality managers and consultants.

Bring your whole team to the workshop and we’ll tailor the breakout work to your specific product focus.

This exciting and ground breaking two day workshop is led by Karen Holtzblatt, CEO and Co-founder of InContext

Karen is the visionary behind InContext’s unique customer-centered design approach, Contextual Design. Karen’s combination of technological and psychological expertise provides the creative framework for driving development, innovative designs, and design processes.

Recognized as a leader in requirements and design, Karen has pioneered transformative ideas and design approaches throughout her career. Karen introduced Contextual Inquiry, now the industry standard for gathering field data to understand how technology impacts the way people work. Contextual Inquiry and the design processes based on it provide a revolutionary approach for designing new products and systems based on a deep understanding of the context of use. Contextual Inquiry forms the base of Contextual Design, InContext’s full customer-centered design process.

Karen led the research for the Cool Project and developed the Cool Concepts which will form the basis for her new book What Makes Things Cool?

Karen co-founded InContext Enterprises in 1992 to use Contextual Design techniques to coach product teams and deliver customer-centered designs to businesses across multiple industries. The books, Contextual Design: Defining Customer Centered Systems, and Rapid Contextual Design are used by companies and universities all over the world. As a member of ACM CHI (the Association for Computer-Human Interaction), Karen was awarded membership to the CHI Academy, honoring the most significant contributors, and received the first Lifetime Award for Practice, presented to her in 2010 for her impact on the field. Karen’s extensive experience with teams and all types of work and life practice underlies the innovation and reliable quality consistently delivered by InContext’s teams.

Karen also has more than 25 years of teaching experience, professionally and in university settings. She holds a doctorate in applied psychology from the University of Toronto.

What you’ll learn and practice

Wednesday, June 20
We teach you what the Cool concepts are and what it means to apply them to design thinking.

Introduction to the principles of Cool: The Wheel of Joy

• Walking the data. We lead your team in immersing themselves in data relevant to the Wheel of Joy
•  Discussion of issues and implications of Wheel of Joy data

Introduction to the principles of Cool: The Triangle of Design

• Walking the data. We lead your team in immersing themselves in data relevant to the Triangle of Design
• Discussion of issues and implications of Triangle of Design data

Thursday, June 21
Get practical experience how to apply the Cool concepts to product design

Introduction to design implications for each of the Cool Concepts.

• We use an example product to walk through guided questions showing the application of the Cool Concepts

Break up into small groups, by company or product interest area.

• Stimulus questions for each factor facilitate design thinking for a target product area
• Teams work out several ideas for product transformation

Sharing ideas. Each small team shares ideas and discusses insights and then gets feedback from the group

You leave with a new understanding of how to design for the cool user experience. And if you bring your product team you leave with a set of product ideas and an action list you can start working on now.

So why am I writing about this professor? I didn’t know anything about Mr. Wilson before he passed away. But as I read his obituary I became curious and sought out more detail about who he was. How did he gain insight and understanding that was often different than ‘conventional wisdom’? What I discovered and why I’m writing about it here is he was a man that owed some of his success to the way he approached his work and life. And that approach was to go into the field and understand human behavior.

He always focused on the empirical and practical. He looked at human behavior on the ground, talking to people and building up detail. As Wilson’s sometime co-author Karlyn Bowman put it, he had “an eye for the piquant detail.” He saw things that others did not see, whether he was reading a journal article or conducting a field interview and he made the most of what he saw. As his fame increased, he acquired a reputation as the most restrained, punctilious, and empirically grounded of public intellectuals according to the Weekly Standard’s recent description of his work.

I discovered that his ability to see things that others didn’t was due to his desire to go out and interview individuals such as police workers or civil servants while they did their work. This gave him his empirical data from which he was able to synthesize and develop his ground breaking insights. This sounds a lot like Contextual Inquiry.  The article in the Weekly Standard describes his work this way: his method was “demanding careful study and actual data from empirical measurement and field research, applied at just the right level of theoretical generalization for the problem at hand.” His work covered a number of decades and he was doing Contextual inquiry before that word came into common use—in fact, Contextual Inquiry is based on the field research methods used by sociologists like him.

While I know the value of Contextual Design as we practice it in the world of business, it was great to see someone who applied this same kind of method with such fantastic results.  As the Weekly Standard article summarized Mr. Wilson’s impact: “Large numbers of his countrymen learned that, when they saw an article with his name on it, it would be worth their while to read it; they would be bound to learn something, and even if they disagreed with his conclusions, they would for the moment be in the company of a man who knew how to think seriously.”

A pretty impressive homage.  And as the Economist wrote of Mr. Wilson, “as a scientist, political or social, he needed to count and collate things to find the answers to his questions. But nothing that was really important about human beings, he once said, could be measured in that fashion.” So while our technology may allow us to measure clicks and website tracking it won’t give us the motivations and intents human beings have. You have to actually go out there and talk to them in order to understand.

What makes products Cool? How can teams design for Cool? What mysterious forces need to align in order to create the most innovative products on the planet? To find out, we immersed ourselves in the experiences of everyday people as they used their coolest products. And we discovered there’s really nothing mystical about it.

Check out the full webinar description here to sign up.

Learn “What Makes Things Cool”

View companies we partner with

It’s always exciting for us to see what we call practical innovation in action—companies leveraging existing and emerging technologies with their own unique skills and capabilities and doing the “next right thing” for their customers. And when it’s all the product of a well-executed customer-centered design strategy—especially one we’ve been able to influence—it’s particularly satisfying.

General Motors Takes a CUE from Customers

by Larry Marturano

Infuse insight into your products and organization
Everything we do is driven by a deep understanding of your customer

Any time that a new platform emerges, it calls for new design principles and techniques to truly bring the possibilities of that platform to life. Starting with the iPhone in 2007, a new era of mobile life is upon us and people are flocking to all kinds of touch and mobile devices. These devices and associated apps, along with other “cool tools,” have begun to transform the lives of everyday people and workers alike. What never was possible before is now easily possible; the pain of technology use and life hassle has evaporated in a “Poof!” as if by the tap of a magician’s wand. A new way of living has been born.

In 2010 we started our Cool Project to understand the cool user experience and the way cool tools have transformed people’s lives. This research, a combination of qualitative and quantitative data, identified the core factors of cool expressed in the Wheel of Joy and Triangle of Design. My Interactions article introduces you to these core concepts. We hope it will start a dialogue about how to deliberately design cool into your products, apps, and devices.

Since this publication we have continued to collect data on the cool user experience in different business segments. I am pleased to share that the seven factors of cool have been validated and extended by our foray into the lives of business users at work. Moreover, our preliminary work creating reliable repeatable measures for cool have indicated that the cool factors are stable and measurable.

With stable concepts comes the possibility of new design principles and techniques. Currently we are developing and validating these design directions in collaboration with our clients. And take a look at our new offerings to help your team understand and design for cool.

So it was exciting to see General Motors announce their next generation driver experience this month. The “Cadillac User Experience,” or CUE for short, will appear on flagship Cadillac brand products beginning in 2012. With CUE, Cadillac integrates the car’s infotainment systems with a truly modern user interface. Combining touch and haptic feedback, natural language voice interaction, proximity sensing and judicious use of buttons and controls, CUE enriches in-car information, communication, navigation, and entertainment, while at the same time simplifying the interaction and tailoring it to the driving experience.

CUE is revolutionary in the automobile industry, introducing a number of capabilities for the first time. The 8-inch capacitive touchscreen center stack display features multi-touch and haptic feedback.. The display shows a simplified set of icons and information to minimize distraction during normal driving, but when the integrated proximity sensor detects a finger approaching it, richer information and controls are automatically shown. The 12-inch LCD cluster display is easily reconfigurable to match your driving style. Media from up to 10 connected devices and drives are aggregated and can be navigated and accessed as one library. The speech interface allows your emails and texts to be read to you—and for you to respond, without ever having to take your eyes off the road.

It is quite unlike anything yet seen in automotive interfaces—more akin to the iPad than a car. No doubt to underscore this break from the past, GM chose to announce CUE not at an automotive event, but at CTIA, the main wireless telecommunication industry conference.

Early reviews based on pre-production units has been overwhelmingly positive: “CUE has the potential to be a real game changer” (Motor Trend), “Smartphone and tablet manufacturers should take note—this car manufacturer just showed you how to do car mode” (Android Central), “…it could prove to be a huge improvement over the convoluted control knobs on German and Japanese luxury cars.” (Forbes).

The design of CUE started with a joint InContext/GM exploration of the attitudes, values and behaviors of 32 drivers in four North American cities, with a focus on information, navigation, entertainment and communication. It’s been particularly gratifying for us to see how much value GM places on the customer-centered philosophy that underlies CUE’s design—even in the press release that accompanied the announcement:

“CUE development began in 2008 when Cadillac designers rode with 32 consumers for six months to study driver habits. Engineers and designers then used the data to develop CUE.”

They even explicitly called out the Contextual Design models they used in their CTIA presentation:

In addition to generating the core design concepts, the study also generated the ideas for some of the underlying technology as well—in a published paper describing the user research, GM notes:

“The Contextual Design effort described here provided significantly more innovation to our infotainment and telematics systems design than GM’s previous user-centered design methods of relying on the collective experience and wisdom of the designers/engineers and conducting usability tests to incrementally improve a design. This project alone resulted in over 180 new design ideas, from which 33 patent submissions were presented for approval, 8 were approved for patent filing, and 3 had defensive publications written.”

Of course, the initial customer data gathering and concept creation were only a small part of the huge effort that went into executing CUE. Still, driving innovation of this kind is what gets us all up in the morning and it’s very satisfying to see front end research, ideation and requirements definition executed so well as part of a long term experience strategy.

From a new product development point of view, there is a larger and very important point that is illustrated with CUE: significant innovation can and does result from a well-executed, integrated development effort incorporating customer-centered design. A common criticism of user-centered design is that “asking people what they want” simply results in incremental innovation. And I think that is probably true—except that user-centered design isn’t about asking people what they want. It’s about understanding the intents, behaviors and attitudes of the people who will use your product, and then using your own design and domain expertise to create solutions that support their lives, even if it means restructuring and improving what they do and how they do it. It’s about redesigning products and—in the most elegant and profound designs—redesigning lives.

CUE is an innovative, bold step. It represents a practical combination of best-in-class interaction design and technology from computing and telecom and combines it with GM’s particular expertise in automotive engineering and design. Time will tell, but I believe it truly is the right next step for them. Kudos to the GM product planners, engineers, designers and management for trusting customer-centered design and for making such a courageous break with the status quo.

Join us in Seattle November 7-9 to learn Contextual Design, the industry-leading approach to user-centered innovation.   This intensive, hands-on public workshop is for anyone who has a part in defining and designing things people use—products, systems, services, or processes. Contextual Design provides you and your organization with a practical way to successfully start with a problem or idea—the “fuzzy front end”— and navigate through to a user-validated design.

By attending, you will learn how to reliably:

• Capture detailed user data that provides ongoing value for future products
• Create coherent, user-centered visions to drive your road map and requirements
• Discover hidden and emergent needs in your market or user population
• Understand the underlying causes of customer satisfaction issues with your product or service
• Define a user-centered system structure and behavior for your products
• User-validate requirements for your next release before committing to development

The workshop is offered in three one-day courses, each designed to be standalone and develop a core capability you can use. So you can attend one, two, or all three days to best fit your schedule, budget, and learning needs:

Monday, November 7 – Contextual Inquiry: Innovate from deep customer insight

Tuesday, November 8 – Visioning: Invent a new customer experience from user data and design thinking

Wednesday, November 9 – User-Centered Requirements: Define and validate products and systems that people will use

Click here to learn more and register.

View flyer here.

But what happens when processes developed independently achieve wide adoption and come into contact with each other? Do they provide synergy, or do they get in each others’ way? The answer may very well be “both.” User-centered design and Agile development provide a case in point.

Evolving a Process: Contextual Design. Processes are when people within companies try to get their work done  they think about and discuss how to work; they try out different approaches, borrowing techniques from other places and inventing their own. If they’re successful, they may formalize the process and sometimes even give the process a catchy name and write books about their “way” of designing systems. But any new process originates within a particular work context, history and culture and tends to reflect that culture. This is exactly how Contextual Design (CD) itself started at Digital Equipment Corporation in the US.

CD was developed to support innovation in design through a deep understanding of users. Like most processes, it combines and repurposes techniques that came before. Contextual Inquiry, the field research technique, was an adaptation of ethnographic and grounded theory methods Karen used in her doctoral dissertation. The affinity diagram came from the Total Quality movement. And paper prototypes were an adaptation of the Participatory Design approach developed in Denmark. [ref] All these elements came together into a process that worked for Digital’s developer-centered, non-hierarchical culture.

This early version of CD was fine within Digital, but when we left and started InContext in 1992 we learned what worked for Digital didn’t always work for other companies, different products, or different corporate or country cultures. And so CD evolved to address new circumstances – and as we expand it to new industries and new types of problems, it keeps changing. For any method to stay relevant, it must evolve from the original business culture it grew up in.

CD was just one aspect of an industry-wide push towards user-centered design. Platforms were changing throughout the ’90s and ’00s: WYSIWYG, direct manipulation, the internet and web, mobile phone interfaces and touch screens. These new platforms posed new challenges in developing usable designs and made it critical to work with users who were not developers. Careful interaction design and visual design became more important as end-users became less technical. “User Experience” (UX) has now become the umbrella term for a user-centered focus in development: field research driving requirements, interaction design iterated with users, usability testing, visual design, etc. All these new techniques require a new role – the UX professional. They are now part of organizations – each creating their own “way” to get the requirements, the function, the structure, the interaction, and the look right.

The challenge of software development. In parallel to user-centered design, another process challenge faced product-making companies: delivering the product on time. Delivering the right thing on time is an age-old challenge – it is the holy grail of controlling a product development environment. And coding is just another “way” of working – people working together guided by a shared understanding of what is to be made and the steps to get it done.

At the time Contextual Design was born the waterfall method of software development was the rage – define what you want as explicit requirements, design the implementation to build what the requirements say, write the code, and test to see you built the right thing. It’s simple, logical, and very well suited for the supplier/client relationship beloved by the government.

Unfortunately, too often it didn’t work. It turns out to be very difficult to exactly specify every detail of a complex software system, to ensure that your specification does what you expect – and to ensure it’s useful in the real, messy world of work. To develop more reliable specifications and ensure they were correctly implemented, the software development community produced more and more complex methods of modeling requirements, the data itself, system behavior, and implementation architecture.

The other big problem with waterfall was time. The whole system was specified at once. It might take 2 (or 5, or 7) years to go from initial conceptualization to final delivery using the waterfall approach. This frustrated marketing, management, and everyone else. If you were wrong, it was a very big deal to fix and a very long wait to the next release – and you were always wrong, to some degree. You could get a good score on the maturity of your software process and still not excite the market or move product in a timely way.

This was the context in which Contextual Design method was developed. Multiple modeling techniques were an expected part of development practice. So it was natural for us to include models in CD – the work models to reveal how people work and the User Environment Design (UED) to show the structure of the system as experienced by the user. Such models were a natural extension of the way coders already worked. And Contextual Design – like other user-centered design methods – promised to improve the accuracy of requirements, offering some confidence that your 2-7 years of development would produce something that was essentially correct. So long, that is, as your requirements haven’t changed.

In parallel to all this, IT (Information Technology) departments were building and delivering code to internal business users. And if it was hard for product makers to get clean requirements from customers outside their organization, it was even worse to get requirements from the business. Why? Because the people making the tools for you are just down the hall – it’s just too easy to run over and say, “add this,” “make me that.” IT is always prone to becoming just a technical secretary – at the beck and call of senior users.

Small local changes makes looking at things from an architectural point of view is very hard. Each department developed their own little version of ordering, or project management, or scheduling, and their own glue code to make it all work. This is the bane of IT departments – a million special-purpose systems, unintegrated, each with its own interface. This is the world in which single–sign-on is an exciting development – because it is so difficult to achieve given existing systems.

To prevent falling into the “technical secretary” trap, IT folks looked for a process that would give them some control over the systems they were developing. They looked to various waterfall methods – the Rational Unified Process (RUP) being the latest – to impose order on the requirements coming from the business. But the result was that the internal team was perceived as highly unresponsive. It should be easy to get software from an internal organization – but instead, heavy, formal processes with many required steps and elaborate intermediate deliverables created a long, slow, cumbersome development methodology.

Worse, it seemed that no matter how formally the IT group communicated and how carefully they made the business say what they wanted, it just wasn’t ever right. The business was hardly ever happy once they saw what their requirements turned into. Business and IT  tried many things to handle this problem – putting work experts into the IT organization to help translate requirements to engineers; heavy change order processes so the business had to go through pain if they wanted to change requirements; Joint Application Design (JAD) to get better requirements from business stakeholders; formal contracts between IT and business – and still the requirements weren’t right, and still the business wasn’t really happy, and still development took way too long.

Evolving a process: Agile Development It is this IT culture that birthed Extreme Programming (XP), one of the first Agile methods, and this culture informs much of Agile methods today. Forget getting the requirements right, says Agile – just write simple stories describing what the user should get from the system. Make them simple – put them on an index card so no one is tempted to make them too elaborate. Keep them short, so we can code up a bunch of them in just a 2-4 weeks. Then check with the business partner. Show them what we’ve done. If they like it, good – if not, little harm done. We only invested a few weeks of work; we can go back and fix it. The process is fast, it produces value quickly, and we don’t need all the big heavy Business Requirement Documents and many, many meetings to figure out the entire strategy and architecture. Just do a little at a time.

Of course, Agile methods are more sophisticated than this quick summary suggests. They include coding practices which make the quick iteration and rework possible, as well as people and process management to keep everything on track. But the core insight of Agile is to use fast iterations to produce measurable customer value, getting a course correction from the customer at the end of each iteration.

It’s no accident that this approach grew up at the same time as rapid prototyping was becoming popular as a requirements gathering technique. Rapid prototyping is another method of putting a system design in front of stakeholders to get early feedback. Everyone in IT was struggling to figure out how to get the business to articulate what they really needed in their applications. Agile’s rapid iterations of code is just one further step from rapid prototyping – wrapped into a larger coding and project management process.

When worlds collide: Agile meets User Centered Design So we have the parallel evolution of two processes: user-centered design and prototyping for the front end, and Agile development for coding. Both processes address getting requirements right, but they come at it from different points of view, leveraging different tools, skills, and organizational roles, and different cultures. UX focuses on the design of the user-facing function, layout, and overall user experience; Agile assumes you have an idea of what to build and focuses on how to run a team to develop and check it out quickly.  You’d think they go together well – and they can – but in practice it hasn’t proved to be so easy.

Bringing the two approaches together is made more difficult because Agile itself is evolving. XP assumed easy access to users because of its IT heritage; Scrum started in manufacturing companies where software requirements were internal and assumes the Product Owner can answer all questions. These assumptions don’t hold true in modern software product companies – so introducing Agile means it has had to change. What do you do when your customers don’t work in the same building? How do you decide what to build when you don’t have the business telling you what they need? How do you embed Agile development in a product development process that has to include marketing strategies, making a business case, developing a product support structure, and supporting sales?

Moreover, businesses (including executives, development managers, product managers, the support organization, and coders themselves) are used to a waterfall method – plan, design, code, ship. They are usually not ready for the mind-shift Agile requires. Adopting Agile often means, “develop in short iterations” without changing any other part of their business practice.

And yet, as the Agile community itself has come to realize over the past few years, Agile development must expand its scope if it’s to support product development organizations well. Traditional Agile development starts with “Write user stories” – but what goes into those stories? Who gets to say, when you don’t have an internal business customer sitting next to you? Defining a “Customer” or “Product Owner” role just begs the question – how do they know what the real customer wants? How do they know what the real users do on a day by day, minute by minute basis?

Traditional Agile methods don’t have a workable answer to this question – but user-centered design does. Just like the development processes so many years ago needed to get into the field to understand user requirements, Agile also needs a reliable requirements process. Just like the previous development process needed to work with and iterate with users directly – not customer representatives – Agile needs to work with the real end-users.  Then Agile as a development process can pick up where user-centered design leaves off. Where Agile is weak – in getting sound, reliable information from and about users – UCD and user experience professionals are strong. These approaches don’t just go together well. They need each other.

That is why we at InContext have been so heavily involved in the Agile community since almost the beginning. Our paper, written with (then) Lisa Baker of LANdesk in 2004, was the first to describe interleaving UX and Agile work in the way that has since become standard. We wrote Rapid Contextual Design in 2005 to provide techniques useful in an Agile context. And Hugh’s publication User-Centered Agile Methods describes in depth the relationship between UX and Agile, and provides strategies for integrating the two.

We’ve also defined services to help our clients bridge the gap – to implement Agile in a strong, effective, and user-centered way. If you’re struggling with this transition, we’d love to hear your story.  It doesn’t have to be a train wreck when Agile meets user-centered design. Agile doesn’t displace or replace UCD. But it does mean that we have to think about how people and the processes can work together well.

When methods collide it challenges us to find the third alternative – it challenges us to think of new ways to help the people building products work together better. We believe that Agile is the best way to build products with a controlled process and in realistic time frames. And, of course, we believe that getting to your users in the context of their real life is the best way to understand what they are doing, what they might need, and how to transform their world. It’s been fascinating and challenging to be at the forefront of bringing these best practices together.

References

Participatory Design

Ehn, P. Work-Oriented Design of Computer Artifacts. L. Erlbaum Associates Inc., Hillsdale, NJ, 1990.

D. Schuler and A. Namioka (Eds.), Participatory Design: Perspectives on Systems Design, N.J.: Lawrence Erlbaum Associates, 1993.

Contextual Design

Beyer, H. and Holtzblatt, K., Contextual Design: Defining Customer-Centered Systems, Morgan Kaufmann Publishers Inc., San Francisco (1997).

Holtzblatt, K., Wendell, J., Wood, S., Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design, Morgan Kaufmann Publishers, San Francisco, CA, 2005.

Agile Development

Agile Development and User-Centered Design

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S. Schwaber, K., Sutherland, J., and Thomas, D. The Agile Manifesto, 2001. http://agilemanifesto.org

Beck, K. eXtreme Programming Explained: Embrace Change, second edition. Addison-Wesley, 2004.

Beyer, H. User-Centered Agile Methods. Morgan & Claypool Publishers, 2010.

“We can’t seem to nail down requirements and suffer from feature creep”
“I wish we had a better way to prevent missed or incorrect requirements”
“My team is fighting about what direction our product should take”
“I want to create an innovative product, but I’m not sure where to start”
“I have a new product idea, but don’t know if customers will want it”
“I want to improve the user experience of our products”

By attending this workshop, you’ll learn how to reliably:

• Capture detailed user data that provides ongoing value for future products
• Create coherent, user-centered visions to drive your road map and requirements
• Discover hidden and emergent needs in your market or user population
• Understand the underlying causes of customer satisfaction issues with your product or service
• Define a user-centered system structure and behavior for your products
• User-validate requirements for your next release before committing to development

Learn the industry-leading approach to user-centered innovation

This intensive, hands-on workshop is for anyone who has a part in defining and designing things people use—products, systems, services, or processes. Contextual Design provides you and your organization with a practical way to successfully start with a problem or idea—the “fuzzy front end”— and navigate through to a user-validated design.

You’ll learn to use Contextual Inquiry, the best-practice user research technique, to gather data and develop deep insight into what people are trying to achieve in their work or life. You’ll learn how to use this insight to drive groundbreaking innovations. And you’ll learn how to validate a proposed solution by testing and iterating a mockup with actual users who use it while they work.

A flexible program to fit your busy schedule

This series is offered in three one-day workshops, each building on the other. Each day is designed to be standalone and develop a core capability you can use. So you can attend one, two, or all three days to best fit your schedule, budget, and learning needs.

Taught by experienced trainers and practitioners

The workshop includes real-world examples and exercises to develop skills that participants can begin to use right away in their work. It is taught by our senior professionals in small enough class sizes to ensure individual attention.

Wendy Fritzke—Senior Coach
Wendy has been coaching teams in Contextual Design techniques for 15 years. She has helped teams from a variety of industries—including software, hardware, healthcare, legal services, IT, customer service, and retail—define their product requirements and drive product design with detailed, grounded user data.

Dave Flotree—Senior Work Practice Designer
Dave has over 25 years of customer-facing business experience in user research, requirements analysis, functional design, and marketing of technical products. He has used Contextual Design with clients from start-ups to Fortune 100 companies in a wide range of domains including healthcare, legal services, financial, education, business systems, construction, and software.

Who should attend

Individuals or teams who have a hand in defining or designing products, systems, business processes, or services: product managers, designers, developers, marketing professionals, project managers, business analysts, quality managers, and consultants.

What you’ll learn and practice

Monday, November 7
Contextual Inquiry: Innovate from deep customer insight

Find out how to go beneath symptoms and feature requests to reveal the real underlying issues customers face and need help with. Learn how to bring customer data into your organization in a way that’s vivid and actionable for new designs.

Course Outline:

• Introduction to the principles behind contextual inquiry field interviews
• Practice how to conduct  contextual inquiry interviews
• Practice conducting an interview interpretation session
• Practice building an affinity diagram to reveal core issues and insights across a user population
• Introduction to setting project focus and planning contextual interviews

Tuesday, November 8
Visioning: Invent a new customer experience from user data and design thinking

Reveal and solve the core issues that exist across your market or user population, doing so in a way that inspires inventive thinking while keeping team conversations and ideas focused on reality and what matters most to customers.

Course Outline:

• Introduction to modeling how people work and live
• Practice building and consolidating work models, and analyzing them for design implications
• Introduction to visioning a new way to work or live from consolidated user data
• Practice participating in a visioning session, a facilitated ideation process
• Introduction to evaluating and improving visions to reflect business and technology realities
• Introduction to consolidating and dividing the vision into releases for implementation

Wednesday, November 9
User-Centered Requirements: Define and validate products and systems that people will use

Capture and organize requirements in a way that builds in usability by providing the right functions users need at the right time and place. Then co-design and iterate mockups with users while they work to uncover and fix requirements errors before committing to development.

Course Outline:

• Introduction to using interaction patterns to represent system structure
• Introduction to storyboards and User Environment Design to capture user-centered requirements
• Practice creating a storyboard to design the details of specific user tasks in a vision
• Introduction to paper prototypes and prototype interviewing with users
• Practice paper prototype interview for validating requirements
• Practice interpreting an interview to identify and resolve issues

Daily schedule

8:00     Onsite registration opens, light continental breakfast provided
9:00     Morning session begins
noon    One hour lunch break, buffet lunch provided
5:00     Afternoon session ends
Morning and afternoon sessions include 15-minute breaks with refreshments

The Agile conference continues to be one of the more exciting conferences around, and not just because they have trampoline and parkour performers at the conference banquet. What I love most about it is the sheer range of topics that are covered. There were sessions for programmers covering things like unit testing multithreaded code and how to do continuous integration. There are sessions for managers and coaches on how to introduce agile to an organization. There are two “stages” focused on the User Experience (UX)—one covering the UX role and UI design, the other one how to work with customers.

But in addition to these sessions focused on Agile itself, there were others looking beyond Agile: sessions on Lean development, on organizational change, on collaboration and team dynamics. There were sessions on fear as a roadblock to change and how to deal with it and on handling conflict in teams. And the keynote focused on positive emotions and why they matter for effectiveness, innovation, and health.

That keynote was especially interesting to me in light of our Cool Project. When we studied what makes products cool, we discovered that it’s because they hook into basic human motivators: the sense of Accomplishment, the need for Connection, the formation of Identity, and the pleasure of Sensation. When we can achieve these in our lives, it creates a deep sense of joy.

But that means that a cool product delivers small moments of joy throughout the day. Since research shows that positive emotions make us more effective and creative, does that suggest that cool products actually make us better people? Does the momentary joy of connecting to my distant child through a Facebook post that I read on my iPhone before going into a meeting make me more effective in that meeting? Perhaps cool products are compelling in part because we sense that they make it easier for us to be the people we want to be.

Grandiose claims, I know. But the research is there. What if it’s true?

Other sessions, though perhaps less far-reaching in implication, had immediate practical value. The integration of UX groups continues into Agile teams continues to be explored—among many good sessions, John Innes discussed how to track UX work within an Agile team context, both to identify the most important UX work to do and to track that it’s done. I also finally made it to Jeff Patton’s session on Story Mapping, a quick and surprisingly effective way of organizing stories to reveal the connections between them.

My own session was well-attended and well-received. I decided this year to give folks a quick and dirty introduction to running a user interview—a skill that’s sorely needed on an Agile team and that participants would be able to use right away. One guy said this was the “first session where I got concrete tactics”—which I don’t believe. I attended more than one session of practical use myself.

And of course, the conversations between sessions are just as valuable as the sessions themselves. Lots of folks (still) are doing Agile but with lots of questions about whether they are “doing it right”—taking full advantage of what Agile has to offer. Others are still working on introducing Agile in their companies and are encountering resistance, expressed or tacit. And just about everybody finds that their UX teams are stretched too thin. We have a range of services to help people with all of this—watch this space or hit me up directly and I’ll give you some options.

So, another Agile conference gone by. If you were there, why don’t you share what you thought were the highlights? And if you weren’t… let me know what you’d like to see in next year’s conference. Session proposals will be due all too soon.

References

I promised the participants in my session that I would post references to materials I’ve found useful in the Agile space. So here goes:

Rapid Contextual Design by Karen Holtzblatt, Jessamyn Burns Wendell, and Shelley Wood – How to incorporate user feedback into any fast-turnaround process. This book doesn’t discuss Agile explicitly, but the techniques it describes fit well with Agile development.

User-Centered Agile Methods by Hugh Beyer – A short book on integrating User Experience design and methods into Agile development.

eXtreme Programming Explained by Kent Beck – Still my favorite basic text on Agile development. Yes, it’s XP-centric, but the advantage there is that it covers a lot of the development practices which are core to making Agile work, and that tend to be overlooked these days.

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle – This is the standard Scrum reference.

In addition to the above books, here are some articles and papers that I’ve found useful:

Martin, A., Biddle, R., and Noble, J. “XP Customer Team: A Grounded Theory” in Proceedings of the Agile 2009 Conference (Agile 2009) , pp 57-64. IEEE Conference Publishing Services, 2009.

Martin, A., Biddle, R., and Noble, J. “XP Customer Practices: A Grounded Theory” in Proceedings of the Agile 2009 Conference (Agile 2009) , pp 33-40. IEEE Conference Publishing Services, 2009.

These two papers are a gold mine of information. The authors did a detailed survey and investigation of multiple Agile teams and used the results to identify common best practices for user involvement.

Morgan, D. “Covert Agile—Development at the Speed of… Government?” in Proceedings of the Agile 2009 Conference (Agile 2009) , pp 79-83. IEEE Conference Publishing Services, 2009.

A fun experience report that describes how a team used Agile, satisfied their customers (stakeholders and managers), and still failed—because they never got feedback from actual end-users. Useful if you need to make the case for doing real customer field visits.

Kollmann, J. Sharp, H., and Blandford, A. “The Importance of Identity and Vision to User Experience Designers on Agile Projects” in Proceedings of the Agile 2009 Conference (Agile 2009) , pp 11-18. IEEE Conference Publishing Services, 2009.

Makes a compelling case for having a whole-system user experience vision prior to starting Agile development. Useful if you’re arguing for doing some design or planning up front and you’re facing the “no Big Design Up Front” attitude.

I’m teaching one of my 16-year-old son’s friends how to do an affinity analysis on some data he’d collected for a high school “critical thinking” project. Sometimes I’m not sure how I get myself into these things. But here we were.

That semester, Cody had picked topic he was interested in, how teens felt about religion, created an interview protocol and a survey, and collected about 60 responses. Three days before the due date, he showed up at my door asking for help (hey, we’re talking teens here—three days is actually PROACTIVE in high school). His statistics seemed contradictory. His initial hypothesis, that teens who actively questioned their faith would be more satisfied than those who had blindly accepted theirs, didn’t seem to hold water. He had both questioning teens and accepting teens, but there didn’t seem to be much of a correlation with satisfaction or happiness.

I suggested we do an affinity analysis with his open-ended question responses and interview findings, and helped him create about 600 little yellow sticky notes, a separate nugget of “customer” data on each one.  We had just started the affinity, and we had small groups of stickies all over my basement wall.  The tempting sounds of my son playing Xbox were in the background. Cody was getting anxious.

“I don’t see where we’re going.  Can’t we just go back and look at the stats?”
“Dude. Chill. Just go with it.”

For those of you who’ve never experienced it, an affinity is a way to structure qualitative data so that it reveals the underlying issues.  You start with just a blank wall and your data points on a pile of sticky notes. Then you start putting stickies on the wall, clustering data points that seem to “go together.”  After groups form, you label the “go-together-ness,” or affinity, that the groups entail. You can also repeat this grouping exercise with the first level labels, and so forth. In the end, you have a hierarchical organization of labels that identify the main patterns and issues in your data—they tell the real story of the information you collected. The really cool thing about affinity analysis is that the issues surface directly from the data points—you’re not sorting the stickies top-down into preconceived bins, you’re letting the issues emerge from the ground up.

“It’s all just random groups—this is aggravating.”
“Cody. I do this for a living. Trust the process.”

Cody was going through the emotional gyrations that every one of our client teams goes through when they’re first exposed to affinity analysis. When we start, everyone is energized by the possibilities of four blank walls and the data lying in neat piles of stickies. But once the analysis starts the team frequently descends into an emotional sinkhole—the one Cody was in now. Chaos reigns as people walk around the room putting stickies up, making groups, and then taking them apart again and reforming them elsewhere. Soon the walls are covered in seemingly random groups of two or three or twenty sticky notes. You read a new note and remember something on this wall that was like that… but wait, someone moved it. So you put it somewhere else it seems to go, but you worry that it’s not quite “right.” You wonder aloud where that one item about X went. Who messed up your sticky note group around that?

During this phase, most people get at a little frustrated—it seems random to the untrained eye and it also seems like “organization” is the last word anyone would use to describe what is happening to all of that neat, clean data. You can’t see a way that this is ever going to come together. You worry about the logic of what you’re doing, and you doubt the whole process.

What happens in the emotional sinkhole is that you are being asked to think in a new way, a way you’re not used to. In grouping and regrouping the stickies, your brain is analyzing what it is seeing, recognizing and evaluating patterns in the groups. You are not simply looking at the data notes and mentally testing them against what you already know. You are not using deduction, which makes up the bulk of most people’s formal schooling and professional training.  Instead, you are thinking bottoms-up, recognizing order in what seems like chaos.

You are using induction.

Inductive thinking is a key component of design thinking. Most people are not comfortable in this mode, and the angst teams feel at this point is a real indication of just how dominant deductive, linear patterns of thinking are. Cody was feeling exactly this anxiety as he tried to get his head around inductive thinking (and resist the lure of Xbox at the same time).

The unease is palpable during the initial phase of affinity. But then something happens. Somewhere during the second day of one of our affinity building sessions, the sticky note groups stabilize and you move to a different part of the process—labeling the groups.  Now things become more comfortable, as you move back to a more analytical mode of thinking. The patterns start to become more obvious, and you start to see the light at the end of the proverbial tunnel. Usually this little emotional kick carries the team to the end of the analysis on a high note. You can almost see the relief on our team members’ faces as they get to return to a more familiar way of thinking and they see the payoff. Cody was no exception.

“Hey—now I can see four bigger issues why kids like and don’t like what religion does for them.”
“See?”
“That wasn’t in my stats. This is cool.”

Unfortunately, this difficulty in adopting a new way of thinking has far-reaching implications. In fact, I think the little emotional rollercoaster that we take teams on in a two day affinity analysis is the same journey that organizations and even whole companies go on in adopting design thinking into their business processes.  But whereas we have the luxury of an affinity analysis that is time-boxed to a couple of days, organizations trying to adopt design thinking as a way of doing business face a longer and more complex problem. It’s harder to play the trust card and just power through.

I think this might be why it is so hard to institutionalize design thinking—and its close cousin, user-centered design—in organizations. Too often, people and teams lose faith and then interest, and efforts falter amidst the prevailing doubt. Even in the C-suite, people are comfortable with linear, deductive logic, but the inductive ideation from observed behaviors and the iteration that characterize design thinking seem to break this logic.  It’s easy to doubt and lose faith in the process, sometimes even for those who are trying to champion design thinking in their organizations.

It may also be why so many companies struggle implementing Agile development processes; Agile, like UCD, is characterized by iteration and emergent design from small pieces. All of these diverse practices require a level of comfort with induction and iteration that is neither commonly found nor commonly taught.

The truth is that for the majority of us have a hard time trusting induction and iteration. It feels inefficient, meandering, and random. It feels “illogical.” It’s hard to trust the process.

It’s unfortunate, because the payoff is significant. Teams we work with invariably say the affinity is the point where they really start to have innovative insights into the design problem. And some of the most innovative companies in the world are the ones who have successfully integrated design thinking deeply into their business. It might be hard to trust the process, but it pays.

And Cody? In the end, he trusted and finished his affinity. In doing so, he found a rich set of reasons why his respondents were satisfied with their faith and how they got there, nicely augmenting his statistics and explaining the reasons and motivations behind the numbers. He turned out to be quite good at induction, actually. He pulled the “A.”

Now he wants help on Physics. Sigh.

One of the difficult problems faced by an Agile team is that of getting reliable user input. Since Agile projects depend on minimal up-front planning and specification, user feedback is critical. But product owners are rarely users themselves and the actual end-users are often located elsewhere and may be highly diverse. This session introduces participants to Contextual Inquiry (CI), a proven field research method for understanding users and their needs. We introduce CI, show how it fits into Agile development, and give participants practice in gathering data and then writing user stories.

Come if you can!

Agile 2011
Wednesday, August 10, 2011

When Apple came out with the iPhone in 2007 it was a game-changing product. Everybody was talking about it, even those not flocking to AT&T. People at parties gathered around the phone to watch the pinch, the swivel, the pictures, and the games.

The technology industry, including our clients, reacted as well. They were frustrated at not being able to create a game-changer like Apple. Everyone wanted their version of the iPhone impact. Now business products feel the pressure to produce a cool experience in products at work.

Business has been searching for the Holy Grail to guarantee transformative innovation for years. Go scan the business bookshelves—innovation that produces major profit is a never-ending discussion. Everyone wants to know the secret sauce.

A quick look at those books reveals that the innovation discussion falls into two camps. Many, many books try to address how to restructure your organization or team so that the people within it will innovate. Let’s call that organizational innovation. And other books talk about “cool” as it relates to marketing—how you make your sneaker, band, or vodka sound cool by association with stars or life experiences. Many fewer books address what we might call design innovation [1] —how to put products together that deliver practical innovations that people can put to immediate use.

Successful practical innovations like the iPhone deliver immediate transformative value. They are not a testing vehicle for what I call foundational innovation, interesting but as yet unproven technologies. Voice recognition is a great example of a foundational innovation that had promise but was not ready for prime time 25 years ago—or even 5. Products with voice recognition might make some money but they operated as prototypes and learning vehicles to help the technology mature. But today voice recognition—at least in English—is a practical innovation. Now we can really speak into the Droid at any text field and produce a sensible result that needs little editing.

Game-changing, practical innovations deliver value by transforming life—by changing how we work, live, and play so profoundly that they create the “can’t go back” experience. As one of our participants in the Cool Project said about the iPod, “What are we going to do, carry around a Discman® and CDs? No, we can’t go back!”

InnovationInCool hopes to bring to you knowledge, conversations, musings, fun, and our services too, as we explore the domain of practical design innovation. At the heart of our knowledge are our Cool Concepts built on the field data we collected through the Cool Project. What we have learned is that, although joy is at the center of the experience of cool, we know a game-changing product is cool because it creates that “can’t go back” experience. In the big or in the small, cool delivers something that once you have it you can’t imagine living without it.

But what produces that experience? Joy is our Geiger counter—it points us to what will feel like a profound impact. And the Wheel of Joy and Triangle of Design tell us what we should be thinking about to design for cool and produce successful, practical innovations.

The cool experience is intimately tied to successful design innovation. It’s not about finding one magic feature, not about being first with some new, untested technology that doesn’t quite work yet, not about finding a set of colors, transparent screens, black cases, or any other aesthetic. The cool experience shows us how to design game-changing practical innovation into products on purpose, every time.

Of course the experience of cool never lasts, because we get used to having the transformative impact on our life—we come to expect it. And then the hassles of everyday life creep in, blotting out our memory of how much worse it used to be. And so the opportunity for more cool and more practical design innovation emerges.

This is the endless cycle of product design. We must come to understand the cool experience so that when we look into the ever-changing lives of people we can see the opportunities to provide a new cool impact.

So join us, learn what we are learning about creating cool, design innovation, and product development. Contribute to our collective knowledge of design innovation by sharing your Cool Bites, your product stories, and what you have found that others should read.

——
[1] The word design has become nearly impossible to use. Some people think design only refers to industrial design–the look of an object. Others think design is interaction or visual design of software. We think design refers to all of that taken together with the definition and structure of any product. Design means the design of the whole product.

I was happy to start off the day with a packed room for my presentation, “I’m in the User’s Shoes, Now What? How an Empathetic Perspective on UXD Leads to Innovation”. The wonderfully engaged crowd joined me for a 45-minute overview of ideas concerning the importance of empathy in UXD and how an empathetic approach can help lead to innovative ideas. This was my first time with this presentation, and I was excited to share it with such a great audience.

I started with some thoughts around the parallels between rehearsal and UXD and the relevance of working in a cyclical and iterative process. My main point is that if your process is going to be empathetic, that requires lots of immediacy and touch points, so you need iteration. But the energy really picked up in my presentation when I moved on to talk about how to build a truly empathetic ensemble, one that moves beyond a team to find the kind of magic great improvisation abounds with. From the questions at the end it seemed like this struggle to build a harmonious ensemble struck a chord with many people in the audience. Understandable, as this is definitely a challenge, though not an insurmountable one. Practical and actionable recommendations were the biggest request at the end. I’m now developing workshop activities and real examples in action for next time.

From there, the day was an interesting mix that held some particular highlights for me. It was refreshing to hear others talking about interaction design from a structural perspective, before getting functional, in “Grid Systems: Building Blocks to a Better UX”. Using grids as a language to talk about the idea of structure was a clever choice by Klein and DiTommaso; making it relate to something everyone could easily understand and take something away from the conversation. It would have been great to get to see some more translation of grid systems into actual designs though and how the presenters have applied them in larger, structural systems.

Particularly exciting to hear was the session “Beyond Usability Testing” by Hawley and Berlin, and its proposal that sometimes you need to understand and evaluate the usefulness of a product before you can do usability testing. It reminded me of some of the ideas in the presentation David Rondeau and I did for MiniUPA a couple years back called “Why Usability Should Never Come First”. What I found great was the discussion around how to understand when your client is really asking to test for usefulness, when they think they are asking for usability. The presentation provided great clues for listening in order to separate that request out, which is fantastic. Oftentimes just hearing the distinction is the hardest part. I can’t emphasize enough how important it is to separate out these two ideas of usefulness and usability, and it was great to hear others singing the same tune.

One of the great things about going to an event like this is just getting to talk with people and hear what the themes and current issues are in the field. And I definitely was intrigued by some things I heard. In particular, I heard the word iteration a lot of times during the day from others, much to my surprise and pleasure. Though from certain conversations, like the one in the panel discussion “Building Out a User Experience Team,” it seems that we need to be careful to distinguish between iterative and agile. What I took away is that my point early in the day about the importance of the role of a “Director” (who holds the vision together) in an iterative process is critical. It is often a missing ingredient that makes agile frustrating, and at times unsuccessful. As UX professionals, we can provide true value by picking up this role.

Overall, I get the sense that User Experience as a field is swiftly moving into its adolescent phase – we’ve gotten our independence and now continue to test new ways to dress and characterize ourselves to find the best fit and presentation. This was different than last year where people still seemed more concerned with understanding the best practices; now the focus is on a strong voice and organization around User Experience and finding the right ways to engage with the rest of the organization in a productive manner. It’s wonderful to see the progress the field makes every year.

All in all, it was a good day at MiniUPA 2011. It was a great opportunity to share ideas and learn with other UX people. Check out the Slideshare event for presentations and photos.

It used to be that a professional publishing company had a concrete product and a clear value add. But today publishing companies are less able to capture value from those traditional print-based offerings and must find new ways to add value and grow. They are, in a word, being dis-intermediated by free web content and smaller players. For this discussion, when we say professional publishing company we are referring to companies that publish to business and educational professionals.

Over the past 15+ years, we’ve worked with numerous clients in the professional and educational publishing space on a wide variety of design projects. And what we’ve learned is this:

• The value companies have traditionally provided their customers—that of vetted, compiled, editorialized content, packaged in a nicely printed format and delivered direct to the customer—is no longer sufficient. They are being challenged to figure out what value they can provide and how to capture that value successfully.
• Simply moving existing content online doesn’t work. Many companies have tried. None have succeeded. Their failure is often what leads them to us.
• To add value, companies need to understand the context of work in which their information is used. Once they understand the customer’s work, they can see the opportunities to add value and create new services.
• The move to digital content delivery means publishing companies are going through the painful process of transforming themselves into technology companies, which requires a new skill set and way of thinking about themselves and their product.
• Traditional marketing methods of getting user input will never provide the information companies require to be successful.

Providing Value Starts With Understanding Workflow

Moving content online provides an opportunity. We’re not talking about the opportunity to add additional functionality, like full-text searching and linking and all the other obvious benefits that digital content offers. We’re talking about the opportunity to understand the customer’s workflow—the tasks, environment, and people that make up their day-to-day work. When our clients take the time to understand their customers’ workflow, they learn why it doesn’t work to just dump everything online. The customer isn’t living and breathing the content like the editors, content creators, and others at the publishing company are. Customers are using the information to get their jobs done. Once a company understands the details of the customer’s workflow, they understand why they can’t expect the customer to search five databases, for example, with different search interfaces just to retrieve the information they want. They understand they must offer a single, simple search interface for all content. And then they can extend the value of the content by, for example, supporting the customers’ tasks of compiling their research and sharing it with others.

One of our client’s traditional business was based on a strong customer and service representative relationship, where the customer would call up their representative, ask for some very specific information, and the representative would track down the information, compile the information into a report, and send it to the customer. As this company started looking for new value opportunities online, they studied the workflow of their customers and decided to implement a self-service model that integrated their information into the overall tasks of the customer. The design solution for this project was a single place where the customers could track their tasks, get resource documents, and access tools and templates. And since they had studied the existing customer and service representative relationship, our client knew that, to be successful, the new self-service system had to be as reliable as the trusted representative and provide a comparable sense of personalized attention.

Prevent Misapplication of Industry Trends

Once a company understands the work that their content supports, they see where value can be added and what opportunities there are for new services. They also learn that a value for one audience will not necessarily transfer to another customer base. And, equally important, they learn that they can’t just implement the latest trend without understanding if it will fill a need—that is, add value—for their customers.

For example, after working with us, one of our clients created an integrated workspace to support their customers. This workspace included not only information to help these professionals make business decisions, but also supported other tasks such as monitoring and reviewing interactions with their customers and vendors. The design also included a community element, where customers could get insights from trusted sources in the larger professional community. Supporting the use of information within the community became a key element of this design and a new value that the company could provide.

However, when the same idea was tested with another of our clients that supports the medical community, it was not successful. We learned that medical professionals wanted expert commentary on specific articles, but they were not interested in having discussions with or getting opinions on an article from the larger medical community. What they did want was relevant medical information easily accessible when providing patient care. In another project, we found that if the medical publisher brought their content closer to the center of the work—the patient’s medical record—the publisher was offering greater value. This integration of content with patient records also helped cement the relationship between the medical professional and publisher by positioning the publisher as a partner in getting the work done.

The above is an example of how a concept such as networking can become popular, and companies jump on the bandwagon. But without understanding the details of the user’s work, what works for one group won’t be successful for another.

Understanding Workflow Reveals Common Structure that Can Be Leveraged

Understanding the specific work of various market segments also allows a company to successfully deploy a corporate-wide solution across individual customer populations. For example, one client that supports educators needed to understand what their customers liked in an existing system that would soon be replaced. They also wanted to understand how to take their corporate-wide search engine and tailor it to this specific audience. Extensions to the base search engine included adding more search types to cover content that instructors were using in their classes, such as images and video; creating browse categories specific to the various disciplines; pulling in discipline-specific websites as related links; and making sure discipline-specific journals were prioritized in the search results. This sort of customization by population allowed our client to reuse the core functionality of their company, while creating a personalized experience for a particular audience that made their customers feel our client truly understood their work and the information they needed to do their jobs.

Finding the right value add for each customer base and implementing a solution that fits the customers work goes a long way toward addressing another key issue digital publishers face—maintaining credibility. Our clients have a long, respected history in their specific content domains—one that can be threatened by a poorly designed and implemented online offering. It is vital for publishing companies to treat the online experience they offer their customers with the same careful care and consideration that they are accustomed to providing with their print materials. The problem is, as a company, they often lack the skills to provide the same high-quality online experience—because they aren’t used to thinking of themselves as technology companies.

And Then There’s the Technology

Providing content online, and especially providing the kinds of integrated workflow solutions and good user experiences that we’ve been talking about, requires that a publishing company essentially transforms itself into a technology company. This change requires a shift in skills and personnel; from the skills of traditional editors, writers, print designers, and production specialists to those of developers, testers, and UX folks. This shift can be extremely painful as companies struggle to balance their existing expertise—still required for delivering high-quality content—with the new expertise demanded for thriving as a digital publisher.

One pitfall we’ve seen companies fall into is adopting the technology mantel so completely that the technology, with all its seductive capabilities, becomes “the product.” Each new release focuses on implementing additional functionality and exploiting the features of the technology. They lose sight of the customer who is actually going to use the new device/app /JavaScript widget. The focus is “platform, platform, platform,” rather than the customer’s work and how it might be supported by the platform.

Then there are the problems that traditional technology companies have been grappling with for years that digital publishers now need to address as well. For example, what kind of underlying systems must be in place so that content can be written once and output to multiple platforms, including print, web, and multiple mobile platforms? The growing field of eBooks and mobile apps has both expanded and complicated the possible solutions.

Another is the problem of communication. In technology companies, it’s often the marketing and product management people who don’t know how to talk to the developers who in turn don’t understand the UX perspective. In the digital publishing world, the technical people don’t understand the content creators and vice versa. In both cases, having detailed customer data gives all sides a common language and a common thing to focus on—the needs of the customer.

Bringing It Back to the Customer

Recently, we’ve seen the publishing industry start to right itself from their infatuation with the platform. The industry is aware that they need more customer input to be successful. But our experience has taught us that the traditional marketing techniques such as focus groups and surveys that companies tend to use will never get them where they want to go. When you want to become part of the customer’s workflow, you need a level of customer intimacy and detailed user needs that are not needed when producing printed materials—and simply will never be gathered from a focus group or by asking customers what they want. You need the kind of detailed, grounded data that comes from watching customers really use the content in the course of doing their daily work. You need the kind of data that comes from doing Contextual Design.

In a few weeks I’ll do a more formal introduction to the community of this new direction for InContext when we launch the website www.innovationincool.com. Right now the website is just a placeholder where you can sign up to be notified of the launch. More importantly, you can contribute to the content by sharing your “cool sightings.” Any time you think something is cool—any time something makes you say “cool!”—share it, and tell us why. It’s a community inquiry: What are we paying attention to when we use that word?

Once we decided to find out what makes things cool, our Cool Project started by collecting opportunistic bites of cool from real life. Then we did a large field study and discovered the set of concepts represented in the Wheel of Joy and the Triangle of Design, articulating the core factors that produce the cool experience. My talk at CHI introduced these concepts, which will also be the basis of my new book.

It turns out that what draws us to use the word “cool” is not always what makes the cool experience game-changing. Someone at CHI showed me a business card holder with a neat design on the top—“Cool!” I said. I bought a big painted egg when in Australia because it was “cool.” One way we use the word “cool” is when we see something interestingly different—whether it is technical, art, or architecture.

But it turns out that the cool experience of game-changing technology (like the iPhone) goes well beyond aesthetic uniqueness or even bits of fun and surprise. Cool technology that is game-changing has a profound impact on life—on the way we live our life. This impact produces an experience of joy. The Wheel of Joy and the Triangle of Design reveal how technology produces that joy. With these cool concepts as tools, designers can start to define and make tradeoffs to help produce the cool experience with their products.

I was pleased with the reception of these concepts at CHI. It started some of you thinking—which, of course, is the goal. I spoke with one person who went away deep in reflection about where he was in his life and how technology was helping him stay in the unstoppable momentum of life—one concept we talked about. Indeed, he got so distracted about how the cool concepts revealed things about his life that he wasn’t thinking about what it meant for design!

But the cool concepts have pretty profound impact on design thinking. For example—what does it mean to re-conceive your product in terms of its place in the whole flow of life? Central to cool is getting all of life’s activities and obligations done without stopping. So to make something cool you can start by asking yourself:

• Is your product a core activity that is valued by the person such that it has a right to claim attention and time? And if so—even core activities are only focused on for 15-30 minutes or even less at a stretch. Can your product support this kind of attention shift?
• Is your product offering really seen as a chore activity—something someone has to get out of the way to get on with the real things in life? Setting up travel, expense reports, setting up meetings, balancing accounts, doing what HR asked you to do… Chore activities are cool when they can fit into the dead time of life and get done with minimal and split attention.
• Or is your product really providing a momentary activity—something we like to check in on in those spare moments between core activities or in that dead time while waiting. Checking, monitoring, looking at status are all simply momentary activities—not a call for a big portal. So products are cool when momentary activities actually fit into moments and keep life moving.

Core time, chore time, and momentary time all come together to make up the whole of life as we try to balance home and work commitments—and never stop moving. They get differential time slots and attention—they get a different willingness to sit at a desk versus act on the run. When products fit into the flow of life as we like to live it—they are profoundly and lastingly cool.

But these distinctions are only one part of the cool factor of accomplishment found in the Wheel of Joy. When we can keep our life moving, we feel that we have accomplished our life on that day—and we say, “Ahhhh.” We say, “I’ll never go back to that old, stodgy way that holds my life hostage—this new way is too cool.” And that is why DVR’s are still cool after all these years.

The unstoppable momentum of life is only one example of the kind of thinking that our cool concepts can start to push. But like all new ideas they will bump up against existing assumptions and they will bump up against existing product design practices. So I look forward to sharing the implications of these concepts for our practice in HCI.

And I look forward to hearing from all of you about what cool means to you and what you think about our ideas—because we know that the next phase of software and technology development is going to be impacted by all the new platforms and interaction techniques. Getting a handle on how to think about what makes things cool is imperative for product success—and, well, just having fun making things cool.

So please watch out for our new site—and for more on how we use the cool concepts to push design thinking. And to those of you who attended the course, let me know what you are thinking now!

If you’ve ever been to CHI, you know that there is always a strong focus on academic papers and research. But I noticed two definite shifts this year: a stronger emphasis on “design” throughout the conference and a new interest in the history of design.  

This was most evident in a great talk given by Bill Buxton and also in the Buxton Collection—a mini museum of input and interaction devices that he’s collected over the past 30 years. The collection was on display at the conference and it was a fascinating journey through the past. It contained various input devices like early mice and joysticks, experimental keyboards, electronic rolodexes, and the first touch-screen smartphone from 1993. But Buxton’s point wasn’t just to show off a fancy collection of gadgets, it was to start addressing a problem he saw in the field of digital technology.

In his talk, he argued that just by introducing digital technology, we are in fact designing culture—whether we mean to or not. He looked at other fields of cultural importance, like art, music, dance, or architecture, and found that in each, learning and understanding the history is a core part of the field. This however, is not the case with digital technology, which is why he’s made the Buxton Collection available to everyone.

It’s great that we’re starting to make the history of digital technology available, but I believe we should also be doing the same for interaction design. We need to understand the history of digital design on screens and how it has changed. It’s not because the basic interaction design principles change over time, because they haven’t. The principles we introduced in the CHI course—prominence, relationship, flow, clarity, simplicity and consistency—were just as relevant 25 years ago, they probably just had different names. No, the history matters because how we apply those principles has changed as our technology changed.

This is because each new technology brings with it new opportunities and new constraints that affect how we design the interaction. Let me use the history of spreadsheet software to explain. If we look back at the first spreadsheet software, VisiCalc, it seems primitive now, but was revolutionary at the time. It introduced great new features, but the interaction was constrained or shaped by the technology of the time. It had to run on a desktop computer, with a monochrome display, a slow processor, and only a keyboard for input. Next came applications like Excel 2.1, which started using a new style of interaction called WIMP. It allowed for more direct manipulation, made possible by better displays, the use of a mouse for input, and of course, faster processors. After that, AJAX and other technologies allowed applications to appear on the web, like Google Spreadsheet. They also introduced a new style of interaction, sometimes referred to as RIAs or Rich Internet Applications. Even though the primary goal of RIAs was to emulate the capabilities of desktop applications, they introduced entirely new methods of interaction as well as new constraints that were not seen on the desktop.

If we examined each of these applications, we’d see that the high-level structure of the interface hasn’t changed much: each is a basic spreadsheet with associated tools. The basic interaction design principles didn’t change either; the products that were successful had good prominence and relationship between elements, good flow between steps of a task, and how to use the software was clear. What really changed were the interaction design solutions created in response to the technology.

With larger changes in technology come more dramatic shifts to the interaction design or even entirely new paradigms of interaction. In this case, an understanding of the structure and principles of interaction design becomes even more important. You only need to look at the current interaction paradigm shift caused by touch-screen technology in new mobile devices like smartphones and tablets. Unfortunately, many of the apps are created with no real understanding of the new opportunities or constraints introduced by this technology and used in a mobile context. If we don’t look at the history, we can’t apply the lessons learned. Instead, with each paradigm shift, we tend to reinvent the wheel and repeat the mistakes of the past.

In the end, our challenge is to create successful products and that means applying the principles of interaction design in a way that best fits the opportunities and constraints of the technology. This is what our CHI course was about and it’s how we approach design at InContext. We look at design from an intentional and deep structural level, not just the surface or visual design level. It allows us to see the repeating patterns of interaction, which when combined with rich, qualitative user data, leads to higher quality, holistic designs that work for the user, the business, and the technology.

It’s easy to think of interaction design as just a wireframe or a layout, but it really impacts our culture at a deep level—just as much as the actual digital technology, if not more. If we are indeed “designing” culture, as Buxton argued, then understanding the lessons of the past will be critical. We’re already seeing evidence of this in our recent research on what makes products “cool”, which reveals how digital devices and our interactions with them are changing both our cultures and our patterns of living. I think we need to recognize that “interaction” design isn’t just how we deal with the interface—it’s also about how our creations fit into and shape life itself.

I’m interested in your thoughts, and I’d love to continue and expand the discussion that was started at CHI. As interaction designers, how much interaction design history do you know? Does it inform your designs or do you feel like you’re always reinventing the wheel? Has knowledge of the past helped your interaction design? Or has lack of knowledge hindered you in some way? Drop me a comment below, I’d love to know what you think!

The problem is that everyone is having the same issues at the same time, so even when solutions do exist they aren’t well known. Moving the industry to an effective integration of Agile development with UX and the larger product development practice is going to take a lot more education, promotion, and repetition of the basic message.

Some elements of workable Agile methods are becoming more standard. Lots of people are working in the mode where the UX work is done a sprint or two ahead of the development work. This makes space for actual design to happen, which is a necessary thing if you want a successful product.

Many people are still struggling to find a place for design. Partly this is because they never had strong processes to support design—it’s still very common that the product manager and marketing write a PRD (Product Requirements Document) with minimal input from designers and no real user-centered process. Designers are then stuck trying to layer real field research and interaction design on top of a system that was conceived without a deep understanding of users. In these organizations, there used to be slack time while development wrote specs and worked out their architecture—and this could be used to sneak some UX design into the process. With Agile, that slack time disappears. I spent a lot of time talking to people about how to get it put back in.

A lot of folks talked about issues they’re having writing user stories. It’s not really a sexy topic, but it’s core—if you can’t write well-scoped, coherent, independent user stories to capture your user needs it’s pretty hard to do Agile. Expecting the Product Owner to write a PRD and then somehow disassemble it into user stories is not the most efficient approach to this. Plus a lot of organizations expect the Product Owner to do this on their own, which makes no sense at all. It’s a much lower level of detail than project managers or marketers are used to—they need help to figure out the details at this level. Once, UX designers would have been creating wireframes, which clarified the design issues—but now this step is missing. We’ve actually got a service to coach this process, just to get teams through it.

Both of these issues (and lots of others) are solved by giving the UX designers their rightful place at the Agile table. That’s what my session at CHI was about—not only can UX be integrated with Agile, but it must be if Agile is to be successful. You can’t do Agile without a strong connection to the end user, and it’s the UX people who have the skills to maintain the connection.

I’d like to hear more about how people are doing with user stories. In a lot of ways they are where the UX rubber hits the road—if the team doesn’t have the right stories to start with, it’s going to be very painful to adjust after development starts. And if the team is new to Agile, no one on the team has any experience writing stories effectively. So let me hear stories about stories from you—the good and the bad.  What’s the state of your practice?

Many of us talk about being user-centered, and most of us want to be user-centered designers. But what does that really mean? And how do you take the understanding you gain from user research and do something meaningful with it for an innovative outcome? In this talk, I will cover some easy and quick ways to infuse existing UX processes with some theatrical technique that will help to drive empathy that leads to true understanding, and therefore innovation. Come learn a little about storytelling, ensembles and RRI (Representation, Repetition, and Iteration) – the real ROI of UCD – and what it all means to user-centered innovation.

Usability and User Experience 2011
UPA-Boston’s Tenth Annual Mini UPA Conference
Wednesday, May 25, 2011
Cambridge Hyatt
575 Memorial Drive
Cambridge, MA 02139

In his defense, he has a long history of actually going out into the field to gather customer data. He totally gets the value and understands how important it is from previous experience. His response to our discussion about the lack of that understanding in this case was twofold. First, he said he is too busy just managing the internal issues and getting everyone aligned and keeping the project moving forward. Second, he said his boss is not at all supportive of user research. His manager has the attitude—like so many in the world of technology—of “We know our customers… we talk to them all the time.”

While my friend knows the difference between talking to customers and really understanding their environments and the issues they face in day-to-day life, he is not able to convince his management team of that value. This attitude is what I call complacence inertia. I have seen it throughout my career. Product managers are under time pressure, new technologies come along and everyone wants to be first in the marketplace. It’s natural to assume you understand your market and your customers because you talk to them in various forums, but it lulls us into complacence. I choose the word “complacence” because it captures the situation perfectly. The dictionary defines complacence as “a feeling of security while often unaware of potential danger.”

The irony is that the same set of managers would be first to say they want to bring more innovation into their product offerings in order to beat the competition. Where they get mixed up is they assume that technology is what differentiates the product—and that the innovation is in the technology. My experience is that a company can take advantage of a new technology and maybe even be first to market, but what actually differentiates the product is what it does for the customer. Customers often don’t really care about the technology at all—what they care about is how it can be used to make their life better.  

I remember when Fibre Channel, a high speed interconnect protocol for computer storage systems, was new and exciting—to technology companies anyway. My organization was one of the first to put this new technology into systems and ship them to customers. My team and I spent time going into our customers’ environments gaining an understanding of what was happening in large data centers. I wanted to really understand how we could use this technology in useful ways beyond just making things faster.

What we ended up providing customers had little to do with the technology itself. While our solution certainly was enabled by the technology, it wasn’t Fibre Channel that our customers cared about. It was the ability to manage multiple systems as though they were one machine and easily allocate and manage system resources across those systems with high performance. Our solution was much larger than a single technology; it came about because we spent time understanding what was happening in our customers’ environments.

Of course gaining that customer knowledge is not always easy. My colleague recently wrote a blog for PDMA, “Why is listening to the voice of your customer harder than you think?”, which describes nicely the challenges we face in gaining that understanding. But it is possible to do. And it’s the best way to ensure a successful product that beats the competition.

So we come back to the competition point: Technology can enable wonderful things, but the best way to beat your competition is to understand your users’ lives. From that understanding you can generate solutions which are innovative but grounded in solving the problems users may not even be able to tell you they have. My customers would never have told me they needed multiple computer systems working together as one machine, easily configured and managed. They told me about database sizes, numbers of users, application issues, and system management problems.

Now, we were well down the road to shipping our first systems incorporating Fibre Channel before we completed our research and generated our solution ideas. People frequently tell me they don’t have time to do the field work and keep to their product schedule. My simple response is, “pay now or pay later.” If we had just shipped the systems we initially designed, our platform would not have been successful. We would have spent countless engineering months (years?) trying to figure out what was wrong, what should we fix, etc. to get sales up. But because we had our research in hand, we quickly laid out a roadmap to improve our initial shipping product and evolve it into the solution that was extremely successful in the marketplace. Even when you can’t get the resources and time to do field work before a product is well into development, you can still do the field work in parallel and bring that knowledge into play. Especially when the initial product launch may not be as successful as planned, you can lay the groundwork for developing a roadmap to success.

I’ve come to believe that the best way to fight complacency within organizations is to educate management teams about how field research and understanding your customers’ lives is the key to beating your competition. It is a competitive imperative, if you will. Ask yourself, “What’s the one thing my competitors don’t have that I have?” They have access to market data, probably access to new technologies coming along, and they also talk to customers. I would argue what most companies don’t have is a good understanding of actual customer behaviors and motivations at a level of detail that can be used for designing solutions. And this real-world, detailed level of understanding produces solutions that beat the competition every time.

Where will you get your competitive advantage? Convince your team that going into the field and understanding your customer’s motivations and behaviors will give you something that the competition won’t have access to. Why? Because they also suffer from complacency.

For those coming late to the party, there’s an ongoing debate in the Agile community about Phase 0. One Agile value is “no Big Design Up Front” or BDUF. That’s often translated in practice into: No planning, no user research, no concepting, no requirements specification. “Look at Flickr!” the purists say. “They thought they were doing online gaming! But photo sharing turned out to be the most desirable aspect and over successive iterations, the site evolved to what it is now.”

So an Agile project, in the most extreme view, starts with the most involved people sitting down in a Release Planning Meeting, brainstorming what they’d like, and putting features on story cards. Sort the cards, and start coding.

There are a few problems with this.

First, there’s the question of who’s in the room. In theory, the customer gets to define what goes on those cards. But who is the customer? There’s nearly always more than one. Who gets to represent them?  How do they know what to say? In most real projects, the customer ends up being the product manager or some other surrogate. And without a process for them to learn what’s really needed by the real customers, they’re guessing at what the needs are. And that’s not good.

In fact, of course, even real, honest-to-goodness end users have to guess at what their needs are. It’s been a frustration to well-meaning developers since forever that you can’t just ask users what they need and get a reliable answer. Users are buried in doing the work—they don’t think about it in the large. They don’t have enough distance from it to see where the real roadblocks are. They assume things have to be a certain way because they’ve always been that way. So even if the end-users were in the room, the cards they wrote wouldn’t be reliable.

That’s from the user side. There’s also a problem from the design side. If a product or system was just a collection of features, writing them on individual story cards might be fine. But, of course, a system is more than that. Every time someone writes a story card, they have a whole concept in their mind of how that feature is going to fit into a larger system and how it’s going to help users do something useful in the world. Where’s that larger design represented? How is it shared? In fact, the most important conversation in the Release Planning Meeting—the overall design and goal of the system—is not acknowledged or represented.

So given these problems, how do real teams get around them? So far as I can tell, by doing some level of up-front design. Not “design” as software engineers use the term—they talk about the design of the software architecture—but design of the user experience. Whether it’s done by writing a Product Requirements Document, doing some user research, doing “product concepting”, everyone is starting with a clear idea of what they want to build and they engaged in a set of activities to get there.

Lately, when I do talks I’ve started to challenge the audience—who can give me a counter-example? Who thinks they’ve really started with no Phase 0 at all? So far, no one’s taken me up on it.

So now I’m asking you. Write me back if you think you really kicked off your project with no Phase 0 at all. I want to hear how it went.

Anybody?

If not, here’s a quick primer. Every year since 1995, Gartner publishes a set of reports on the state of technology in a variety of industries. And as they’ve been doing since 1995, Gartner uses the Hype Cycle to describe individual technologies’ status and fortunes for mainstream success. The Hype Cycle says that a technology goes through a predictable series of stages on its way to mainstream adoption. In the first stage, Technology Trigger, a technology is introduced. The media or tech blogosphere picks up the stories on early proofs of concept and demonstrations. This sets the stage for a rising tide of excitement until the technology reaches the Peak of Inflated Expectations, where it seems widely expected to beat sliced bread, cure cancer and eliminate all human suffering, sometimes all at once. Some companies jump into the game, but soon there are widespread failures as the technology fails to meet lofty expectations. And so begins the Trough of Disillusionment, a point at which companies fail or merge, and the technology can only survive if it meets the needs of early adopters. If it does not die, the technology reaches the Slope of Enlightenment and the Plateau of Productivity, as it matures and realistic applications of the technology emerge, along with viable business models.

Why is the Hype Cycle so much fun for me? For one, it’s always interesting looking back at the technologies we all thought were going to rule the world. Remember JINI, holographic storage, or the 3-D web? I didn’t think so. In a sense, it’s also like the ultimate Vegas odds board for geeks. Gartner publishes Hype Cycles in almost 70 areas yearly, so it’s cool to pick what emerging technologies appearing in the Trigger stages you think will be the Next Big Thing and then follow them in the tech press. In the latest incarnation, 3-D Printing, Tangible User Interfaces, Autonomous Vehicles, Mobile Robots and Human Augmentation all appear in the Trigger stage. Which will be a bust? Which won’t we be able to live without? It’s a high stakes game with the whole world watching.

From a technology standpoint, it’s all good fun. But from a design standpoint, I often wonder just why a technology has to go through all of these stages. It seems awfully inefficient. Can’t technologies ever just move right to the Plateau of Productivity? It seems odd and a little frustrating that the Hype Cycle rings so true.

To me, it’s all about nouns and verbs.

When you think of a technology or a product as a noun, you concentrate on what it is, its object-ness. My late mentor Jim Wilson called noun-thinking our inherent physics fixation. You become dazzled by the sheer achievement of the demonstration, overly fascinated by the whiz-bang quality of the thing itself, without worrying too much about its real utility. I remember the first time I experienced immersive virtual reality, in a CAVE at the University of Illinois at Chicago. I stood in a ten foot cubic box, wearing glasses and amazed at how I was instantly transported far undersea, with schools of fish seeming to swim right through me. I was in physics fixation heaven—I was so overcome by the novelty and technology that I didn’t stop to think about what real problems were solved by people experiencing virtual schools of fish swimming through them.

But a verb is something different. A verb implies action—and useful action, hopefully. When you think of a technology or product as a verb, you think about what it can do for people. You think about the problem it solves, the usefulness of the thing in everyday life. You are verb-thinking. An application is no longer a thing—it is an act.

A product or technology can get through the Trigger phase and rocket up the Peak of Inflated Expectations just being a noun—perhaps it’s always been so and always will be. People are always attracted to novel technologies that seem like magic. But that excitement only takes it so far, and perhaps the Trough, too, is inevitable. In the classic Crossing the Chasm, Geoffrey Moore gives us another way to think about the Trough. Early technology enthusiasts are willing to invest time, money and incur risk in adopting new technologies in early stages of the Cycle. But the mainstream thinks differently, and the qualities that attract them—proven value and return on investment, ease of use and integration, low and predictable costs—are almost exactly the opposite of what attracts the early adopter. Moore asserts that products fall into the Chasm when companies cater to their early adopters and refuse to mold the technology into a comprehensive solution to a practical problem. I think this is exactly what is going on in the Trough of Disillusionment.

Getting out of the Trough requires providing practical value. It is a lot about a technology’s transformation from technology-as-object to technology-as-actor, the emphasis evolving from “what it is” to “what it does.”  Technology enthusiasts respond to the noun, but the mainstream responds to the verb.

As a technologist, this is what first drew me to design thinking, and to user-centered design in particular. From a product development point of view, user-centered techniques can help lift you out of the Trough by helping understand the practical problems the technology can solve, and identifying all of the pieces you need to provide a complete solution for your customers. Adopting a customer-centered new product introduction process including front-end user research, cross-functional teaming, and early experimentation and prototyping gives you a systematic way to do verb-thinking, always emphasizing the utility and value of your technologies, and avoiding the perils of the Trough. As Don Norman points out in his book, The Invisible Computer, institutionalizing user-centered design techniques like Contextual Design can help.

I was happy last month to see that Vitality, a Boston-area startup headed by David Rose, was purchased by Patrick Soon-Shion, a serial entrepreneur-turned-venture-capitalist. David spent more than 10 years shepherding ambient display technologies through the Hype Cycle, experimenting with and commercializing everything from ambient orbs to picture frame-like displays to alarm clocks at his first company, Ambient Devices. But the compelling value turned out to be in medicine—GlowCaps, an ambient reminder system for medications embedded in prescription container caps, is the reason for Vitality’s acquisition, and his exit from the Trough. Vitality’s website says that applying ambient displays to medicine is the result of David’s struggle with medication compliance himself, but I can’t help wondering if ambient display’s trip through the Hype Cycle might have been shorter had a physician or two stumbled upon the ambient orb a bit sooner.

While I’ve had a long and varied work experience, the most formative part of my career was when I worked in professional publishing, where I was part of a team put together to move my company from print delivery to electronic. Back then the Internet was almost unknown; we were transitioning from print to CD-ROM or non-Internet online systems. Our content was millions of pages of editorially enhanced, full-text legal and government documents, along with analysis, books, journals, and newsletters—with a never ending torrent of new material that had to be analyzed and published.

You might think the opportunity to digitally deliver a tremendous amount of ever-changing content would be embraced. Not so much. The company had been in business for decades and was very successful; our core competencies were gathering information, writing analysis, and print production. Our customers (and many of the employees) were accountants and tax attorneys—not people known for leaping at a chance to change. If you work for a technology company, I really can’t explain to you how difficult and painful this was as we moved ourselves and our colleagues—often kicking and screaming (not a metaphor)—into this new world.

“This is like déjà vu all over again"

— Lawrence Peter "Yogi" Berra, noted philosopher (and all-time great American baseball player)

It’s been over 10 years since I worked for that publishing company. You might think my experiences would be irrelevant in today’s world of ubiquitous internet access and seemingly endless streams of online information. But identical experiences are happening all the time, right now, for hundreds of publishers or content providers. At least once a week I read an article, have a conversation, or work with one of our clients whose story makes me feel like I’m reliving the past—either my past or the past of clients we’ve already worked with. I can say, “Here’s what I think is happening in your company, tell me if I’m right”—and I get it right—without them telling me anything more than where they work.

In a few weeks InContext will be sharing a more in-depth look at  key user findings based on the extensive user research we’ve done with our publishing clients. But in the interim, I thought I would offer a few observations.

A caveat: These observations are based on working with publishers that provide content used for professional work or in education, although I suspect they are quite similar for consumer publishing (Condé Nast, Time Inc, etc. give me a call. I’d love to test my hypotheses with your content.)

Think of yourself as a technology company, not a publisher—but don’t become technology centric

It’s a huge challenge for a print publishing company to transform into a technology company. Technology delivery is not a core competency. The people accustomed to driving product development are the editors, content creators, and subject matter experts. Those same people are not necessarily skilled at delivering in a digital medium. The shift needed by the personnel can be profound, and those who can’t make the shift have to be transitioned out. Moreover, new people are often brought in that are techies who think first, second, and third about what technology can do.

This creates a company dominated by people who are in love with technology, or at least have a serious crush on it. When I ask them to describe what their product does, they talk about objects and APIs, not about what work the customer is accomplishing when using the product. It’s time for an intervention—they’ve gone to the dark side. In other words, they’ve gone too far in the other direction and become technology centered.

For example, I recently spoke with someone whose initial forays into moving their printed content to handheld devices were not very successful. They needed to get something into the marketplace, so they found out how to put content on the platform and released the products. They now privately admit that the offerings are not being used by customers, and they are getting ready to redesign and re-launch.

But I’m worried for them (this is not an InContext client). His description of what they plan to do was 100% focused on which new platform features they are going to implement; they are not seriously thinking about the overall context of how their customer uses the content. I’m afraid they will fall short again.

Don’t read this as saying the platform does not matter; of course it does! But its features (and constraints) have to be considered in the context of the customers’ use.

Your product is not the content

The content you publish is not your product. Aggregation, curation, editorial value-add is not your product. Of course there is value to what the publisher provides, but it is becoming less valuable when the source materials are readily available, for free, on the web.

So what is the product? Supporting the full context of use of that content in your customers’ work practice is your product. And that means you need a deep understanding what happens before, during, and after the content is read. So you need to talk to your customers.

That brings me to my last point.

The old ways of talking to your customers don’t work for product design

(This means you too, technology companies!)

If you listen to what’s coming out of the publishing industry lately, you’ll hear increasing talk about needing to be “customer-focused” and listening to the “voice of the customer” in order to create the “user experience” or “support the user workflow.”

You’d think this would be music to my ears. But then the conversation quickly turns to focus groups, surveys, and one-on-one interviews. Sigh. Steve Jobs is right; if this is how you “ask” your customers none of these techniques are going to tell you a darn thing that will be helpful in designing your product.

The really successful companies making the transition from print to digital—companies like Wolters Kluwer and McGraw-Hill Higher Education—are using Contextual Inquiry interviewing to observe end users in the field. They’ve made Contextual Design the cornerstone of their customer intimacy programs and product development processes. Moreover, because they understand the context of use, they are developing solutions that deliver what customers really need.

Isn’t that every company’s goal, regardless of industry?

Watch for an announcement in a few weeks when InContext publishes our research insights from working in the publishing industry. In the meantime, leave me a comment. I’d love to get your perspective!

One in particular that I personally rave about is Coastal Contacts, an online retail store for contacts and eye glasses. I have been a customer of Coastal Contacts for about ten years now, almost since they came into being. From the beginning I have been impressed, though at first I was just looking for the cheapest avenue for my contacts, having decided that 1-800 Contacts was just not worth the cost. Coastal Contacts’ “customer first” philosophy helps them to consistently make updates that strategically and iteratively enhance and improve the experience; successfully paying off in revenue and growth.

For instance, I recently received an email reminding me that my contact lens supply was running low. This is apparently a new “feature” and everything about this was brilliant. For starters, it was the right timing for a reminder; I had, in fact, only the day before checked my supply and realized that I had just a month remaining. I’m horrible at remembering this myself and usually scramble to place a last minute order.

But it’s not just that I don’t have to keep track myself anymore which makes it brilliant, it’s also that this email is personal and says that Coastal Contacts has my interests in mind. They are telling me they are going to do the work for me, and that they know ME because they know my prescription and the recommended wearing schedule. More than ever I feel like we have a relationship, and amazingly, one that apparently continues to grow after all this time.

This email also had a link to the Coastal Contacts “Express Refill” functionality. The whole concept of “Express Refill” is great all on its own. It allows me to reorder exactly what was ordered last time without having to reenter any of the information, all that is required is to confirm the selection. I remember thinking, “this is exactly what I wanted them to do next” when this first rolled out. If I wasn’t hooked before, they had me permanently now.

“Express Refill” also shows that Coastal Contacts knows how to get the right base set of functionality and experience out the door and incrementally take steps towards expanded capabilities. When “Express Refill” first came out it maintained the prescription information, but not the doctor information. Coastal Contacts obviously understood the priorities of their users; that I would more easily remember my doctor’s name than my prescription. So I was happy. They gave me something valuable, even if it was not complete. When they rolled out the additional functionality to maintain the doctor information as well, it just was icing on the cake of an already great experience.

Coastal Contacts has also begun to take advantage of new web technologies and social media in their efforts surrounding eyeglass sales. Virtual tools to show how frames will look, user generated videos, and referrals play a major part in these efforts. Their Facebook Fan Page is also quite a successful venture and a way to keep customers engaged. In fact, they have even convinced me to “like” them because of their continuous “free glasses” campaigns, and I don’t do this lightly.

Coastal Contacts may not be a site I use on a daily or even weekly basis, but their dedication to stellar user experience and innovation makes them cool to me as a customer and keeps them in the forefront of my consciousness. This isn’t an easy status to achieve for a product or service like this, which could be considered niche.

Understand your market and users and commit to doing what you do–which face it, for most businesses isn’t what Apple does–well, innovatively, and with clear strategy and you could be cool too.

What would that mean for your business?

First, on Monday, May 9, Karen Holtzblatt and David Rondeau will present Looking Below the Surface: Understanding and Analyzing Interaction Design. Focusing on essential core concepts, this course provides a foundation to better understand interaction design and the importance of underlying structure. It helps participants see past surface details to understand the fundamental aspects of the interaction and how they affect user experience. The course introduces interaction design patterns as a method for analyzing and revealing structure.

Then on Tuesday, May 10, Karen Holtzblatt will present Designing for “Cool”: Making Compelling Products and Applications. In this talk, she reveals some of the results of our research into what makes a product cool. We have found that a set of core attributes generate the cool experience, and these attributes can be named, explained, and analyzed to help develop compelling products.

And on Wednesday, May 11, Hugh Beyer and Karen Holtzblatt present The Role of the UX Professional on an Agile Team, in which we discuss Agile development and how that affects the role of the User Experience designer on a project team. The tutorial arms UX designers with concepts and techniques enabling them to participate effectively in Agile projects. We show how principles driving Agile methods can be used to support UX involvement and we describe proven Agile/UX best practices for integrating the two perspectives.

But, looking at their base principles, Agile methods should be friendly to UX participation. Continuous user feedback is core to Agile—and who better to supply it than UX designers? But many Agile values and attitudes work against the needs of UX design. Agile methods were created by developers, for developers, without much consideration for user interaction.

In this tutorial, we arm UX designers with concepts and techniques enabling them to participate effectively in Agile projects. We show why Agile methods make sense from the developers’ point of view—and how principles driving Agile methods can be used to support UX involvement. We also show where Agile methods work against the UX goal of a coherent, consistent interface and provide strategies to accomplish a coherent design anyway. We describe proven Agile/UX best practices for integrating the two perspectives.

Finally, we step back and look at project scope. Agile methods address small-scale projects—how to scale them up is debated in the Agile community. We show how to plan a user-centered Agile project of any scale, from iterative fixes to whole systems.

Over the past several decades, Cool has evolved into a marketing imperative: an overarching requirement for many designs. Companies spend billions organizing and reorganizing to cultivate “innovation” so they can reliably create it. And a new generation, with vastly different expectations on Cool design, is coming of age as consumers and workers. But Cool is hard to pin down – there’s no accepted way to define it, measure it, or design for it. Like glamour, it is an ineffable yet powerful quality that depends on a host of subtle factors.

This course presents a set of core attributes that make products and applications Cool. These design attributes emerged from an extensive cross-generational contextual research project understanding how people from 15 to 60 experience “cool” and its relationship to value and impact on their lives.

We first present core Cool concepts based on the research, using real product and service examples to illustrate and illuminate the material.  We include the application of cool concepts to productivity business applications. Attendees participate in an exercise to evaluate the products they use, own and/or are designing to how Cool attributes apply and affect them. We end with an analysis of what it takes for an organization to develop and ship game-changing products revealing the real effort required to create cool products. We look at the problems organizations face in creating Cool, and discuss the challenges inherent in large organizations as they attempt to move toward a more innovative culture.

When creating or evaluating designs, people often get caught up in the surface (or UI) of the design, or they try to use the latest design trends without looking at the more important structure that underlies an interaction design. Focusing on the essential core concepts, this course provides a foundation to better understand interaction design and the importance of underlying structure. The basic materials and building blocks, key design principles, and structure of interaction design are illustrated by using familiar, real-world examples. The course also introduces interaction design patterns as a method for identifying structure. By learning how to use patterns to analyze structure and reveal new information, participants also learn how to evaluate designs in a more substantive and valuable way.

I once consulted for a startup back in the early dot-com boom days. They were developing a product that would ensure referring physicians only place medical orders that wouldn’t be denied by insurance. Insurance companies only reimburse when the ordered test or procedure codes map to qualified symptom codes. They won’t, for example, pay for a knee x-ray if the symptom is shoulder pain. The company founders envisioned a medical ordering system featuring a human body UI where all the user had to do was mouse over a part of the body to identify symptoms and it would present only qualified tests or procedures to order. The founders assumed they understood how orders are made and that referring physicians would be the primary users of their new product. A lot of engineering effort went into making this new design visually striking and easy to use. It was innovative, it was cool-looking…and, unfortunately, it missed the mark.

To explain why, I’ll start with what we found out about the work of creating medical orders.  I worked with an employee trained in Contextual Design to conduct contextual inquiry interviews at a number of healthcare offices and institutions. Though physicians prescribed orders, such as CT exams, we found that it was the office assistant (OA) who typically did the actual work of making it happen. Once a physician informed the OA of what to order, verbally or written, the OA would proceed to determine the proper sequence if there were multiple orders, figure out the patient’s availability, then contact the referred specialist services to obtain authorization and schedule an appointment. Most orders would be routine and predictable so it was easy for the OA to know the correct order codes to enter from memory or from a cheat sheet. Sometimes, for more complex tests or procedures, the OA would consult with the service’s scheduler who might recommend a change to the physician’s original order.  In these cases the OA would have to go track down the physician, who was probably off to his or her next exam, to approve the change.

Once we understood the medical ordering context, we tested paper mockups of the company’s product design with OAs, since we knew they would be the ones who really dealt with orders. And what was the very first thing they did?  They immediately wanted to get rid of the human body UI—the one the engineers had spent so much time perfecting. OAs liked their existing form-based UIs where they could quickly and unambiguously tab to fields and type in the necessary information. They did like the idea of a feature that could identify procedure codes insurance would pay for when a symptom code is entered, but they clearly rejected the idea of hunting around for symptoms and procedures off of a graphical model. Even more importantly, the engineers’ mockup didn’t include support for the largest part of the OA’s work: scheduling the order. To schedule an order, the OA would typically have to find and provide answers to screening questions from the referred service, verify insurance coverage, coordinate multiple calendars to find appointment times, and provide the patient with prep instructions. Scheduling could be time-consuming and full of problems such as needing information from the physician or patient when they are unavailable.

So all the startup needed to do was make changes to the design based on user feedback, right? Well, it wasn’t going to be that easy. First, they were so invested in the human body UI paradigm—in fact it was core to the original vision on which the company was founded—that the idea of giving it up was not considered even in the face of clear evidence to do so.  For example, the VP of Engineering had this to say after seeing, first hand, OAs rejecting the prototype outright:  “They don’t get it.” Secondly, they stuck with a product scope that only addressed entering the order in isolation, deciding against recasting their business to provide an overall scheduling solution or integrate cleanly with existing scheduling systems. So in the end, not only was their offering user-unfriendly for OAs, it failed to effectively support the core work of appointment scheduling. After launch, the company never really got off the ground and eventually folded due to very low sales from lack of customer interest.

Their confidence in the original business plan and product concept was so great that it had blinded them to customer realities. The train had already left the station before they really knew customer needs. They failed to distinguish the core value of their innovation—screening symptom codes for reimbursable procedures—from superficialities such as a “cool” UI.

Fortunately, blind spots can be avoided by obtaining customer work practice data and concept validation early on, prior to locking in business and product plans. I have the greatest hope for companies that are not only brimming with new product ideas but who also have the humility to recognize that they may not know everything about their customers. They show a willingness to seek out deeper customer understanding and adapt when it challenges existing assumptions.

Does your organization have any blind spots?

I frequently hear that argument. Of course, I don’t believe it for a second. I’ve had this discussion with my friends and colleagues, sharing with them my own personal experiences over the years. So it was refreshing to see a recent article published by a General Motors client team who shared their own experiences and results innovating with Contextual Design (CD). Though they’ve since done many CD projects, even their first experience going into the field and spending time with users generated many innovative ideas. In fact, as reported in the conference on Automotive User Interfaces and Interactive Vehicular Applications (2010) (Journey: GM’s move to incorporate CD) the team’s effort resulted in 33 patent submissions. Now, that sounds like significant and new ideas were generated by the team.  

This particular team deals with the most physical of products—cars. They have responsibility for the systems we all interact with inside a car: the navigation, radio, communication and instrument cluster gauges—what they call the Human Machine Interface (HMI). As part of the project, team members went out and rode around with drivers as they went about their daily life, commuting, running errands, taking trips. The result of their work and analysis was a set of key findings captured in work models from which they did visioning; Contextual Design’s structured ideation process. While I won’t go into the content of the whole paper, I will pull an example from it which demonstrates how observing users in the field can power real innovation or what we often call practical innovation. What that means is ideas that are applicable to real people’s lives and can be shipped in products now.

One of our findings was that navigation means more to users than just getting route instructions from point A to point B. The team learned that in-vehicle navigation systems provide situation awareness, security, entertainment, and educational opportunities to the driver and vehicle occupants. In addition, the task of navigation isn’t just confined to the car, as they observed a great deal of trip planning being done online using the participants’ personal computers. We learned that life flows in and out of the car but the problem is the car is a silo. This has far-reaching implications for design.

One deceptively simple behavior pattern which drove their design thinking was that while driving through familiar areas, drivers do not require navigation assistance. They often observed drivers turning off the route guidance prompts when traveling in familiar locations and skipping recommended turns by the system because the driver knew a better route.

Now, this behavior might seem obvious—but no one had thought about the implications for design before. Based on this information, the GM team developed requirements for a new navigation routing system that would learn where the vehicle has traveled and based on that information make more general routing instructions, as well as providing drivers information about how their route will be impacted if they choose to ignore a maneuver.

For example when starting from a Detroit suburb and traveling to Chicago, the system would prompt the user to get onto I-94 west while monitoring the driver’s progress toward this goal without providing unneeded and often annoying turn-by-turn instructions of how to get out of the driver’s own neighborhood. The frequency of prompts would increase when the vehicle recognized it was traveling in unfamiliar territory. This is very similar to the way in which people give instructions to drivers when they have knowledge about the driver’s familiarity with a particular location. This more intelligent routing method, though deceptively simple, was judged by GM to be important enough to patent.

Though not every team that goes into the field ends up filing for patents, every team does find going to the field a source of insight and innovation. Sometimes it’s from discovering new aspects of the user’s world, but other times it comes from rediscovering and making explicit aspects that have been overlooked. The result is new, transformative designs which deliver huge value to users and generate customer loyalty. Isn’t that what we’re all trying to do for our customers?

My Rental Car Experience

A recent experience renting a car drove me to think about this problem. While it may seem far removed from the design of software or web interfaces, the lessons learned still apply.

I travel regularly for work and the experience of reserving, picking up, and returning a rental car, to me, is still surprisingly easy and painless. At first, this trip was no exception. I arrived at the airport, boarded the shuttle, and the driver confirmed my “elite” membership. As we approached the lot, he told me the car’s location and dropped me off about 20 feet from the car. Talk about great service!

I always find the next part to be a little stressful—getting into a strange, new car. I sat in the driver’s seat and familiarized myself with the car. I found all the basic controls (side mirrors, headlights, and windshield wipers) and made sure I knew how they worked. Ready to go, I reached over to start the car (they always leave the key in the ignition). But there was no key. Even worse, there was no place to insert a key!—just a large white button.

As you may have guessed, this was my first time with a keyless ignition. Luckily, I enjoy figuring out how things work and I actually thought this would be fun (yes, in a design-geek sort of way). I looked around for the key fob, spotted it up on the dashboard, and put it in my coat pocket so I wouldn’t forget it. I turned my attention to the large white button labeled “START STOP” and pressed it once. The car turned on. Actually, the dashboard lit up but the engine didn’t start; the car was only in ACC mode. I pressed the button again, expecting it to behave like a traditional car (turn the key a little for ACC mode, then turn it more to start the engine). Instead of the engine starting as I expected, the dashboard lights went out and the car was now off. If a single-click didn’t work, perhaps it’s following a more modern computer paradigm and a double-click will work. So I tried quickly pressing the button twice. The dashboard lights came on—and went off again. I pressed it with short quick presses. I tried long slow presses. I varied the number of times I pressed the button. Once. Twice. Three times. Nothing. The engine would not start. I felt like I was attempting to crack a secret code.

At this point, I have to admit I was starting to panic. I needed to get to a client appointment and didn’t know what else to try. I wasn’t ready to ask for help either—after all, starting the car is a simple basic task. I’m a designer, how could I admit that I can’t even start the car? I examined the key fob more closely and on the key ring, I noticed a small plastic card with instructions. But half of the card was missing! I was able to pick out a few key words—”apply” and “pedal” and at last, I had a clue. I stepped on the break pedal while pressing the ignition button twice—and the engine started.

Unfortunately, this wasn’t my only problem with the car. I didn’t realize it had an automatic toll pass installed—until I was approaching the toll. I had to lean over and read instructions explaining I had to “slide open the transponder box” to use it. But I couldn’t tell if it was open or not—at least not while driving down the highway at 60 mph.

I also attempted to charge my phone when I noticed the battery was low. I searched all around the center console for a plug, but eventually had to give up. As I later discovered, it was deep inside the center armrest storage area—impossible to find while driving. By now, I was so frustrated that all the good feelings I’d had about the rental car service were completely erased.

The Problem

As I said before, most of the rental car experience is pretty well designed: Easy online reservations, very helpful shuttle drivers, simple car pick-up, and quick car drop-off. As you may have noticed, these are all aspects of the experience that the rental car company controls. It’s the part that’s not under their control—the experience inside the car that’s the weakest point of their service. The rental car service has a fundamental connection and reliance upon the automobile—which is an external product designed by others. It’s the kind of connection we tend to ignore, when in fact it could be a great design opportunity.

There’s also another part to the problem. Car manufacturers are constantly improving their cars and have no problem introducing new features even if they’re surprising or disruptive to users. This is managed by having salesmen teach people how to use the car at the time of purchase. People then drive their car, usually every day, and quickly learn how to use the controls—even when they’re new and strange. This doesn’t happen when you rent a car and that’s part of the problem. The car and the sales process are designed to support car owners, not car renters. Features that are seen as improvements for owners become disruptive for renters.

Seeing Design Opportunity

So, if the design of the external product is out of our control, how do we go about designing the connection to that product? In this section, I’ll review two basic strategies.

Make a smoother connection. From the user’s perspective, connecting to an external product can often be a confusing experience. It’s like being in a strange or completely unfamiliar situation. You don’t know what to expect or what to do because you don’t have the necessary knowledge. You need a guide to help provide knowledge at the point of action and smooth the connection.

Does that mean we should design something like Clippy the paper clip? Absolutely not. Instead of a wizard or a help feature, we should provide the information and controls users need at the point of action—where and when it’s needed.

The rental car company was obviously aware of the problem with the ignition button because they included a small instruction card on the key fob. The problem is that the key fob is not at the point of action. Since there is no actual key, the fob can be placed anywhere in the car; it doesn’t have to be near the ignition button to start the car. When people have a problem, they are looking at the ignition button, not the fob. A better solution would be to place the information on a simple label at the point of action—next to the ignition button.

Similarly, information to help people get familiar with the car (headlights, wipers, toll pass, power port, etc.) should be available when you first enter the car. The information could be printed on a simple card and placed on one of the seats or hung from the rear view mirror. The information could also be provided to the user in a simple email, as a link to an interactive website, or even as a mobile app that provides a quick 30 second visual tour. The goal is to make the important information available when and where the user needs it—at the point of action.

I’ve mentioned a few ideas based on my individual experience, but what I’m trying to do is highlight the design opportunity, not recommend a solution. That would require a deeper understanding of the work practice across the user population, which should be done by going into the field, observing people, and talking to them about what they do.

If you look at desktop, web, or mobile applications, you’ll see the same problems and opportunities exist. Facebook automated the connection from external sites to their own site by allowing external websites to place a “Like” button on their pages. This allowed people to share content on Facebook—at the point of action. Apple’s visual voicemail removed hassle by automating the connection to your cell phone voicemail system and raising information about the messages directly to the phone—at the point of action. I could cite many more examples, but let’s move on to the second strategy.

Automate the connection. Connecting to an external product often comes with a lot of hassle. It’s as if there’s a huge wall between the two products that prevents information or actions from being passed between them. This wall can be removed by automating some or all of the connection between the two products.

In the case of rental cars, this strategy isn’t really an option. Services that automate the driving of the car already exist: They’re called taxis, shuttles, and limos. So let’s use a web example instead: Mint.com, an application for tracking personal finances. If you’ve ever tried other personal finance software, you know how difficult it is to get all your financial data into the application. You have to go to the website for each account, sign in, export your data as a file, import the file into your finance software, clean up the entries, and then repeat for each account (checking, credit card, loan, etc.). It’s an awful lot of work to connect to all these external accounts. Mint.com saw the design opportunity and automated the connections. The first time you use the application, it prompts you to input the login information for each of your financial accounts. It saves the information and then automatically pulls in the information from each account and provides one place to see all your financial information. Automating the connections to external accounts and removing that hassle was a big part of Mint.com’s success.

Look for Design Opportunities

So the next time you have to deal with an external product that’s connected to your design—even if you think it’s out of your control—don’t dismiss it. Instead, view it as an opportunity. Keep in mind that some opportunities will offer substantial benefits, while others won’t even be worth pursuing. Every situation won’t lead to a design breakthrough, but that’s not the point. Great design opportunities exist in these connections, but if you don’t look—you won’t find them.

The sad news about product design is that it requires people to make and ship products. Products, systems, cars, medical devices, games, even apps—all require the work of many coordinating people. First, we have the development team; then add in marketing, product management, and testing; top with user-centered design roles: user interface, user research, user experience, visual design, and industrial design; and add planners, business analysts and all the managers and stakeholders. All these people have something to do with defining requirements and translating those requirements into design, specifications, and an implementation.

All these people need a shared understanding of both the user needs and the solution. Achieving a shared understanding isn’t “nice to have”—achieving a shared understanding is about shipping product that delivers value in a reasonable timeframe. Products don’t fail to ship because the technology doesn’t work or because the people can’t think up features. Products don’t ship because people can’t come to agreement.

The challenge of a shared understanding doesn’t go away with a small team or the “One Great Brain” theory of product development. Why? Because as soon as multiple people are expected to coordinate to deliver, they must operate from shared understanding to do their jobs effectively. No “One Great Brain” can ever do it all. Product development is always about people acting together and in parallel based on a common understanding of the problem and the solution. In the end, no matter what we wish or hope:

This organizational challenge—the need for a shared understanding—underlies many of the techniques used in Contextual Design.

Contextual Design solves the problems of people working together through the techniques of CD itself. CD fosters a shared understanding in many ways throughout the process. But it starts with these elements:

• Use a cross-functional team to do the work
• Interpret the data together
• Model the data to reveal the work practice
• Ground solution ideas in structured customer data

Tower of Babel “Now the whole earth had one language and few words. And as men migrated from the east, they found a plain in the land of Shinar and settled there. And they said to one another, ‘Come, let us make bricks, and burn them thoroughly.’ And they had brick for stone, and bitumen for mortar. Then they said, ‘Come, let us build ourselves a city, and a tower with its top in the heavens, and let us make a name for ourselves, lest we be scattered abroad upon the face of the whole earth.’ And the LORD came down to see the city and the tower, which the sons of men had built. And the LORD said, ‘Behold, they are one people, and they have all one language; and this is only the beginning of what they will do; and nothing that they propose to do will now be impossible for them. Come, let us go down, and there confuse their language, that they may not understand one another’s speech.’ So the LORD scattered them abroad from there over the face of all the earth, and they left off building the city.’ Therefore its name was called Babel, because there the LORD confused the language of all the earth; and from there the LORD scattered them abroad over the face of all the earth.” (Genesis 11:1-9)

Cross-functional teams capitalize on multiple perspectives

Every person involved in product development comes to the job with their own personal experiences. We each see the world from our own point of view, filtered by our unique history. So when we look at user data or user needs, it’s like we are carrying around our own personal flashlight that shines light on the things we think matter, leaving everything else in darkness. Marketing people naturally see trends, themes, and motivations. Developers naturally see the possibility of function (“fix this”) and data structures. Usability testers tend to see problems. UI-type professionals see the interaction and graphic design detail and how pages and function is laid out. Data modelers see data and business people see business problems. And so it goes.

We each have our personal focus based on our lives and our professions. It’s this focus that drives what we see in the world and what we think matters. Herein is the problem—we don’t actually live in the same world of experience. And yet our various points of view matter to the ultimate success of the product.

Deming, the quality guru, held that to deal with this problem we need to walk in one another’s shoes. He recommended that people rotate through jobs in a company. But this is time consuming. More importantly, different people have different skills and interests—they aren’t necessarily interested in trying out all the jobs just to be able to see through others’ eyes. Beneath Deming’s idea is that if people can have the same experiences they are more likely to have respect for others’ points of view.

Inspired by Deming, Contextual Design starts with a cross-functional team. Not to oversee the project; not to review direction; but to actually do the work together for a limited period of time. One interesting lesson we learned is that shared understandings don’t come from typical corporate meetings—and they don’t come from doing HR team-building activities together. Shared understanding comes from doing real work together in situations where individual expertise informs the work but doesn’t guide it; where each person comes to the activity as an equal.

We start this process by immersing the team in the user’s world. There is nothing more powerful than going to the field—and there is nothing more leveling than going to the field. In the field, people get a visceral experience of their users’ lives. This immersion always opens eyes and reveals things no one ever thought of. And because each member of a cross-functional team comes at this experience from their personal focus, each team member will see different things. This is good—because the team as a whole sees more than any one person could.

But it is unwieldy to have all members of the team troop around in the field together so they all see at the same time. Sending everyone out to the field together wastes time and money. But worse, it’s hard for the user to behave naturally with five people watching!

Instead we created the interpretation session.

Interpretation Sessions naturally bring perspectives together

The Interpretation Session is a structured meeting that helps create a shared understanding across a team and overcomes the boundaries of individual points of view. Team interpretation sessions bring the design team together to hear the whole story behind each interview and capture the insights and learning relevant to their design problem. Through these structured discussions, the team captures issues, draws work models, and develops a shared view of the needs of the one customer whose data is being interpreted.

During this process something magical happens:

“Capture that,” a marketing person says. “That’s important!” “What’s important?” thinks the developer. “Oh, they are looking at brand!” “Capture that,” the developer says. “What?” the marketing person thinks. “Oh, I see, they are seeing how data is used from multiple applications!” “Can you believe that horrible interface—there are so many layers,” the UI guy says, watching the user struggle to get to the desired place. “Oh!” the other team members say. “Yes, I see!”

When a team is focused on the same data they can hear each other react to the data from different points of view. In this context the different perspectives become tangible and real because they are situated in the real life data of the user.

In CD an interview is interpreted within 48 hours. This ensures the quality of the data recorded, requires no preparation for each session, and ensures the team doesn’t get overwhelmed by reams of data to interpret at once. But quick interpretation turn-around also requires the team to alternate continuously between collecting data and interpreting it. As a result each interviewer’s point of view continuously expands through participation in the interpretation sessions. When they return to the field to collect more data they bring this new larger perspective to the data collection itself. As each team member learns how to see from multiple points of view, the data gets richer. The team creates a shared understanding of the data and the meaning of the data without trying.

The interpretation session with a cross-functional team naturally shapes a larger common perspective and builds buy-in to the data findings. Even if every developer or product manager can’t be on the team (we like to keep it to 4-6), if each constituency has someone they respect on the team, they are more likely to buy-in too. Plus we encourage visitors, one or two at a time, to interpretation sessions spreading the experience more broadly. In a people-centered business—and all design processes are people-centered—this saves time.

Work Models make the intangible tangible—and sharable

If I ask you for a cup you can pick it up and hand it to me. But if I ask you for your understanding of the users’ practice—what can you point to? A list of needs is not the practice; a feature list of design ideas to support those unarticulated needs is certainly not the practice. How does a team get a shared understanding of what the user is really doing so they can redesign it with technology—even if that redesign obviates the need for the activity altogether? Hidden in the real-life practice are human needs, pointers to potential delighters, the basic intents and organizational challenges that people face day-to-day. A shared understanding of the practice focuses design innovation discussions—and implicitly cautions the designer against breaking what works while improving the practice.

Any practice is more than a set of issues. Any practice has structure—it hangs together to achieve an intent. A list of issues is a good start. But a user’s roles and responsibilities; their collaboration within their workgroup; the process they work within; the values they share or conflict over; the physical environment they organize—none of this is revealed by issues and discrete task descriptions. Any practice bigger than a single function is complex and must be understood from several points of view.

To solve this problem—and to create a tangible artifact to represent the team’s shared understanding of the existing practice—in Contextual Design we capture work models.

The sequence model is equivalent to a task analysis. It shows each step required to perform a task in sequential order. A sequence model represents the activities of someone who will use the system. The sequence model also shows the breakdowns in the practice (as do all the models). The consolidated sequence models become the basis for redesigning the steps of the activities.
The flow model depicts people’s responsibilities and the communication and coordination required to support the work. The flow model reveals the actual human process used by a workgroup or individuals within an organization irrespective of time or order. When consolidated, the flow model is the key model for finding the core workgroups to support and for redesigning processes—both formal and informal.
The cultural model reveals the influences on a person, a group, or an organization, whether external to the company (such as law and regulations) or internal company policies (standards). It reveals the cultural milieu in which the product will have to succeed. When consolidated the cultural model is the key model for identifying the value proposition for the system and revealing influences on buying behavior.
The physical model shows the physical layout of the work or home environment and the constraints it imposes on the design. The physical model captures the footsteps between places, the role of distance, and the use of space. It shows the way people physically structure their work environment and work space. The physical model captures the structure and flow of work as it is manifest in space. When consolidated, the physical model can reveal both how to redesign work within the space and also how to support work online that was previously manual.
The artifact model shows how artifacts are structured and used during the performance of tasks. The artifact model is key when a team is trying to take a paper artifact, like a medical record, and put it online. Analysis of existing artifacts identifies their intent, usage, structure, and information. Artifact models merge with physical models for designs for automobiles or technologies in the home.

Work models are diagrams that represent the structure of human activities. Individual work models are captured by team members during each interpretation session: relevant data is recorded in each diagram as it is revealed during the retelling of the interview story. Contextual Design uses five work models in addition to capturing key issues. Each model represents a different aspect of practice. Taken together they reveal both the data and how the user activities hang together to get the work of life accomplished.

Diagrams are a normal part of a developer’s world. Whether it is a data model, an object model, a process diagram, or any of a thousand other modeling techniques, developers have been using drawings to show different aspects of a system since programming became a separate discipline. Making the abstract tangible is a natural part of everyday team design. If you watch teams at work you will see, as Lucy Suchman did in her classic work, that team work is supported by artifacts—people hang over them and focus their talk by looking at them and updating them and pointing at them. (Suchman, L., Plans and Situated Actions, Cambridge University Press, Cambridge, 1989.) Collaboration is always focused by and on the artifacts that represent what the team is trying to do.

So since we wanted to make the aspects of user work real, we needed something real to represent it. Data models represent data—they don’t represent human behavior and experience. Other modeling formalisms represented other aspects of system development. None revealed user practice explicitly. Since we wanted to foster a shared understanding and a shared conversation about the behavior of people we needed an artifact to represent user practice directly. That is what work models are: a way to capture the data that reveals the structure of practice, and something tangible that can be used to focus a design conversation.

The work models along with personas and the affinity diagram, a hierarchical chart that shows the core issues across a market or population, focus the team on a shared set of artifacts representing the team’s tangible representation of what the people they are designing for do. And because the data is tangible—the data is also reusable—the team can come back to it again and again during the design process.

More than 20 years after we first developed them, we still use these five “faces of work” to characterize the practice. We pick the models relevant to a project; no one has time any more to do them all. Each model brings its own point of view into focus and challenges the team to think from that point of view. Each work model, just by using a diagram to communicate, helps the team become aware of the structure of that part of the practice. Work models help the team’s conversation get real because the user data is made real in the diagrams. And this saves time.

Immersion in structured user data focuses the solution

To have a shared understanding of the user needs and the direction for a design solution, the team needs to move beyond the experience of any single user. An interpretation session makes the life of one user real and captures that user’s data. But to foster a team conversation about a market or user population we need to make the market real and tangible too.

Consolidation of the work models and issues brings data from individual customer interviews together so the team can see common pattern and structure without losing individual variation. Consolidated work models bring together each different type of work model separately, revealing common strategies and intents while retaining and organizing individual differences. Consolidated work models help the team step out of the details of an individual case to see the larger pattern of user activities as revealed across cases and people.

Consolidation results in one diagram for each type of model. Taken together, the consolidated models represent the practice of the whole market that is studied. Because consolidated models organize work practice into coherent and meaningful chunks, the team is able to see, capture, and think about very complex and rich information.

Imagine a room. On one wall is the affinity diagram, with all the users’ issues laid out in an organized way. On another wall is a flow model showing all the roles and relationships, and collaboration relevant to your project. On another wall are a set of key tasks in the consolidated sequence model. On another wall the cultural, physical, and artifact tell their story. And finally personas are hanging flip-chart sized on the last wall. This is your world of the customer—this is your data—externalized and available for the team to walk and discuss, ready to stimulate design ideas and design conversation. And yes—it is also available on-line to use and reuse throughout your project.

The most important resources on a team are the team members. Their perspectives will focus your design solutions. Their conversations will focus the definition of the problem and the direction of the solution. By providing the team structured data to immerse themselves in and a team process to interact with it they will naturally come to a shared solution.

One favorite story comes from a large multi-national company. Five different groups in the company needed to work together to produce a new product line. The design team who used contextual design took their affinity and consolidated work models from group to group gathering stakeholders in each to walk the data and generate solution ideas. As you might guess, the insights from the data and the solutions generated did not differ much from department to department. After all, it was the same company and all departments were in the same general business—and the data was the data. The groups were able to align their direction and get a winning solution out the door, just through structured data immersion and discussion.

Structured customer data allows for immersion and discussion time and time again—whenever needed. And immersion in structured data gives teams the reflection and discussion time they need when forming ideas for solutions. Structured data focuses these discussions on the customer because the customer data is right there in their face, on the wall and on-line. And we find that teams do indeed return to it over and over.

Immersion in the world of the customer during field interviews makes the customer real to the designers who will create solutions for them. Interpreting as a team shares this story and allows for first reflection and insight. But immersion in the whole of the users’ universe—as represented by the consolidated data—forces that big picture view that can drive a more complete solution.

If a team starts from the same data they are more likely to generate a shared understanding of the challenges and solutions—and that saves time and arguments.

All of business is the business of people working together

Any product development process or methodology must deal with the reality of people working together. If the people who have to work together don’t have a shared understanding of the problem, they will not generate a coherent solution. Without a shared understanding it is hard for a team to ship on time:

How many times have you found yourself arguing about requirements two weeks before you are supposed to ship? How many times have you pushed out your ship date because you are still arguing about what is necessary to build? How much time have you spent in meetings trying to come up with the real problems and solutions? How many methodologies have you tried on the way to getting your organization to get to a shared understanding? How many products have you shipped that the users didn’t like because you didn’t have an accurate understanding of their problems? How much frustration are you living with?

Hidden within Contextual Design are many kinds of structured design meetings meant to help teams work together effectively. But creating a shared understanding starts with a cross-functional team going out into the field to gather and interpret the data as a team. With consolidated work models and a process for team immersion in the data a team will develop a shared solution.

Sprinkle in additional stakeholders as ride-alongs on the field visits. Let others, who will be involved in creating the solution, participate occasionally in interpretation session. Invite extras who will have an opinion to help build the affinity. Bring them all to data immersion events.

Tangible customer data is the most powerful way to align your team. If you are honest about the time you really spend reaching agreement—you’ll find that Contextual Design can reduce team contentiousness, produce a better result, and speed your time to market.

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.

Interaction Designers (Boston and Chicago)

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 drive design solutions.

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 just web pages
• 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
• Can 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 and handle multiple tasks.
• Collaborative: Must be able to work in a highly collaborative team environment which includes 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.

User Researchers/Work Practice Designers (Boston and Chicago)

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
• Can 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 which includes 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, cover letter and salary requirements to careers@incontextdesign.com.

InContext is an Equal Opportunity Employer.

A hands-on exercise where everyone in the room participates in a (very abbreviated!) product visioning exercise.  We’ll pretend we are charged with defining a new solution to help grocery stores improve the shopping experience for their customers.  We’ll use real shopping data and the group’s knowledge of technology to create a systemic vision of a new world of shopping.

Presenter: Dave Flotree

At ProductCamp Vancouver

An effective way to understand end-customer needs is to go into the field to learn how they work and live, what they are trying to accomplish, as it relates to your product focus. We’ll cover the interviewing principles to use and then present a “top 10″ list of common interviewing mistakes and ways to overcome them.

Presenter: Dave Flotree

At ProductCamp Vancouver

Hugh has more than 20 years of experience building and designing applications, systems, and tools. Before co-founding InContext, Hugh acted as lead developer and architect in a range of systems at Digital Equipment Corp. His domains of experience include object-oriented repositories, databases, and integrated software development environments. Since starting InContext, Hugh has overseen the design of applications from desktop to web to mobile, and from enterprise to small business to consumers in the wide variety of industries supported by InContext.

He holds a B.S. degree in Applied Mathematics from Harvard.

Recognized as a leader in the design community, Karen has pioneered transformative ideas and design approaches throughout her career. Karen is the inventor of Contextual Inquiry—the industry standard for gathering field data to understand how technology impacts the way people work. Contextual Design provides a revolutionary approach for designing new and existing products based on a deep understanding of the context of use. Most recently, Karen initiated The Cool Project  to explore users’ experience of cool products and the rapidly changing role of technology in people’s lives.

Karen co-founded InContext Enterprises in 1992 to use Contextual Design techniques to work with product teams to deliver market data and design solutions to clients across multiple industries. The books, Contextual Design: Defining Customer Centered Systems, and Rapid Contextual Design, are used by companies and universities all over the world. Karen’s new initiative on What Makes Things Cool?  was introduced in Interactions magazine in 2010.

Karen is a member of the CHI Academy (awarded to significant contributors in the Computer Human Interaction Association) and in 2010 received CHI’s first Life Time Award for Practice for her impact on the field. Karen holds a doctorate in applied psychology from the University of Toronto.

“Ask yourself: Will any small children die if you don’t implement this feature now?”

Usually people laugh—and start to see the “must have” feature is not really so critical.

Of course, if teams are developing nuclear power plant controls, medical devices, airplanes, cars, tanks… that’s a whole different world and the design team knows it.

Today we have new gadgets and apps that start out “helping” us in life and quickly become an integral part of life. At what point do these tools require a different sense of design responsibility? At what point can these applications lead to serious damage?

I was recently in Brazil to give a workshop. I met wonderful people trying to bring customer-centered design to their own countries and companies. This opportunity to spread the word worldwide is one of my favorite activities. As usual I attached a small vacation for myself and my husband to the trip.

We have driven and hiked all over the US, Canada, Europe, Africa, Israel, Central America, Australia, and Mexico. So we are experienced travelers in less-developed countries. But this time—for the first time—we relied on technology. And this time—for the first time in 40 years—we drove into a nightmare.

My husband is the trip planner. In the past we had maps, books, phrase guides, recommendations, advice from the hotel, guides when appropriate, and our trips were a little wild but successful—even though we never knew the language. On one trip to Mexico we went from Mayan ruin to Mayan ruin riding the rough dirt roads in our 4-wheel drive vehicle. Our funniest memory was driving through a tiny town tooling along what we thought was the main road and encountered a bunch of kids yelling at us and waving their arms. When we dead-ended into someone’s backyard and chicken coop we figured out we had gone the wrong way. We backed out wondering what went wrong. Now we saw that the kids were pointing to a homemade arrow indicating the real main road. So off we went, waving back.

Brazil to us was just another adventure. Our first worry came when our Brazilian hosts were nervous about our trip plans:  “What?,” they asked. “You are driving alone down our coasts?” “You are going to Rio? Rio is dangerous!” More dangerous than Mexico and Costa Rica?  Than walking in Morocco? we asked. “Well maybe not,” they said.

We asked others at the conference and got a mixed report. So we were careful; we had already downloaded the Nuvi Brazil maps so we were set. We Googled the route in the US, and again in Brazil. We asked the hotel in Sao Paolo where we started and they Googled the path to guide us. So we had multiple confirmations of our route to Rio.  We had our careful plans as usual. We had no maps but we had map confirmation.

We got in our Chevy sedan and started off to Rio.  Getting out of the city was stressful. Did the navigator really know where it was taking us?  “This looks like a farmer’s market!” “Are we in the right place?” “Isn’t there a highway?”  We were stressed, but we had been navigating together for years and stress like this is normal. In the past it looked like, “Do YOU know what you are doing? Where are we on the map? Are YOU sure this is the right road?” Stress comes with exploration of new places. But a side benefit of a navigator seems to be to give us something else to blame.

Once we were out of the city and into the mountains the land was beautiful.  I was tooling along the winding road thinking, okay, now we are on our way. We stopped for gas. The attendant seemed to be asking (in Portuguese) if we were going to Parity. We nodded and said, “Parity.” That is what passes for communication when you don’t know the language. But as we were pulling away he seemed to be shouting to us.

In some part of our brain we wondered, was he trying to tell us something—like the kids in Mexico? But we couldn’t talk to him so we kept driving. And, well, we had our navigator. It said to go this way—we were safe.

3.5 hours into the trip and 18 miles from the goal we navigated to a dirt road. We did not have a 4-wheel drive car. No books said you must drive a 4-wheel drive car in Brazil like they do in Mexico and Costa Rica. So I backed out. “This can’t be the way,” I said.

We checked our Google map print out. “Yes it is,” my husband said. We checked that we had set the navigator to “NO UNPAVED ROADS.”  Yes. We drove back the way we came hoping the Nuvi would reset itself Instead it took us to a “safe” place on the windy mountain road to do a legal U-turn, only to return us to the dirt road.

“That dirt road is the only way,” my husband said. The maps say so, he meant. The navigator maps we all rely on say so. The most updated maps in the world say so.

I went into the road. After a mile I stopped. The road was rutted and felt like a wash. There were rocks. “This can’t be the way,” I said, and I backed out again. “What do we do now? We are 18 miles from the goal. It is 5 pm.”

We checked the navigator again. We were like a ball in a pinball game trying to find a way out. We went back up the mountain again hoping the navigator would find a new way—it didn’t.

“We’ve driven dirt roads before,” my husband said. So we tried it again.

Five miles driving down the dirt road I felt like we were falling down the mountain. I was swerving around rocks and ridges going up on the side of the road to let a truck pass. I’m driving on a river bed, I thought. I stopped. “We are driving down a wash.  There are no houses on either side. We are alone in the middle of a rain forest and it is getting dark!”

It is 7 pm. The voices of our hosts and others were echoing in our heads about danger and attack. We could get stuck! What if the car broke down? What if we bottomed out? We were alone—in the forest—with no cell pickup—in another country—where we didn’t speak the language—with no food—nowhere near a gas station—and it was almost dark.

“Can you even get us out?” my husband says. Thank God for our Chevy—it took us the whole way out and then kept going.

We drove back over the mountain to the highway, set the navigator on Sao Paolo, and made it to the Airport Marriott after 10.5 hours. We never did get to Parity, to see the coast, or to Rio. In 40 years of travelling we have NEVER failed to get to our destination. And in 40 years of travel we had NEVER been led to such a state of terror.

At the Marriott we met some businessmen. “What were you thinking?” one said. “You went with no driver?  Rio—let me tell you how scary Rio is—let me tell you the story of the businessmen who were held up!” We were lucky, people thought, to come out of the experience unscathed.

But Nicaragua wasn’t so lucky. Google maps led them into an international incident. Apparently Google misrepresented the border between Nicaragua and Costa Rica and was off 3000 meters. A Nicaraguan military commander, relying on Google Maps, moved troops into an area near the border and took down the Costa Rican flag, raising the Nicaraguan flag instead. This caused tension between the two countries. The commander justified his action by referencing Google Maps. A Google spokesperson said that the company doesn’t know the source of the map’s error.

After the trip I wrote to Nuvi wanting to tell our story and get our money back for the Brazilian maps. This is what they said:

Dear Karen Holtzblatt,

Thank you for contacting Garmin International. I am sorry to hear you are having troubles with the City Navigator Brazil NT mapping.

Unfortunately since the maps were already downloaded to your device there is no way to return those for a refund. Can you please reply back with the addresses you were going to and from and we can try to figure what went wrong with the routing.

Please let us know if you have any further questions.

With Best Regards,

What is the responsibility of a company to their users? Do we call this user error? Do we say it is just stupidity? Do we issue warning to always take a real map? Do we put disclaimers on the software packages—like cigarette packages?

What is the design responsibility of a company? What is their responsibility to find out how their products are really being used? What is their responsibility to ensure that “no small children die”—or are led into fearsome and dangerous situations?

Do we need to wait for legislation and investigation like the auto industry? Do we need to wait for death?

Garmin—It’s not about the $50. It’s about design responsibility. People and governments are relying on you for more than you imagined: foreigners travelling to new lands; people traversing “bad parts of town”; cars stuck in dirt roads; governments planning initiatives. Will you just wash your hands of it and say—I’m just a map provider with a voice?  Or are you ready to stand up and take on the responsibility of design?

I swore because Apple did it again. The keyboard was one of their designs, just a simple keyboard, not even a sexy product. But somehow it pulled me away from the group, pulled my hand out of my pocket, and got me to stroke it—all without my even being aware of what I was doing.

This isn’t about some kind of silly Apple vs. PC war, either. I wasn’t thinking about Apple. I wasn’t thinking about the keyboard at all. I was talking to my friends. This was pure seduction: something about the design of that keyboard bypassed any sort of higher reasoning and hooked me at the level of sensation.

This isn’t about usability or usefulness or fit to purpose, either. I’ve never typed on that keyboard—I’ve no idea whether it actually works. But for the things we bring into our lives there’s a level of design that is independent of use. This level of design is about image, style, mood—and we do make choices based on these qualities. I do, anyway. And the more technology becomes part of everyday life, the more this level of design matters.

It’s not all that matters, of course. Any of us can tell stories about designs that were so extreme they made the device unusable. If that keyboard doesn’t work well as a keyboard, I’d start hating it within five minutes of use. But any decent company can make a good keyboard these days. The design of the look becomes a differentiator once the core utility is taken care of.

The other reason I swore when I found myself seduced by a keyboard is because nobody but Apple seems to care about this kind of design in their computers these days. Other companies succeed in producing minimalist designs—simple, no clutter, what’s there is just what’s needed. But there is a gulf between simple and graceful, between uncluttered and elegant.

It’s a hard gulf to cross. I can teach you how to be useful, how to enhance the life or work of real people. We have a process for that. I can even teach you to be transformative—to make the leap from the way things are done now to the way they ought to be done. (Really. We have a process for that, too.) But making your product seductive is something else again. There’s a level of artistry to there.

This is similar to what goes on in the car industry, which has been seducing consumers for a very long time. For one of our projects, we studied how Porsche works with their designers. We discovered that Porsche often doesn’t do their own design—they work with Italian design companies to design the look of their cars. The Germans supply the engineering and the Italians supply the art, and I apologize for the national stereotyping such a statement suggests.

But notice I’m talking about the final look and polish, not the fundamental operation of the product. If that keyboard is difficult to operate, I’ll fall out of love with it in no time flat—and I’ll never feel the same about the brand, either. So you’d better get the basics right—by working with your users—and then in your visual design you’d better be enhancing and reinforcing your users’ values and self-image. Otherwise, the product won’t seduce.

What this implies is that if you want to achieve a certain look, to go to the experts. Don’t expect engineers to do beautiful designs. It takes time and training to develop any skill, whether that’s coding, user interaction design, or visual design. And to develop a design that’s not only attractive but seductive… well, watch this space. We may have more to say about that.

Somebody said that to me the other day, and I’m sure you’ve heard the same if you’re involved in Agile development at all. I had the usual half-defensive, half-annoyed reaction one has when on the receiving end of such a remark. But then I started to mull over the question.

Is Agile just a fad?

At some level, the answer is clearly “yes.” Agile is the current fad in the development world. Everybody’s talking about it; many teams actually are doing it; most of those who aren’t doing it claim to be. (That’s a useful definition of a fad right there: when people who aren’t doing it and don’t want to claim to do it anyway.)

But what does it mean to be a fad? If it is a fad, does that mean we should just dismiss the whole endeavor? Maybe looking at past fads in our industry would be instructive.

The first fad I became aware of in my professional career was Structured Design. Edsger Dijkstra’s letter Go To Statement Considered Harmful kicked off a whole new way of looking at programming. Yourdon and Constantine’s Structured Design codified it for an entire generation of programmers. People wrote, thought, trained, and wrote software packages around this new paradigm.

Now, 30 years later, who remembers Structured Design? Wasn’t that just a fad, popular in its day but irrelevant now?

Well, no, actually. The principles of cohesion and coupling matter just as much now that we’re programming in methods and objects as they did when Yourdon and Constantine first discussed them. Developers are still expected to code in well-structured blocks—without using GOTO statements. Yes, some of the modeling techniques and some specific practices have been abandoned—but the core insight of Structured Design is still alive and well. It’s just so built in to our modern practices that no one notices it anymore.

Object-oriented development is another case in point. Once, it was the fad of the day, spawning OOPSLA and other conferences, training, and many programming languages. Now it’s old news—but almost everybody can expect to be programming with objects, whatever the language, because they’ve all been extended to be object-oriented. The core concept is built into our standard practices.

So yes, Agile development is a fad. Ten years from now, I’m sure it will have been superseded by the Next Big Thing. But I’m equally sure that the core insights of Agile development will have been built into the standard practice of the day. Those core insights will at least include short iterations, each delivering a complete package; frequent validation of progress with customers and end-users; and daily attention to process and to team interactions.

Fads come and go, like waves on a beach. But each wave leaves pearls on the beach, the valuable insights that made the fad exciting in the first place, while sweeping away the flotsam of irrelevant or unhelpful practices left behind by previous waves.

This is probably the only way we can do industry change—by generating so much enthusiasm, excitement, and energy around the new approach that it can overcome the inertia maintaining the status quo. The excitement makes change possible.

And besides, it’s fun.

1. Edsger Dijkstra (March 1968). “Go To Statement Considered Harmful”. Communications of the ACM 11 (3): 147–148. doi:10.1145/362929.362947
2. W. Stevens, G. Myers, L. Constantine, “Structured Design”, IBM Systems Journal, 13 (2), 115-139, 1974.
3. Edward Yourdon and Larry L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and System Design. Prentice-Hall, 1979.

By June, the Kin was dead.

While the causes of the Kin’s demise are complex and hotly debated, I want to zero in on the user research and design aspects here.  Microsoft is often vilified for perceived usability shortcomings, but not many other companies spend as much time and energy on user research as the Redmond crew.  According to Microsoft, developing the Kin concept included “everything from usage statistics, to target-customer profiles, to a Web-based ‘consumer collaboration’ group called Project Muse that involved some 2,000 volunteers.” So what went wrong? Surely this much user research could not have missed the mark?

I don’t believe that this signals some kind of end to user centered design, as some have claimed. But I do think that Microsoft’s design team, however well-intentioned and well-funded – may have fallen victim to two seductive but faulty user research practices: relying on statistics for generative concepts, and building exactly what their target users told them to build.

There are places for statistics in design to be sure—Google does a great job with it—but one huge weakness of statistical methods is that statistical data is not generative, that is, it does not encourage the generation of new concepts.  Rather, they lead the designer too often into incremental solutions to existing problems.

Let me illustrate by way of analogy.  My wife and I are in the midst of having our kitchen remodeled.  It’s a hellish experience (a topic for another post!) but let’s assume that my architect could instrument my home the way that Google can instrument their search page.  Maybe the architect would want to monitor every step my family took, and measure and time every button press on every appliance we have in our kitchen, or video what we do 24/7.  And so let’s imagine what my architect would see through this analysis.  She’d see we spend a lot of time around the oven, and the fridge, and the peninsula where we do prep, and the kitchen table.  She’d see a big jump in usage around mealtimes, and late at night when my son swears he’s not eating my last Twinkie.  She’d see we use the microwave way too much.  But it’s what she would not see that is more important for our design than what she would see.  Because even with video, she would not see me going to use the neighbor’s oven when we entertain, or taking a turkey or a roast into the basement to carve because we’re using the peninsula to serve.  And she wouldn’t see that whenever we have more than a few guests, they have to go somewhere else rather than where we’d like them – right with us in the kitchen—because the space where the table sits is too small.  So lots of big “requirements” for my kitchen—a double oven, a big table, more working surface, socializing space—are not revealed by the instrumented kitchen.

The big problem with the instrumented kitchen is that it doesn’t answer the question of “why.” Because the real user motivations are hidden in the statistics, the designer doesn’t know the reasons behind the behaviors.  It’s not that the statistics are useless, it’s that they’re incomplete. 

So Microsoft used reams and reams of data about what applications, services and even keypresses were used on smartphones to redesign a youthful, social networking experience.  To their credit, they didn’t stop there.  They also used Muse.

Project Muse was an attempt at tapping the wisdom of a large group of Microsoft’s target teen and twenty-something market through an online community.  A sort of design crowdsourcing, if you will.  Invited participants were engaged through forums, polls, live chats and other mechanisms through the Muse community site.  And so Microsoft designers ostensibly could get a deep understanding of young social networkers, uncover hidden needs and desires, and design an experience just for them.

Not having been privy to the designers’ thoughts in Redmond, it’s hard for me to criticize too harshly. But this approach sounds very similar to the one some of our clients take, and ultimately reject.  The appeal is seductive: if I can gather data from seven people, wouldn’t 70 be better?  And what about 700?  With online web collaboration, it’s easy to “listen” to lots of people.  Must be better data for design, right? 

The problems are twofold.  First, analyzing so much input is daunting. What to make of poll results, forums, blog posts, chats?  Bob wants X, Mary thinks Y would be cool, Colin disagrees with both.  It becomes a cacophony of voices that is hard to structure and hard to digest.  It’s like focus groups on steroids.

The other problem is the more serious.  Mostly the language of users is about features and feature requests.  And when users tell you en masse what kind of features they want, you’re not likely to get much that is structured, systemic—or groundbreaking.  What you get is a huge mass of feature ideas that must then be managed: prioritized, scoped, and tracked.

But users aren’t designers, designers are designers.  From users we can get a deep understanding of problems—if we’re in the field and actively observe, not ask.  But it is the designer’s job to respond to those challenges in a holistic, systemic and elegant way.  Great products are not just buckets of the most requested features.  The perils of asking your users what to build are well documented, and I think it applies well in this case.

I don’t have the definitive answer about why the Kin died—and I don’t work in Redmond, so it’s hard to be too critical.  But even with all the research, the Kin was an undifferentiated, obvious attempt aimed at a narrow demographic of users.  Maybe the designers knew the perils I laid out here.  But if they didn’t, I would wager that stats and Muse played at least accomplice roles in Kin’s death.

With the introduction and popularization of Agile methods of software development, existing relationships and working agreements between user experience groups and developers are being disrupted. Agile methods introduce new concepts: the Product Owner, the Customer (but not the user), short iterations, User Stories. Where do UX professionals fit in this new world? Agile methods also bring a new mindset—no big design, no specifications, minimal planning—which conflict with the needs of UX design.

This lecture discusses the key elements of Agile for the UX community and describes strategies UX people can use to contribute effectively in an Agile team, overcome key weaknesses in Agile methods as typically implemented, and produce a more robust process and more successful designs. We present a process combining the best practices of Contextual Design, a leading approach to user-centered design, with those of Agile development.

Table of Contents:

• Introduction
• Common Agile Methods
• Agile Culture
• Best Practices for Integrating UX with Agile
• Structure of a User-Centered Agile Process
• Structuring Projects
• Conclusion

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

This week I recognized that changing your mind is hard work too. I’m not talking about simple “I’ll have tuna fish today instead of salad” changing your mind. I mean learning to look at the world in a new way.

Of course, changing minds is the business we’re in. People don’t need our help to keep doing things the way they’ve always done them. People don’t need customer data to keep building what they’ve always built. The value we bring is in giving you a new way to look at the world. Even if we’re just working on a usability improvement, no one builds an unusable interface on purpose. People build unusable interfaces because they are looking at the world the wrong way. Usually, because they are looking at the world as an engineer, instead of as a user.

So… we were doing a vision this week. This is the part of Contextual Design where we’re done collecting and consolidating data and we’re finally allowed to invent new designs and new function. We’re finally able to set our creativity free. This is supposed to be the fun part.

And our vision wasn’t going smoothly. It wasn’t going badly, but the team wasn’t able to loosen up and invent. They’d add a piece to the vision and then they’d have to stop and discuss it. I’d bring them back to the vision, they’d add another piece, and then they’d stop and discuss that. It was a much slower and more painful process than I wanted it to be.

But, of course, it’s not about me. It’s about the team. And for the first time I recognized what was really going on here. We were building a vision, yes—but the real problem for the team was that the data was telling them that their current approach to the problem wasn’t going to work. This is a company with a lot of history and a lot of success with highly complex solutions for highly technical professionals. They’re trying to extend their product to amateurs and ordinary folk—and every single assumption, expectation, and habit they have built up over 20 years is wrong.

I’ve known people in this situation shut down and refuse to listen. To their credit, my team didn’t do that. But inventing a design that would really work for these users was forcing them to change their mind—was forcing a paradigm shift. Every time my team stopped visioning to discuss with each other, I could almost see them tearing at the walls in their own minds, opening windows, creating new ways of seeing the problem—which enabled them to invent new approaches in their vision. It was maybe less fun, but it was absolutely the vital work this team needed to do to invent a successful product.

Will they succeed? I don’t know. They’ve succeeded in making the customer data their own, and seeing in a new way. Now they have to teach their organization to see the world the same way, and that’s a hard task. The data will help—it’s pretty compelling when it’s spread out over all four walls of a room. But it will be a big stretch for the company and maybe they’ll choose to go back to the products they’re familiar with.

But they won’t go in blind—they won’t put together a product that can’t work for these users only to watch it fail in the marketplace. They won’t waste a boatload of money and an immeasurable quantity of passion and commitment building a product preordained to fail.

For today, that’s enough.