This is the first of a couple of heavyweight books to appear this year, offering us a methodology which will lead to improved usability in systems, delivering a better user experience. Deborah Mayhew is a hugely respected author of several other books, primarily in the area of cost justifying usability.

A second book in a similar vein from the famous and prolific Larry Constantine with Lucy Lockwood will be reviewed later this year at UIDesign.net

The Usability Engineering Lifecycle

a practitioner's handbook for user interface design

by Deborah J. Mayhew, Morgan Kaufmann, 1999

This has been a good year for exciting new titles in the UI Design field. This is another book which I really really wanted to like. Again it promised a methodology for improved systems design and usability. The sub-title indicating that the book is specifically designed for guys like me, practitioners, who need a methodology in order to make our job more repeatable and predictable. This tomb weighs in at over 500 pages and has taken me a long time to read and absorb, so was the effort worth it?

Usability for the reader

This book creates a great initial impression. On a first flick through, you have already learned something. The book is beautifully laid out and uses several graphic design techniques to improve accessibility. This is a highly usable book. Perhaps one of the first books on Usability, to have had proper usability analysis done on it, itself. Are you listening, other Usability authors?

The overall methodology is presented as a Flow Chart with 24 stages which appears before each chapter. I found this very useful as it clearly marks out the "road map" for the book.

The preface is worth reading. It explains that each chapter is split into 12 sections and these are listed as a Table of Contents at the beginning of each chapter. This makes the book extremely accessible as a reference guide. I found the prospect of two sections particularly interesting: Scheduling and Integration with other tasks; and Web Notes. The former promised to demostrate how to integrate usability engineering with OOSE (the established software development methodology from Ivar Jacobson); the later, was said to provide the hints, tips and alternatives needed in order to adopt the methodology to the web site design. Both of these indicate that this is a very up-to-date book which looks at the real problems which we all face trying to deliver state-of-the-art solutions.

Content

Chapter 1 offers us an overview of the whole book. Its 30 pages of management summary explaining why a methodology for usability is necessary and what can be gained from it, as well as the broad detail on what is required. This would make an ideal quick read for a boss. Consider using it as part of his "education" on building modern IT systems.

The flow chart for the "Usability Engineering Lifecycle" has been laid into three main sections, "Requirements Analysis", "Design/Testing/Development", and "Installation". These represent the big 3 sections of the book. Within each are a number of tasks, for which a chapter is provided. So here they are as a simple list: User Profile, Task Analysis, Platform Capabilities / Constraints, General Design Principles, Usability Goals, Work Re-engineering, Conceptual Model Design, CM Mock-ups, Iterative CM Evaluation, Screen Design Standards, SDS Prototyping, Iterative SDS Evaluation, Detailed User Interface Design, Iterative D UI D Evaluation, User Feedback. There is a fourth section tagged onto the end "Organisational Issues" which has chapters on promoting the methodology and project planning and tracking as well as organisational roles and structures.

So we have a book which seeks to teach us a great deal - Usability, Design, and Process. It would be impossible to review all of this in detail. I am also not best placed to do such a broad evaluation. I make no apology as I am not a Usability expert and have no formal background in HCI. I am a software designer who knows a little about UI Design. I also know a little about development processes. So it is likely that this review is biased from the perspective of a designer not a usability engineer.

Chapter Layout

As I mentioned, each chapter is set out in a number of sections. These are clearly differentiated and some of them, the anecdotal ones are boxed in grey. The sections are Purpose, Description, Scheduling and Integration with other tasks, Roles and Resources, Sample Technique, Level of Effort, Alternative Techniques, Short Cuts, War Story, Web Notes, Sample Work Products and Templates.

There is a great deal of Mayhew's experience delivered with many of these sections. The sample templates are particularly useful for someone wishing to introduce formal process and provide templates for writing things down. These templates have obviously been developed from experience. So why re-invent the wheel? Copy someone else's work instead.

One or two sections have to be questioned, such as the "Level of Effort". The problem is that the numbers are obviously relative but the base line (i.e. the size and spec of a typical project) is never explained. I am not in a position to evaluate sections such as "sample technique" across all 20 or so chapters, so I will concentrate on UI Design. This may or may not be fair.

I felt that the Roles and Responsibilities was a little lightweight as it concentrates on whether the UI Designer or Usability Engineer are leading the team. Once again programmers get a raw deal and there is little appreciation that several flavours of programming talent go into delivering a complex, usable system. This was the first hint that the book is a fine grand scheme but fails to deliver on real practicality.

Finally, you can skim the whole book by reading the page summaries in the side bars. This is a technique admirably employed which has been seen before in books such as David Taylor's "OO: A Manager's Guide".

Requirements Analysis

The introduction makes it plain that Mayhew is firmly in the "Contextual Analysis" camp. She, like me, believes that analysing what is currently done, is the best way to move forward with a design. Don't ask the Users how they would like it to work, just ask them what they do. In other words, leave the designing to the designer. There are references to Beyer and Holzblatt's Contextual Design as well as Mayhew's own approach. Several pages are spent on how to integrate this with OOSE. Mayhew makes some attempt to explain how Contextual Task Analysis can be done using Use Cases. She makes two key observations. Firstly, that Use Cases must be contextual to really work. This I believe is crucial, however, she fails to point out that this is fundamentally different from the Jacobson approach and immediately breaks down because a Contextual Use Case which describes how the Users currently work, cannot be used to describe how the system should work and consequently cannot be used for testing purposes. As this is the foundation of Mayhew's integration with OOSE, there is a fundamental mismatch. I find it extra-ordinary that a pre-release reviewer didn't point this out.

Her second key point is well made. She states that Use Cases should be Goal oriented. This is Alistair Cockburn's approach and its a pity that she didn't reference his work.

Overall I failed to be convinced by this integration of Use Cases and Usability Engineering for Requirements Analysis. The approach described suggesting that Use Cases can be used as the starting point, seemed rather unbelievable (speaking as someone who has tried it before without success).

Use Cases aside, this first section is very convincing and the worked example of a Police Station application, together with the completed requirements paperwork had a very true ring about it. More of those years of experience shining through. Overall I found this first section packed with practical advice and very good templates. Its incredibly thorough without being as heavyweight as the Hackos & Redish book on the topic.

Chapters 5 & 6 on Platform Capabilities and General Design Principles, was for me the start of some frustration with the book. They were really too wordy and though highlighting the importance of the tasks, there was too much reading involved to extract the information. This was to become a recurring theme.

Design, Testing, Development

This section starts with a chapter on Re-engineering i.e. designing out the process problems rather than designing them into the software. This was all very well but the chapter avoided mention of office politics and therefore it isn't really good advice. You cannot tackle re-engineering unless you are a good politician. Again the chapter is wordy and there is surprisingly no suggestion that the system prototyping can be used to facilitate the re-engineering.

Next we move on to the UI Design, starting with Conceptual Level. Mayhew again takes a stab at OOSE/RUP by pointing out that it has traditionally been weak on specifying UI. Quite so.

There are some useful tips in this section, such as using both top down and bottom up design along with developing several alternative designs. This didn't ring quite true with the advice that upto 3 alternatives should be selected for usability testing of a prototype. I have never seen anyone with the budget to develop three prototypes.

Perhaps to avoid an area that Mayhew (or anyone) doesn't fully understand, Use Cases suddenly disappear from the picture. There is no mention of how to use them to move the UI Design forward. We are told at what stage the Conceptual Model should be done and how that fits with OOSE but not the specifics.

I liked the sample technique presented but again would question the level of effort suggested. At only 5 weeks work, I assume we are building quite a small system in the worked example. This highlights a key point. Do we really need such a heavyweight methodology for a small to medium sized system.

I found the sample work templates for the conceptual model rather disappointing. They seek to pigeon-hole the system into a certain type of design. Its far too early for this in my opinion. I also feel that the pigeon holes provided don't lend themselves well to bigger CSCW type systems. However, the principle of what should be written down is sound enough.

Next are the Conceptual Model Mock-ups or prototypes. There isn't much said about this. Like the OVID book, I felt more could be said on building the prototypes and how to select what to build and how to make the decision about whether it is a paper prototype or working program. Sadly not in this book.

The next chapter looks at iterative evaluation of the prototype. This is a long chapter and highlights Mayhew's strengths as a Usability engineering. I found the alternative technique section, the most useful as it talks in some depth about Heuristic evaluation and refers to Nielsen and Mack's book on the topic.

The next chapter moves on to Screen Design Standards and argues the case for these. Good enough advice. This is followed by a discussion of prototyping standards. This is a good observation. For example, when someone first suggested a combobox with "type-ahead" search, it is almost certain that they had to build one to find out if the technique worked. If you are going to introduce new "widgets" into your design, prototyping them first before writing them into the standard is a great idea.

Following the prototypes for new widgets, comes the iterative evaluation. Are you beginning to recognise a pattern here?

Design Roundup

Finally we get to the detailed User Interface Design. Firstly modeling and writing down the specification. The sample work templates for this were frankly a little vague for my liking. Predictably the design is followed by iterative evaluation. This is done on the real code, and the key is to collect timing data. This highlights that the number one aspect of usability is speed. It is also rather poignant that we are 3/4ths through the book and we are measuring the speed but the methodology presented has nothing to address designing in fast reactions, in the first place.

AWOL

All the issues related to coding and plumbing-in that design are not addressed. Also not addressed are real world problems such as transaction scoping and exception handling. There are no UML diagrams in this book which seeks to integrate with real software development and OOSE in particular. The real world problems related to system architecture and design which affect usability are never discussed. The book is rather light on design but thorough on usability. Before we will truly be at a methodology which solves design for usable systems, we must better integrate design and usability with software construction than that presented in this book.

Summary

Despite making a superb initial impression, I was left with a feeling that it slightly misses its mark as a guide for practitioners. Its fine on the grand scale and no-one could argue much with the overall methodology flow chart. However, fine detail and depth are still missing. There is still a gulf between books like this and books such as the Java Look and Feel Guidelines. The book also suffers from being a little too academic and like several other software industry methodologies, it falls into the academic trap of proposing too many models and too many layers of abstraction. My experience in the field, is that regular practitioners don't have time or resources to create and maintain many different levels of abstract models.

That said, this is still an important book, which has obviously taken years of effort to put together. It is beautifully designed and either the author or publisher deserve great praise for the production standard and readability. This is also the first serious attempt (to my knowledge) to merge a software development methodology (OOSE) with a usability or UI Design methodology. Again in the broad sweep of things it does achieve this merge, but it falls down in the detail. Much more can be done here over the coming years.

It is inevitable that I compare this book to Laura Arlov's book reviewed in March. Both books offer advice on end-to-end project development for improved system design and better user interfaces. One has a much more academic approach, the other has a heuristic, experience from the field approach coupled with some great fine detail advice. You will know yourself which you would prefer.

I think in conclusion that this is a good reference book to have on the shelf. Use it to answer questions which come up at different phases in a project, pick from it wisely and compare with others experience. When someone on the project says, "How should we go about interviewing users?", go and pick up this book, use the index and read the relevant material, then go and do the same in several other books.

Recommendation

4/5 - Not a "must have" book except for those who seek to improve the state-of-the-art. For the everyday field practitioner in UI Design, the Arlov "Dummies" book is a better and lighter read.