upa - home page JUS - Journal of usability studies
An international peer-reviewed journal

User Experience Design: The Evolution of a Multi-Disciplinary Approach

Deborah J. Mayhew

Journal of Usability Studies, Volume 3, Issue 3, May 2008, pp. 99-102

Article Contents


A Recent and Brief History of Software Usability Engineering

The following sections present the history of software usability engineering of the 1990's and 2000's.

The 90's

By the early 90's, development role specialization and standardized development methodologies had become common and accepted in the software development industry, especially by newcomers to the industry who had no history of broader roles and more freedom to manage themselves and their projects. On the other hand, being a usability professional in a software development organization was still not routinely accepted and continued to be a tough role to play, not particularly welcomed by developers and under-supported by upper management. And, while the software industry had by this time adopted the notion of standardized development methodologies, usability professionals had not yet found a formal place in these methodologies, and were much like programmers in the early 80's-generalists who did not specialize in any particular usability role (such as user interface designer, usability requirements analyst, usability tester, etc.) and did not have any structured, standard approach to integrating their expertise and work into software development teams and methodologies. History repeats itself.

Then came the dot com boom, starting in the mid to late 90's.

I remember taking on a long term consulting job with a dot com start up about this time. While I was nearly 50 with 25 years of work experience in the software industry, most of the employees in this start up were barely out of school and in their 20's. They were completely free of any negative feelings about their very specialized roles of back-end or front-end programmers with no other responsibilities, because it was all they had ever known. They had no issues at all with the notion that some other kind of specialist would be completely responsible for the user experience design that they would build.

This client company also had a new and emerging type of user experience professional in the mix-the graphic designer. Suddenly traditional usability professionals like myself found themselves in the same position as programmers had 20 years earlier: needing to share responsibility with a new and very different sort of user experience professional, for what they had been entirely responsible for in the past. Not long after that, yet another new specialized user experience role emerged-the information architect.

My book, The Usability Engineering Lifecycle (Morgan Kaufmann Publishers, 1999, http://drdeb.vineyard.net/index2.php?loc=7&nloc=1), was intended to bring the practice of usability engineering more in line with software engineering practices at the time, by outlining a structured and engineering-like methodology for accomplishing good interface design that could be integrated into the underlying software development methodology. Such a standardized methodology was new to the field at that time, and again, represented a change comparable to the change programmers went through 20 years earlier. The Lifecycle approach was also intended to more clearly establish the role of user experience professionals in the development project team. We needed to catch up with the practices in the industry we were operating within.

I remember that initially, learning how to divide up responsibility for user experience design with graphic designers and information architects was an interesting challenge. It was clear to me from the get-go what a powerful combination our separate skill sets could be, but I often found that usability principles came into conflict with graphic design and branding principles, and had to work out ways to arrive at optimal compromises. That entailed them learning my principles and me learning theirs, at least to some extent. I felt I had a good sense of the boundaries between our skill sets and responsibilities at that point, and it was more than clear that we were much more effective as a user experience design team than any of us would have been alone.

Previous | Next