Wolfgang Maehr

This is an essay I wrote for a course in user centered design. It can also be downloaded as PDF here. Comments are welcome!

___
Software industry is not in its infant years anymore. While Apple is soon its thirtieth anniversary on April 1, dinosaurs like IBM or HP have been in the business even longer. From cost/revenue side the computer industry is no small fish anymore. In the United States every year more than $250 billion are spent on IT application development in approximately 175000 projects [Standish, 1995]. Still, the industry seems to have teething problems with these projects. The Standish Group [1995] argued, that over 30% of such projects will have been cancelled and around half of the projects will have cost 180% or more of their original estimates 1995.

Since then, things have changed. For example has the ISO 13407 [1997] been developed, emphasising user centred design activities throughout the life cycle of interactive computer-based systems. Likewise, the Rational Unified Process (RUP) has been developed [Kruchten, 2000], leading to a risk reduction due to the iterative process [Kroll and Royce, 2005]. This by-now industry standard [Webaliza, 2006] promises something, which might have been a reason for its success [RUP, 2006]:
“Out-of-the-box delivery processes to provide the project manager with a quick starting point for planning and initiating a project. A delivery process will provide an initial project template, identify what type milestones to have in the project, what work products to delivered by each milestone, and what resources are needed for each phase.”

This out-of-the box solution sounds rather tempting, however, has the CHAOS Report also shown that the biggest success factor of a project lied within user involvement and the ultimate reasons for project cancellation were incomplete requirements and lack of user involvement [Standish, 1995]. RUP on the other hand is no real remedy for these pains [cp. Gulliksen et al., 2003] since we can clearly see that RUP does not really give space for Usability or Design and at the beginning, but rather conducts user/usability tests late in the iterations; better than the waterfall model, but still too late [cp. Larman, 2001, page 33ff.]. Therefore it is important to apply UCD thinking upon the RUP development process. This is well possible since RUP focusses on project management (see the quote above) and UCD is more a way of thinking, as Gulliksen proves by his twelve key principles [Gulliksen et al., 2003].

The advantages of this adaptation can be deducted from the CHAOS Report: The user is stronger involved in the process – to me more accurate, the user is even a co-designer [Gulliksen et al., 2003]. This should – according to the CHAOS Report – lead to more successful projects and less time and money wasted. Further more, Kujala [2003] argues that users were more satisfied and accepted the design more, which is a logical consequence from the fact that the users get the feeling of being contributing to the system about to be used, instead of only have it imposed on from (the management from) above. For the developing company one can summarise [Kujala, 2003] that also costs for developing system features the user did not want or could not use were lowered since the user requirements were more accurate.

Since the advantages are clear now, one might ask why do companies not jump on it like a pack of famished wolves? The problem is that the adaptation from a plain RUP process to a combined user-centered, unified design process (UCUDP) is not a simple one and has obstacles in many different places. The first – and maybe the toughest one – is that UCD is a mind-set and has no agreed upon definition [cp. Karat, 1996], which leads to a concept without a clear meaning [Gulliksen et al., 2003]. If we compare this to the RUP-quote from above [RUP, 2006], which promises an out-of-the-box solution, the answer to the question “how should my risk-free development process look like?” is pretty clear; it plays no role here that RUP isn’t a silver bullet either, at least it has a company backing. The second, tightly connected problem, is that UCD requires that all members of a project team must understand and apply user centred thinking [Gulliksen, 2003], a change of mind, that can neither be done within an instant, nor by a single usability expert in the development process. This change needs time, money and figures to convince the management. Especially since RUP has a strong lobby of rational (sic.) companies behind it that promote this one-size-fits-all picture, something that does not apply to UCD [Gulliksen, 2003]. A third obstacle named by Kujala [2003] it to access the users. To identify and accessing them might not be the only problem for large B2B projects, but also for small projects in small companies. Further more, opening a product to user access might this not always be wanted in case of new and strategical products/features, that should be kept confidential. Last but not least, time is always scarce in projects and it can be hard to convince people to devote time and money to an ‘up-front investment tied to uncertain returns’ [McCoy, 2002, p. 285].

To conclude one can say that it is possible and reasonable to create a combined UCUDP (user-centered unified design process), where the usability design is a part of the overall architecture in RUP [Göransson et al., 2003]. It might only need some time, convincing and maybe another CHAOS Report until that is done.

• J. Gulliksen, B. Göransson, I. Boivie et al., 2003. Key Principles for User-centred System Design, in Behaviour & Information Technology, Nov-Dec, Vol. 22, No. 6, pages 397-409.
• B. Göransson, J. Gulliksen, I. Boivie, 2003. The Usability Design Process — Integrating User-Centred Systems Design in the Software Development Process, in Software Process: Improvements and Practice (SPIP), Vol.8, No. 2, Wiley & Sons.
• ISO 13407, 1999. Human-centred design process for interactive systems. Available (2006-03-27): http://www.usabilitynet.org/tools/13407stds.htm
• J. Karat, 1996. User Centred Design: Quality or Quackery?, in the ACM/SIGCHI magazine, Interactions Jul-Aug.
• P. Kroll and W. Royce, 2005. Key Principles for Business-driven Development. Available (2006-03-27): http://www-128.ibm.com/developerworks/rational/library/oct05/kroll/index.html
• P. Kruchten, 2000. The Rational Unified Process—An Introduction. 2nd edition. Reading, MA.: Addison-Wesley.
• S. Kujala, 2003. User Involvement: A Review of the Benefits and Challenges, in Behaviour & Information Technology, Jan-Feb, Vol. 22, No. 1, pages 1-16.
• C. Larman, 2001. Applying UML and Patterns. 2nd edition. Prentice Hall.
• T. McCoy, 2002. Usability: Who Cares? In Usability Gaining a Competitive Edge, J. Hammond, T. Gross, J. Wesson (eds). Kluwer Academic Publishers: 283-294; IFIP World Computer Congress 2002, Montreal, Canada.
• Standish Group, 1995. The CHAOS Report. Avaliable (2006-03-27): http://www.projectsmart.co.uk/docs/chaos_report.pdf
• Webaliza, 2006. User-centred Design – An Iterative Process. Available (2006-03-27): http://www.webaliza.com/methodology/iterative_process.html