WQ Usability Skip to main content
     Home     What we do     Storytelling for User Experience     Articles and downloads     About us

Crossing the Chasm:
Promoting Usability in the Software Development Community

A UPA 1999 Workship Report by Whitney Quesenbery

User-centered design should be a core part of every software development effort yet, despite its well-documented paybacks, it has yet to be widely adopted. Too often, user-centered design remains the province of visionaries rather than the everyday practice of programmers and analysts. Despite a general consensus on a basic approach to user-centered design (UCD), there is little understanding of the process and how it fits into larger software development methodologies. A workshop was organized during the 1999 UPA conference to explore the reasons why UCD has failed to gain wide acceptance and to formulate a plan for promoting it.

We started with Geoffrey Moore’s model of new technology introduction, presented in his book Crossing the Chasm (Moore, 1991,1999). Moore argues that the progress of a new idea or product from the visionaries and early adopters to the more pragmatic mainstream group is not a smooth curve. Instead, a chasm exists between the visionaries who focus on the concept and its intellectual value and the early majority who want assurances that the new approach will serve a proven business purpose. Success and general acceptance requires not merely time and incremental gains, but a fundamental shift in the way the technology is promoted. Although Crossing the Chasm was written about product marketing, it applies just as well to our "marketing" of user centered design to the software development mainstream.

The participants in the workshop represented a broad spectrum of UCD practitioners. They are consultants and staff designers, working for commercial software developers, on internal corporate software and in academic environments. Their backgrounds include cognitive psychology, usability testing, teaching, technical communication, instructional design and programming. Typical projects covered an equally wide range of complexity and interaction requirements. Several of the participants had developed user-centered design methodologies.

Shared Goals

The workshop started with individual introductions. The group quickly reached consensus on a list of shared goals for user-centered design. Almost all participants had been frustrated by the slow acceptance of UCD, even when their organization had clear evidence of its success. Our goals for the future centered on the establishment of user-centered design as an integral part of software development, and on having clear lines of communication with other participants in this process. We hoped that our work would lead a future in which:

  • The value proposition of user-centered design is understood
  • UCD is understood to encompass the entire user experience, not just the user interface
  • UCD is integrated into the software development methodology
  • There is cooperation between groups and an understanding of how we fit together
  • We have metrics and process to ensure success and demonstrate professional expertise
  • We have clear language to talk to developers, marketing and business managers 

Barriers to Acceptance

The first question we had to answer is what is preventing the mainstream from understanding and accepting usability and user-centered design. Most presentations of UCD focus on describing the process and techniques. Although case studies are typically used to demonstrate the value of the approach, they have often not had the desired effect. Rather than being understood as an example of a new paradigm, they are seen as exceptions or experiments. Moore’s model shows that the early majority wants not the "technology" itself, but a "whole product" solution that solves a business problem. Clearly we have not presented UCD in a way that meets their needs.

We used affinity grouping techniques to identify obstacles to acceptance and organize them into groups. The issues broke down into three areas:

  • Business
  • Integrating with other participants
  • UCD process and methodology

For each of these areas, we then looked at how we contribute to creating barriers to acceptance and what we can do to overcome them. Business issues, not surprisingly, centered on time, budgets and determining the value or return on investment (ROI).

  • Managers are concerned about managing the workload and meeting their deadlines. UCD practitioners often cannot reliably estimate time for an iterative process and lack the management skills to contribute to high-level planning.
  • Key cost issues include infrastructure costs for usability labs, the perception that UCD adds to product development costs and the difficulty of evaluating the ROI and success of UCD. We contribute by failing to document our successes in business terms – tracking ongoing costs savings during development as well as savings in downstream business areas

Possible solutions to these issues include

  • Learning to communicate with business and software development management so we can provide reliable time and cost estimates
  • Finding out who the keys to the planning process are and work with them to integrate UCD into the schedule, so analysis, design and testing activities can provide meaningful input.
  • Set clear usability metrics so success can be measured
  • Collaborate with the people and departments who can help us document success stories and make the case for the effectiveness of UCD

Many of the issues raised surrounded how user-centered design integrates with the rest of the software development team.

  • The development culture is seen as hostile to UCD, with fear of change, turf protection and a lack of share values and objectives all contributing to the problems. They see UCD practitioners as outsiders who do not understand their issues, sometimes justifiably.
  • Software development methodologies themselves raise barriers. They may be mandated, but not followed or there may be multiple methodologies in use making it harder to integrate UCD into them. And some methodologies including RAD and OOAD appear to incorporate interface design and make UCD unnecessary.
  • Integrating user-centered design calls for good team-working skills and new team management can itself be difficult for people used to working in clearly defined departments. As UCD tried to gain a foothold, we can appear to be demanding radical change, may not work effectively in teams ourselves and can appear inflexible in promoting our tools and techniques.

Solving these problems requires both business skills and the ability to clearly communicate the process, techniques and benefits of UCD.

  • Partner with methodology owners to educate them in the ways UCD can integrate into the software development process.
  • Create a flexible framework for the UCD process which can work with a variety of software methodologies. Work with vendors to integrate UCD into their methodologies.
  • Be flexible in negotiating process and activities.
  • Lobby for usability values and show how better usability helps everyone.
  • Partner with organizational change people, learn facilitation and team-building skills, clearly articulate how the collaboration between different groups on the team and act as a leader in providing awareness of issues.

Finally the user-centered design process and methodology can itself be a barrier to acceptance.

  • Usability is seen as subjective when practitioners are too open with uncertainties, quote different sources to suit our needs and say "It depends" when a clear answer is wanted.
  • User-centered design is seen as chaotic. Iterations can give an illusion of moving away from the goal by people used to a linear, waterfall process.
  • UCD practitioners do not present a global vision. Others investigating the field can be confused and unsure of whether they are hearing about one process or many.

Better education materials and a clear, shared vision which can be communicated from many points of view are the keys so overcoming these obstacles.

  • Use usability testing data to show that we can measure user satisfaction.
  • Provide concrete techniques, templates and processes. Identify critical check points and show how they are met.
  • Make UCD skills more visible, back successes up with hard data – and take credit for the successes.
  • Create and use education materials which show a commonality of approach and a clear methodology.

This exercise helped us focus on how UCD practitioners can be proactive in changing the situation. Two main issues emerged from this work: a lack of business skills and a lack of a clear methodology which can be communicated. To cross the chasm we need to demonstrate not only that we understand and can address business issues but that user-centered design is a solution to a clearly definable problem.

Creating a Message to Sell Usability

The barriers exercise exposed many areas where the usability community can do more to not only educate other participants in software design, but also to present the case for UCD to software developers and business partners in their language.

Our first step was to identify all of the different people, so a value proposition could be tailored for each of them. This was more difficult than we anticipated. With so many different types of organizations represented, it was hard to agree on the list of stakeholders. We solved this problem by identifying not titles or corporate positions but roles in the software development process, no matter how many individuals fill them. For all of them, we identified risk as a major concern so our strategies focused on how user-centered design minimizes risk.

Role Value Proposition: Proving UCD Offers Less Risk
Person with profit and loss responsibility User centered design will help you make more money and lower costs Anticipate support costs based on usability design

Track support costs and anecdotes

Product owner Confidence in meeting user needs

Provide goals for measuring success

Gauge success of product before release

Prototyping give a target and a way to communicate vision

Estimate of customer satisfaction

Performance goals measurements

Usability test results

Customer satisfaction surveys and results

Metrics used and worked out

Schedule owner Milestones of UCD reduce risk of schedule slipping, reduces chaos

UCD increased predictability – reduced surprises

Evidence of less slippage, slippage counter-example

Examples of schedules

Try to find impact of usability

Person who has to sell the product UCD confirms customer goals and how they will work with the product.

Prototypes demonstrate product early

Usability can be part of sales pitch

Customer involvement and testimonials
Quality manager ISO usability standards (FDA)

Identifies test cases through use cases

Evidence of fewer usability bugs and reduced support calls

Show support for ISO standards

Code manager Early UI specs will reduce hours and late nights later

Good UI design makes a more successful product

Show less rework of code through good prototyping

Post mortems of successful projects

Chief technologist Knowing UCD makes them more effective to company and therefore more effective

User needs mapped to technology

UCD is cutting edge

Direct observation

Video clips showing usability testing and results of iterative design

Methodology owner Well defined methodology makes process of execution easier

ISO standards for usability

Documentation of a clear process for user-centered design
Requirements owner UCD can refine requirements and provide validation and prioritization Traceability from user requirements to user interface
Worker bees Design goals are better defined, so there is less uncertainty in the specs

Users will accept final product

Fewer bugs and less tweaking when requirements are better understood

Developer testimonials

Usability observation

Customer Participation in design and reviews of prototypes make result more predictable Change prototype while they are there

Using a Methodology to Sell Usability

The lack of a common methodology which could be used to communicate the user-centered design process was one of the initial issues identified for the workshop to consider. It is clear that the scope, complexity and business organization for a project have an effect on not only the scale but also the approach of some user-centered design activities. This can mask an underlying consistency, but as we looked at some typical methodologies, a general pattern of tasks and general approach was clearly visible.

Based on this, we examined Cognetics’ LUCID (Logical User Centered Interactive Design) to see if it could serve as the basis for a common framework. This framework would define the general outline and goals for UCD activities, but would not dictate specific tools or techniques.

To be effective it would have to be scalable – as useful for a small project as for a large one – and would have to encompass the range of existing methodologies. We developed a taxonomy in which:

  • A user-centered design framework supplies a high-level definition of the process
  • For each organization adopting the framework, a specific methodology is developed which is tailored to the scope of the product
  • The methodology is populated with techniques

The importance of distinguishing between a shared framework and individual methodologies became clear as we looked at different methodologies which participants had used successfully. The variations between them were less a result of different philosophies than a practical response to projects of different types and scale. Some projects, for example, had a formal analysis period which ended in a user requirements document; others iterated between analysis and design more fluidly, testing conceptual prototypes to validate design ideas. In each case, the choices were effective for the context and produced good results.

It was important that the framework to be able to accommodate different organizational structures as well as different relationships with the users and choices of techniques. One of the strongest areas of agreement in the workshop, however, was that user-centered design is the one way to produce usable software, not simply one way among many. With that stake firmly in the ground, it was clear that the framework has a role in providing a definition of the approach and in acting as a mechanism for comparing different practices of user-centered design – both within the UCD community in evangelizing our approach.

We are continuing to refine LUCID to incorporate the broadest definition of the UCD process. Information about LUCID is available at http://www.cognetics.com/lucid/.

References

  • Moore, Geoffrey A, McKenna, Regis (Introduction), Crossing the Chasm Marketing and Selling High-Tech Products to Mainstream Customers. HarperBusiness, New York, 1991, 1999

 

A UPA 99 Workshop Report published in Common Ground, Vol 10 No 1,March 2000

The workshop leaders were Charlie Kreitzberg and Whitney Quesenbery, Cognetics Corporation. Our thanks to the participants for all of their ideas, energy and enthusiasm:

  • Nigel Bevan, Serco Usability Services
  • Nicole Burton, US Department of the Treasury
  • Francie Fleek, SMS
  • Cathy Gilbert, Edward Jones
  • Laura J. Grosvenor, University of Texas at Austin
  • Avi Harel, ErgoLight
  • Jon Innes, Cisco Systems
  • Linda Kohli, GE Medical
  • Teri O'Connell, AMS Center for Advanced Technologies
  • Martin Rantzer, Ericcson
  • Thrya Rauch, Tivoli
  • Ken Sadahiro, National Instruments Corporation
  • Catherine Spiaggia, Indiana University
  • Cindy Toohey, McGraw-Hill New Media
  • Larry Wood, Brigham Young University

The URL for this article is: http://www.wqusability.com/articles/upa-workshop.html

Whitney Quesenbery works on user experience and usability with a passion for clear communication. She is the co-author of Storytelling for User Experience from Rosenfeld Media. Before she was seduced by a little beige computer, Whitney was a theatrical lighting designer. The lessons from the theatre stay with her in creating user experiences. She can be reached at www.WQusability.com