Making the Business Case for Interaction Design

Written by lerble on June 14th, 2006

This is possibly one of the hardest things for me to explain to the people I work for. WHY a design process that includes the usability engineering is so IMPORTANT. Reading the forward to Alan Coopers 2004 edition of “The Inmates are Running the Asylum” has given me some greater insight into why the old ways of creating software/web applications are still prevalent today.

Cooper talks about how it is the ‘old economy’ thinking that equates programmers in the same way that it classifies variable costs. In business, there are two strategies for increasing profits: reduce costs, or increase revenues. In the old economy of manufacturing physical goods, reducing variable costs became the best way to increase profits. If I can build widget A with cheaper materials and less labor, then I can produce it at a lower cost per widget. Building and distributing software/web applications is a completely different animal than creating a physical good. Increasing revenues through higher sales is the preferred way to increase profits because the cost of distributing software after it is design is, for all practical purposes, zero. Sure there is support to provide, packaging to design, salesman to hire, etc. But, the actual good itself, the code, does no incur further costs as sales increase. If you make widget A out of steal, widget A will always incur a cost for the amount of steel needed to create it. Code does not incur cost for each time it is reproduced. Therefore, it is desirable to SELL MORE to increase revenue, rather than reduce the variable costs.

This is an important distinction to make. Since old economy thinking strives to reduce variable costs, it tends to group development resources into these variable costs. Since you cannot create software/web applications without programmers, they are often left to design the interfaces and interactions as well. This is where the danger of old economic thinking comes in. Would a building project, needing to cut costs, cut out the architect and leave the building design to the people swinging the hammers and laying the pipes for the plumbing? This would be recipe for disaster. In fact, I would be surprised if a building could be built this way at all. Yet, software IS often built in this way. Leaving out the Information Architect, Interaction Designer, or what ever you want to call it, is like building a building with out the Architect– a recipe for disaster in anybody’s book.

I have only read the forward for this book so far, but I am excited to read the rest so that I can arm myself with the knowledge the can change the minds of the business leaders in my organization.

Comments are closed.