I really looked forward to a modern treatment of how to make systems easy to use. This article is not it. It sets out to explain how designers work with clients to determine just what a computer system will do. The title claims to inform the “real work of design.” I am sad to report that the article misses the mark. The author did not build on the existing body of knowledge for humanistic design [1,2,3,4].

The article seems to support a separation between the client meetings and the designers’ “heads down” work. Designs that make systems easy to use must involve an expert in the job being automated, who may or may not be the client or even one of the client’s employees, each step of the way. The hand-waving flavor of this article makes no such demands and suggests that the design process can and should proceed separately from the client. This too often leads to missed expectations and frustrated end users.

The importance of role-playing is emphasized, but there is no mention of the use of prototypes or storyboards to tease out the end users’ real needs. There is a tacit assumption that clients understand their needs; yet, too often, they really have a high-level notion of what they want. The hard work of discovery demands the active participation of experts from the problem domain. The author’s suggestion of embodied performance heads in the right direction, but there is no mention of how to realize such understanding. This article would be stronger if it related the embodied performance idea to the systems approach for systematically determining the functions of the human element of the system design. Namely, develop system objectives, collect data, write requirements, examine alternatives with a prototype, select the cost-effective approach with the client, and then create detailed implementation requirements. Then, the prototype could be used to examine people’s usage of the system and check out the various scenarios before committing to expensive implementation. Clients prefer to see their needs demonstrated in a working prototype before there is a major funding commitment.

This article suggests a soft approach to system design, without the need to involve the client in the hard work of reducing needs to features. This can only be done when there is a problem domain expert on the development staff. The article does not state this need and leaves us thinking that hand-waving or role-playing is sufficient for customer interaction.