Not only can software development projects take longer than projected, 31% are cancelled before a usable product is produced [122]. Consider the following example:
- Financial services organization scraps a custom-developed application just before implementation when quality assurance testing found a fatal flaw in how data could be entered. The application was never implemented because it was too late to change the underlying structure. UX requirements and early prototype testing could have prevented this failure [34].
US courts require that manufacturers “design for reasonable use and misuse” so the risk of litigation must be managed, especially since legal costs can easily escalate into the millions of dollars. The use of a formal, professional UXE process mitigates legal risk in two ways: (1) it increases product safety and therefore reduces legitimate claims; (2) it creates a strong, defensible legal position that acts as a deterrent to fallacious litigation [77]. Consider the unfortunate legal consequences of not using UXE methods:
- American Airlines sues for software project failure. American Airlines sued Budget Rent-A-Car, Marriott Corporation, and Hilton Hotels after a $165 million car rental and hotel reservation project collapsed in chaos. Causes included “an incomplete statement of requirements, lack of user involvement, and constant changing of requirements and specifications,” all issues that could have been addressed with UXE methods. The case was settled out of court [122].
Now that we have considered why to use UXE methods, we will consider when to use it.