Interaction Design and Agile Methods
September 3, 2002
I recently heard a talk by Alan Cooper, the designer of Visual Basic, an author of several books, and the founder of a company that specializes in interaction design. By "interaction design," Cooper means a methodology that produces software specifications by doing interview-intensive "ethnographic" research: modeling actors (personas), then running through scenarios from each of their perspectives. This isn't a new idea, of course, but Cooper gives it a radical twist that puts him at odds with advocates of extreme programming and other "agile methods." Classically, design-intensive approaches have at least paid lip service to the idea that users--to the extent it was feasible to inject them into the design process--could improve the outcome. Cooper flatly rejects that notion. Designing complex systems is hard, he said; only minds that are innately talented, and then specially trained, can do it well. Users can't articulate what they need, and may not even recognize it when they see it. So it's up to the interaction designer to figure out what they really need--as opposed to what they think or say they need.
To a release-early-and-often guy like me, this sounds wildly arrogant. I've had my best success as a developer being a team member who is also a toolsmith. Living with the day-to-day mundane hassles of information management and communication spurs me to imagine ways to improve things. Scripting those improvements in small steps, putting them into people's hands, watching how they do or don't use them, and then iteratively tweaking the system from the inside out -- these are the tactics that have served me well. (I hope the various teams I've worked with would agree!) Of course, I've only done this on a small scale. Groupware I've built is used by teams of only five to ten people. Web sites I've built have been used by tens of thousands of people, but they've only involved a handful of interaction scenarios. The kinds of software projects that are prone to spectacular development and deployment failures -- things like CRM (customer relationship management) systems -- have engineering complexity that Cooper (and others) compare to that of a Navy battleship. I don't know how to build things like that. I suspect the problem space is so big that there is room within it for both interaction design and agile methods to make useful contributions. As decentralized and loosely-coupled Web services kick into gear, the need to merge these disciplines grows more urgent.
There was a fascinating contradiction in Cooper's talk. His arrogant-sounding assertion that users wouldn't know what they wanted, even if they saw it, was offset by a deeply humanistic take on the failure of product planning and design. The problem here, he said, is that the "happy fraternity" of business, engineering, and marketing managers has been torn asunder. People who used to work face to face are now separated by the products of IT: email, IM, the intranet. Lacking emotional bandwidth, the focus all too easily drifts to solving the wrong problems. The same kind of syndrome afflicts us on a larger scale, he said, as we replace human touchpoints (sales clerks, travel agents) with software. Automation works to a point, but without the ability to cajole, negotiate, compromise, and apply the grease of human judgement, systems don't work well. Press zero to connect to a real person.
I've been thinking about this problem lately as I've read through piles of Web services specifications -- for security, orchestration, and all of the other stuff that we'll need in order to reach service-oriented nirvana. My conclusion is that there's no there there, if by nirvana we mean an interconnected software fabric with no human touchpoints. Web services specs talk about things like assertions, attributes, contracts, transactions, and compensation logic. They describe these things mainly in XML that is human-readable for only special kinds of humans. Even an XML-savvy reader will find that Web Services Flow Language (WSFL), XLANG, Web Services Choreography Interface (WSCI), Business Process Execution Language for Web Services (BPEL4WS), and Security Assertions Markup Language (SAML) tend to run together into a blur of angle brackets.
Last week a joint W3C/OASIS Forum on Security Standards for Web Services helped to put some flesh on the bones of these specifications. People from publishing, aerospace, finance, and government told stories about electronic publishing, collaboration with parts suppliers, corporate cash management, and government recordkeeping. These "use cases" were described not in XML, but in words and pictures -- albeit statically, with no ability to simulate interactive flow. In Cooper's world, that simulation happens in the mind of the interaction designer, and is the defining talent of the profession.
For Temple Grandin, the autistic designer of livestock processing plants who was famously described in Oliver Sacks' An Anthropologist on Mars, design is a simulation that runs on the "Sun workstation" in her head. "I visualize the animal entering the chute," she reports, "from different angles, different distances, zooming in or wide angle, even from a helicopter view -- or I turn myself into an animal, and feel what it would feel entering the chute."
Since cattle can't speak for themselves, it's necessary to imagine their experiences in this way. But what about people? The great tragedy here, of course, is that programmers -- who as a group tend toward the autistic end of the spectrum -- are the ones who have been expected to imagine the user experience. The disastrous results we so often see should not surprise us. Cooper's claim that interaction designers are a different breed is credible. People who combine the mental simulation powers of the semi-autistic with an empathy for human experience that is distinctly non-autistic may, however, be a very rare breed.
I asked Cooper: "Is there no hope that interaction design can itself be made interactive, with the assistance of software?" He thinks not. If he's right, then the future of software will depend on our ability -- as a society -- to mine a narrow vein of talent. I don't like the odds. With components and scripting, we've made the skills of a small number of uniquely talented programmers available to a much larger group of application developers. Doing the same thing in the realm of interaction design is a goal we ought not to lightly dismiss. From Dan Bricklin's Demo Program to more recent pnambic efforts like SILK/Denim, there have been efforts to make UI design a collaboration with users. The new agile methodologies, of course, make working software the vehicle for collaborating with users in the discovery of requirements.
The deep principle at work here was explored by the chemist-turned-philosopher Michael Polanyi, most notably in Personal Knowledge and The Tacit Dimension. Polanyi, who died in 1976 and is now being rediscovered by the knowledge-management movement, said that knowing is inseparable from doing. Much of our knowledge is tacitly held. We perform in ways that we cannot articulate.
Ethnographic research is one way to access that tacit knowledge. Working software is another. Are these strategies mutually exclusive? Let's hope not.