Last night I heard William Gribbons, Director of the graduate program in Human Factors and Information Design at Bentley University, speak at a Boston Society for Information Management meeting on the subject "Usability and the User Experience: Reducing Life-Cycle Costs for IT Projects." To this gathering of IT professionals, Gribbons made the case that poor usability and bad design can be responsible for costs throughout the organization, and discussed how the costs can be reduced. Better design of systems can, for example, reduce (or eliminate) training and support costs, and even reduce employee turnover.
Gribbons emphasized a three-part approach to requirements gathering and design, which I found to be conceptually similar to the three-part framework I use when discussing SharePoint implementations with my clients (based on the Doblin Group's Innovation Framework). Gribbons's three pillars of System Design are user requirements, business requirements, and technical requirements. These align nicely with the What's Possible / What's Viable / What's Desirable categories that are typically the triple constraints of the SharePoint systems I've implemented. I've reproduced the graphic I use, below, and added Gribbons's terminology.
My clients have spanned the range of focusing only on the business (to the exclusion of user needs (and future adoption)), to focusing only on the out-of-box product features (without considering places where customizations might be desirable and fully supported by business needs), to focusing chiefly on the users (without a lot of thought given to business alignment and return on investment). I totally agree with Dr. Gribbons that all three types of requirements must be represented if you're going to get the system design right, and that getting it right can significantly reduce all the costs associated with frustration, low productivity, failed projects, lost innovation opportunities, and the need for support and training.
As a side note, my favorite quote of the evening came when Dr. Gribbons was talking about users' affective experiences of a system - e.g. trust, motivation, anxiety, and pleasure. "Could we bring a little pleasure to work? I think we could."
I think so too. More about this in my next post on Emotional Design.