In the third in the uidesign.net series of master interviews, we present the thoughts and wisdom of Larry Constantine. Larry is one the principals of Constantine & Lockwood, a design and modeling consultancy operating out of the east coast of the US. Larry is also Adjunct Professor at the University of Technology, Sydney, Australia. As well as his work in User Interface, Larry is known for his work in fundamental software engineering principles back in the 1970s. He is also a regular columnist in Software Development magazine.

Larry was good enough to lend his support to uidesign.net back in mid-1999 and kind enough to let us use his endorsement as part of the site's banner and branding.

This interview was conducted by email during the first days of May with Larry by David J Anderson.

I always associated the name "Larry Constantine" with your Structured Design work with Ed Yourdon. It was a foundation of what I learned at university. When and what prompted you to get interested in User Interface Design and how did you make the leap from software engineering across into UI?

Yes, structured design was where it all started for me, but returning to the field in 1987-88 after spending 15 years in another profession, I found that the greater challenge was in making software more usable. As a user of development tools and office software, I was amazed by how the major vendors could consistently deliver software that was appallingly hard to use despite well-publicized commitments to "user friendly" interfaces and sizable investments in high-profile usability labs. Something was obviously going wrong somewhere in the process. For all their investment, software houses were not making good on the promise of creating usable systems.

In shifting my attention from the design of internal architecture to the design of the external interfaces, I was just looking at the same box but from a different perspective. In many respects, my recent work is a straightforward outgrowth of a longstanding interest. I have always been interested in understanding how to design and build better systems, then translating that understanding into something that could be taught to others. In that sense, I am still doing today what I was doing back in the 1960s.

The truth is that it is just not possible to address software quality issues or design methods without looking at the organization doing the work and how that work is managed. Actual practice is always intimately tied up with organizational, managerial, and political issues. The ultimate usability of the delivered product is often shaped more by management than by methods. Access to end users, for instance, is often hindered by sales and marketing staff who want to serve as intermediaries maintaining control over how information from customers is interpreted. The best usability testing will have no impact if management simply ignores the findings in order to ship the product next week. The examples are endless.

How you manage the process IS the process.

My interest in management goes way back. Actually, my degree is in management, with minor sequences in psychology and EE, reflecting a mix of technical interests with a certain pragmatism. I am always aware of return-on-investment. Good tools and techniques are ones that give you a lot of improvement relative to what you invest in learning and applying them. In our own work, we are always looking for how to improve the bang-per-buck, how to do more with less.

Is it fair to say that Larry Constantine has a broad interest in software engineering, architecture and system delivery? How would you describe what you do and where your interests lie?

I suppose it's fair. I have always been an enabler, interested in enabling ordinary people to achieve extraordinary results. It was never enough for me just to be able to do good design. I wanted to understand how really good designs come about and then embody this understanding in a form that was teachable. This is why I became interested in theory, in models, and in methods, which are media through which such understanding and skills can be communicated.

I think this is really what separates us from Alan Cooper, for example. Many people see Cooper's work and the work that Lucy Lockwood and I have done as being closely related. In many respects this is true, and not entirely by accident. Cooper's personas, for instance, are an adaptation of our work on user roles.

Cooper also seems to agree with our original conclusion that the development process has been failing to deliver truly usable systems in part because so many user interface design decisions are left in the hands of developers who are ill-prepared to discharge that responsibility effectively. Where Lucy and I part ways with Cooper is in what we would propose to do about this situation. It appears that Cooper wants to wrest control over user interface design from the developers, whom he likens to inmates who have been allowed to run the asylum. To him, user interface design belongs in the capable hands of elite experts--like himself, no doubt.

In contrast, we are trying to equip developers with conceptual tools that will help them make better design decisions themselves and enable them to become better collaborators in the usability process. In many real applications, the user interface is so complex and involves so many elements that a complete design down to the last and lowest detail is just not possible to fix in advance. There will always be issues that arise on the fly and decisions that must be made within the implementation context. There are also not enough trained user interface designers around, and few companies can afford to assign one or more to every project. In the final analysis, usability is everyone's job, so it makes more sense to prepare everyone to do their part in the usability process.

Usage Centered Design is an attempt to apply a rigorous methodology to the practice of User Interface Design. Tell us some more about it and what you hope to achieve with it.

I wouldn't say rigorous, but perhaps systematic, methodical, disciplined. Usage-centered design is a process that helps designers and developers focus on what is most important, what is most likely to make a significant difference in terms of usability. This matter of focus is why we take a model-driven approach. Models make it easier for designers or developers to represent compactly their understanding of the key aspects of users, their tasks, and how best to support them. We want to make it more consistently possible to achieve first-class results on the first try. We believe we are onto something that really works, and the results of our clients and others we have taught to apply essential use cases and usage-centered design bear this out.

Essential Use Cases are one of the foundations of Usage Centered Design. Can you tell us briefly how they differ from other Use Cases that the readers may have read about or used ?

Essential use cases as employed in usage-centered design differ from "traditional" UML or Jacobson style use cases in three important ways. First of all, since they are used to drive the design of the human-system interface, use cases for non-human or "system actors" are not modeled with this technique. Second, compared to the conventional, concrete use cases, essential use cases are both abstract and purpose-oriented, shifting the focus from interaction to intention and from elaboration to simplification. Third, they represent a finer-grained model of the needs and intentions of users, one that identifies the basic structure of the tasks that users are interested in accomplishing. This granularity pays off in more flexible and finely tuned user interfaces that fit the inherent nature of the users' work.

I am not sure about market differentiation, but we certainly have tried to clarify the differences among the various styles of use case narratives and their relative advantages for different purposes. Essential use cases were devised to support user interface design and to enhance usability. Concrete, more elaborated use cases are better suited for informing the design of the internal software architecture. Extended scenarios--realistic composites of multiple use cases--are better suited for guiding inspections and for generating test cases.

Despite the differences and different agendas, a consensus of sorts seems to be emerging regarding the overall advantages of abstraction and purpose-orientation in use cases, and this is reflected in the work of Hermann Kaindl in Austria, Ian Graham in the U.K., and, of course, Alistair Cockburn, in the U.S. His forthcoming book, Writing Effective Use Cases [Addison-Wesley, in press], makes a strong case for "getting the GUI out" of use cases, making them more abstract and technology free. And Jacobson's latest work on the unified process makes explicit reference to the advantages of essential use cases and abstract modeling for user interface design.

Are we likely to see any CASE tools supporting your notation for Use Case Maps and other aspects of EUC modeling anytime soon?

We hope so. This is a major issue, especially when it comes to large-scale projects or work done within ISO 9001 compliant organizations. It is all but impossible to manage the complexity of a design involving 342 use cases with nothing but paper and Post-it notes. You need integrated software tool support. And requirements tracing can become a herculean process when some models are on-line in a CASE tool and others are on flipchart paper.

We remain cautiously optimistic, and there are several efforts in various early stages. Jason Elliot Robbins has expressed an interest in extending the open-source ArgoUML into ArgoUCD, and one of our clients has an internally created tool that may be released as shareware. However, as to the major players, particularly Rational, although we have repeatedly offered to help with defining usage-centered design extensions and designing tool-support, nothing has come of it.

I am not very sanguine about anything coming out of OMG or some other formally constituted group, at least not in the near term. In many ways, the acceptance of essential use cases--along with user role models and abstract prototyping--as standards of good practice, which is spreading rapidly at the grass-roots level, is probably more important in the long run.

The real impetus has to come from the people who are doing the work, from our clients and others who have adopted usage-centered design as the basis of their development process. We are, in fact, currently in the process of organizing a working group and looking for corporate sponsorship for a series of meetings precisely to address the issues of notation, tool support, and the interface between usage-centered design and UML/UP.

As to methodologists, Nuno Nunes, developer of the WISDOM "light-weight" method, has incorporated essential use cases, and Mark van Harmelen employs some of the concepts in his IDIOM method. Much of the spectrum of approaches are covered in van Harmelen's forthcoming book, Objects, Users, and Interfaces: Object Modelling and User Interface Design [Addison-Wesley, in press]. We have a chapter in there on structure and style in use case writing that is also available in draft form from our web site.

Software for Use is the book describing the methodology. It has been around for a year or so now. What effect has it had, and how was it received?

Well, it just won the prestigious Jolt Award from Software Development magazine as the best book of 1999. In general, it has been a critical success and a solid seller, particularly within the developer community. It has received somewhat less recognition from the HCI community, which is not entirely surprising, I suppose. I think many in the HCI community regard us as interlopers of a sort. We do occupy an odd middle ground in the professional world. On the one hand, academics and researchers tend to regard our models and methods as lacking in rigor. On the other, hard-nosed developers who just want simple answers or lists of do's and don'ts accuse us of being too theoretical. That said, on the academic side, the book has been used as the text for a full-semester university course and is being applied by an ever growing cadre of professionals. We have been especially impressed by work at Siemens AG, where usage-centered design has been employed in some very large and complicated projects.

Well, of course, uidesign.net got there first, and we appreciated the early recognition. I certainly hope the book lives up to it by making a real difference.

Order Software for Use from Amazon...

How does Usability Engineering fit with Usage Centered Design?

It depends upon what you mean by usability engineering. In lowercase letters, it seems to me that the term ought to mean the engineering of usability, which is a very broad field encompassing any engineering-based approach to usability. But, of course, most people associate the term with the pastiche of "discount engineering" techniques popularized under that term by Jakob Nielsen.

Like Nielsen's discount approaches, usage-centered design places a strong emphasis on cost-effectiveness, on doing what is necessary but no more. However, we place a lot less emphasis on testing. We see usability inspections and testing to be useful components of the overall process, but rely more heavily on good processes to produce designs that are "almost right" even before usability testing.

Nielsen's new book on Web usability highlights the relative lack of method underlying "usability engineering." It's an excellent compendium of "good" and "bad" examples, but like the Web itself, the book is somewhat chaotic and redundant. One is left both a little overwhelmed and somewhat unsure about where to start and what to do next in designing the next Web site.

Tell us about your training courses and other teaching sessions.

Training is at the very core of what we do. Even when we take the lead or collaborate in a user interface design project, we always try to incorporate some form of skills and knowledge transfer. As consultants, we see it as our job to work ourselves out of a job.

Perhaps one of the more unusual aspects of our teaching is that we do not have standard, off-the shelf courses, but instead custom-tailor each training to the needs of the individual client. Recently, we started also offering seminars to the professional public . These are based on some of our most successful in-house training programs created for major clients like Siemens AG and Nortel Networks. Although the market seems to favor briefer offerings, we prefer a 4-5 day format that gives time to really learn and apply the techniques.

The truth is that, at heart, both Lucy and I are teachers who love teaching. Throughout my professional life, I have always tried to maintain a mix of doing and teaching, of learning and applying. The best teachers are people who not only can do something themselves, but know how it is they do it and how to convey that to others. It's a challenging calling.

I know about your interest in this area. We and our clients have used usage-centered design for a tremendous range of software, Web-based applications, and other products--everything from banking applications to e-commerce Web sites, from industrial automation controls to hand-held remotes. It would not be accurate to say that it is the same in every area of application, but the same basic methods and models apply.

In working with clients, we find that problems most commonly arise when concrete implementation details enter in too soon and contaminate the essential use cases. Interaction scenarios for a desktop application may be very different from the equivalent scenarios for a WAP-based implementation accessed through a Web-enabled cell phone, but both are covered by the appropriate technology-free essential use cases based on user intentions. This highlights the fact that, for different implementation technologies, the differences lie in the translation from essential use cases through an abstract prototype and into an implementation model--the actual visual and interaction design.

In our own work, we design for specialized implementation environments by first designing an abstract prototype that ignores implementation restrictions (such as small screen size, limited buttons, etc.) and then adapting the abstract design to the physical constraints. In our experience, this keeps us from becoming trapped by technology assumptions and makes it easier to think "outside the box" in finding innovative ways to use the technology.

So, the approach varies primarily in the end-game. Interaction contexts may have to be simplified and split up to accommodate to tiny screens, and instead of toolbars the designer may be laying out softkeys. However, the objective remains one of supplying the capability needed by users to carry out their intentions as simply and efficiently as possible.

We need to resist thinking of new technologies as solutions to usability problems, rather than recognizing them as problems in themselves that must be understood and mastered. Remember when graphical user interfaces were heralded as the solution for making computers easier to use? But, of course, it simply wasn't true; it always depends on the quality of the design. If anything, every new technology is more likely to complicate the issues facing the designer rather than to simplify them. In every design class we teach, there are always technophiles who propose to "solve" some problem with voice-response technology, for instance, without thinking through the design issues and consequences.

The biggest challenges, however, are not technical or design issues but organizational ones: How do we balance and integrate marketing and development interests? How do we manage the "art" and the "engineering" of user interface design? How do we carry out usability assurance and keep designs from being compromised and corrupted as they are implemented and then revised? How do we manage the complexity of ever larger systems and applications? How do we achieve quality in radically reduced delivery and deployment cycles? How do we help staff find creative freedom within disciplined engineering?

"You can do it."

I have been lucky to have worked with some brilliant visual and interaction designers, and I have been told that I am not too bad myself. Although not everyone can be brilliant, user interface design is not rocket science. With the right conceptual tools, almost any reasonably competent and intelligent professional who is willing to think and work systematically can learn how to make basically sound usability decisions and produce successful designs.