BJ Clark over at Marked as Pertinent has an interesting post on who should do acceptance testing. He starts there, but he spends most of the post on the really interesting question, which is the role of the Interaction Designer (ID).
His claim, which I agree with, is that the ID is responsible for the overall structure of the application as experienced by the user. Are we building the right system? Does it do what the user needs? Does it do it in a way that the user finds natural, providing just what is needed, when it’s needed, and nothing extra? These are issues for the ID to solve. (I actually prefer to call this the User Experience (UX) and talk about User Experience designers. No matter. There are fine distinctions, but they aren’t important here.)
It seems obvious when viewed from the user-centered side of the house that (1) this is a real job, (2) it needs to be done, and (3) it requires a whole-system view of the application. You can’t do the ID job if you look at the app in parts—if you take each subsystem or, Lord help us, each screen, and design it independently from the rest. For the user to have a consistent, comprehensible understanding of the app it has to present a consistent and coherent interface.
Yet your average developer has a real problem understanding this. Right now, this disconnect is creating difficulties in the agile community—the interaction designers (or usability engineers, or UI designers—whatever they are called in the particular organization) want to consider the application as a whole, thinking about all the parts together. The agile community doesn’t understand the need.
The agile approach to design is to do as little of it as possible. The agile approach to design looks like this: Write a story—which describes one particular part of the proposed app, independent of all the rest; design the system support for that story, including the UI—without planning ahead to ensure the UI is consistent; implement it; and wait for the users to complain. Fix it when they do.
I’m hardly exaggerating at all here. Agile developers have had such success with their build-a-bit/test-a-bit/iterate-a-bit approach that many see no reason why it shouldn’t work for the UI as well.
The origin of this kind of thinking goes back much further than agile methods. This is exactly how developers have been trained to think since Programming 101, which I think they are taking in in grade school these days. They are taught to split implementation into modules; every module should be independent of every other; no module should be dependent on the internals of any other; you should be able to completely change a module implementation without affecting any other module. If you have to change other modules as well, the task is given a special name—refactoring—and you get to complain a lot and have a good excuse for being late.
But this is the exact opposite of good interaction design. If any element of the interface changes, it may well require changes all across the system. If I change how popups work in the Accounts Receivable package, it may well be necessary to make the parallel change in the Reporting package—otherwise the user experience is inconsistent. If I restructure the layout of one page of my website, it’s going to look like it doesn’t belong with the rest of the pages—so I have to change them too.
What this means is you have to do some up-front planning to get the user interaction right. You have to map out the application as a whole and think about how the parts are going to fit together, so you can decide what kind of screen layouts, user interaction mechanisms, and graphic details will work to communicate to the user throughout the app. You have to think about the needs of each part of the app to ensure your interaction architecture provides all the necessary components to make the function visible. Thinking this way is as natural to interaction designers as modular thinking is to developers.
In fact, developers do think systemically. Suggest a feature and they’ll automatically do a deep dive—working out the whole set of module changes required to implement it, down to changes in the underlying database structure. And they’ll make sure that this set of changes works together—systemically—to implement the feature. It’s just that they keep the system coherent vertically, by diving from the user-visible behavior all the way down to the technical implementation, rather than keeping it coherent horizontally, across all aspects of the system that affect the user experience.
If you don’t consider the overall user experience as a whole, you’ll have to refactor your interface during development—which can easily mean massive change across every part of the system, with massive user disruption. If a little up front user research and interaction design will avoid such a mess, it’s probably worth it. Our challenge is to find the appropriate way to incorporate interaction design into agile methods.