Joe's Jottings
Jottings Number 55, by Joe Podolsky:
From: uunet!HP-PaloAlto-om4.om.hp.com!JOE_PODOLSKY
Date: Tue, 14 May 96 17:30:45 -0700
Subject: Satisfying Systems, or, Film Versus Software
What we call things matters. We humans are programmed to respond to labels, often ignoring substance. For example, Nass and Reeves (see Jottings #52) found that people related more positively even to standard computers that were designated (even self-proclaimed) as specialists or as teammates. What about labels we use in information technology? IT never claimed to be a science; we don't at all try to discover things. IT is fundamentally based on software, and software creation is often labeled "engineering"; we do, after all, build things. But engineering is based on well-proven theories and practice. Engineering is a _discipline_, but most software is not disciplined. Algorithmic constructs and formal methods, notwithstanding, most software is, at best, crafted. Craft implies art that is created following a structured process. Organizations like the Software Engineering Institute and gurus like Tom Yourdon, Capers Jones and Barry Boehm have long preached the benefits of software process discipline, but even their methods have not solved our perennial and continuously painful problem. It may be a bad rap, but our customers still complain that we don't meet their needs and, besides, we're too late and too expensive. I used to think that the answer was simply to "become more disciplined." That's what the Japanese tried to do. Their culture is much more amenable to structure, and they spent loads of money and energy to build software factories, to certify their programmers, to do software "right." This approach, after all, worked with VCRs, cameras, and TVs, industries which they captured through their focus and disciplined, low-cost manufacturing processes. But the Japanese failed with software. The counterfeiters in China steal U.S. software, not Japanese. We in the West may be process slobs, but we seem to be building what the marketplace wants. So, we seem to be left with software as an art. Fine art, painting, sculpture, etc. seems a little extreme as a model, since it implies the self-expression of the artist with little regard to customer wishes. But we might look at commercial art for some metaphoric lessons. The two most visible forms of commercial art are films and advertising. Analogies to software creation are abundant. Films, advertising, and software all are strongly based in various physical technologies but also depend a lot on sociology and psychology for their success. All are judged ultimately by their success in the marketplace. All require the participation of teams of people. But there are some differences. First, and foremost for this discussion, films and advertising acknowledge their existence as an art form. Each film and advertising project has a single creative director. No such role is explicitly designated in most software projects, although each project may _de facto_ have such a person. Secondly, software has one attribute not present in films and advertising. Software has a life. Software, and especially information systems, require on-going support. Furthermore, the software becomes entwined with its environment and adapts and evolves, so that the identical code placed in different settings soon takes on completely different operating characteristics. Software is more like an old Volkswagen Beetle or a DC-3 airplane...or a well-worn shoe. There is, however, one area in IT and in software technology has long recognized its root in art. That is the "graphic unit interface," the tool which both links us to and masks from us the true complexity of the computer. _Interactions_, the ACM's journal on human computer interfaces, decided to confer Design Awards to the computer-based products that produce the best "quality of experience" for the users. The June 1996 issue of _Interactions_ reported the results of the first years entries. The awards jury decided, given the immaturity of their process, to honor six finalists rather than selecting a single winner. The six were: _Apple Guide_ from Apple Computer; _Graphing Calculator_ from Apple Computer; _Meeting Manager_ from the City of Edmonton; _The Muse_, a digital music stand from a group based at Carnegie Mellon University; _Nokia Feature Stereo TV, submitted by IDEO London; and NYSE Hand-Held Terminal_ submitted by Mauro/Mauro Design. What was most interesting to me, however, were the selection criteria that the jury evolved. They wanted criteria that would help them "pin down that feeling of satisfaction you get when you encounter a tool or toy that clicks with you on a deep level." The jury decided that "to create a great user experience, a design must be all these things: "_Needed_: Is the product needed? (Here is where we can include financial/market success.) "_Grounded in understanding_: Did the designers understand the needs and characteristics of the people who would be using the product? "_ Learnable and usable_: Is the product easy to learn and use? Are its features self-evident? "_Appropriate_: Does the design solve the problem at the right level...injecting just the right balance of technology and people into a situation? "_Product of effective process_: (Did the process involve) collaboration between different disciplines, a deep involvement of end users, and lots of little steps towards the goals? "_Aesthetic experience_: (Does the product evoke a) pleasing, sensually satisfying experience ... (considering) information, hardware, software ... the whole context? "_Manageable_: What is it like to use (the product) over longer periods of time? Does it fit well into the work culture? _Mutable_: Can people ... change the product to suit themselves ... (and) tailored for new uses?" I think this is a great list. Like any set of attributes, such as those offered by Boehm many years ago and HP's own venerable FURPS, these can be used as a checklist for product planning up front and for evaluation at release. But what's nice about this particular list is that it calls for a visceral communication through the product between the designer and the user, a linkage that evokes pleasure as well as productivity. HP's products often win design awards, so these ideas are not foreign to our culture. But we have a long way to go before our business systems can join this competition. But, building "pleasing" systems seems like a super way of using all those MIPS and all that bandwidth that we now have to play with. Way back in Jottings #24, we quoted PARC's John Seeley Brown who suggested we want "beautiful" systems," but these criteria are much more specific and useful. Do think that we should use these criteria to design and evaluate our systems? If so, how shall we start? Do you know of any systems that can meet these criteria, either from internal groups or from vendors? Regards, Joe