There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.
We previously posted an introduction to different UX roles, highlighting information architects, usability specialists, and visual designers. Cooper classifies these roles as interface design roles and clearly distinguishes interaction design as a different role entirely. Alan Cooper wrote the first UX book I ever read, About Face: The Essentials of User Interface Design (recently revamped to About Face 2.0: The Essentials of Interaction Design), and is absolutely one of the titans in the UX space. Kent Beck is the father of extreme programming (XP), and comparably iconic (titanic?).
Quotes and commentary
We’re pulling several quotes of Cooper’s from the debate as he clarifies thoughts for Beck in the context of that debate. We will add our thoughts as we go. Read the interview to see Beck’s responses and for full context of Cooper’s quotes.
XP is a tool for getting a grip on those shifting requirements and tracking them much more closely. Interaction design, on the other hand, is not a tool for getting a grip on shifting requirements; it is a tool for damping those shifting requirements by seeing through the inability to articulate problems and solutions on management’s side, and articulating them for the developers.
Cooper establishes that he believes XP is focused on making a broken process more efficient. He sees the role of interaction designer much as we see the role of a product manager when eliciting requirements. Cooper goes on to clarify why he thinks XP, while definitely making things better, falls short because it doesn’t try and fix a fundamentally flawed process.
The instant you start coding, you set a trajectory that is substantially unchangeable.
We’ve pieced together a definition of an interaction designer’s role from three of Cooper’s comments.
I’m advocating interaction design, which is much more akin to requirements planning than it is to interface design. I don’t really care that much about buttons and tabs; it’s not significant. And I’m perfectly happy to let programmers deal with a lot of that stuff.
Interaction designers don’t do metaphors and don’t do ways of information presentation—what they do is deal with behavior and with what the solution is going to be.
During the design phase, the interaction designer works closely with the customers. During the detailed design phase, the interaction designer works closely with the programmers.
Cooper uses an architecture analogy to explain that interaction designers perform an ideation step in transforming market requirements into software requirements. Interaction designers gain and apply an understanding of the objectives of the users, and determine what problems should be addressed in software. Interaction designers also play a role at determining how this software implementation should be approached.
Cooper explains interaction design with an architecture analogy in the interview: architects elicit requirements from customers, then document requirements (blueprints), then iterates with the implementation team (builders) to refine the documented requirements. Sounds a lot like requirements management.
The approach that Cooper lays out is decidedly un-agile. He believes that customers can not tell us what they want, and that once we start coding, we’ve committed ourselves to a particular solution. This is in direct contrast to Beck, who believes we can refactor as we go, and use tactical guidance from customers to help us stay pointed in the right direction.
The thing is, the customer is just not going be imaginative and will not visualize a “bigger thoughts”; their “bigger thoughts” are going to be very small.
We agree that simply asking stakeholders what they want won’t result in great software. Interviewing stakeholders with the goal of understanding what they need and why they need it can result in great software. Cooper explains that he believes that a relatively heavy (multi-week) elicitation and synthesis process is required. In this synthesis process, we convert from market requirements to product requirements.
Interaction design is mostly a subset of requirements management. What interaction design doesn’t cover is valuation and prioritization of requirements and management of those requirements. It does cover elicitation, ideation, validation and collaboration. Interaction design also gets involved in the design of the implementation (when iterating with developers), so it is a hybrid role containing both requirements and design elements.