Effective Engineering 
                Consulting Services
   
                                           "Helping Engineering Excel!"

Home
Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
e-Newsletters
Our People
Contact Us
Photos

 

Back to e-Newsletter Archives:

 Effective Engineering e-Newsletter – 12/8/2005

This is your monthly e-Newsletter from
Effective Engineering Consulting Services (www.effectiveeng.com).  If you would like to receive Effective Engineering e-newsletters as they are published, please send an email to e-newsletter@effectiveeng.com, and we will add you to our distribution list.  Comments and suggestions are welcome and encouraged!


eN-051208:


The Inmates Are Running The Asylum!
[1]
 
By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]


What do you get when you cross a computer with an alarm clock?  With a camera?  With a car?  With anything else?  The answer, according to Alan Cooper in his excellent book, “The Inmates Are Running The Asylum[1], is that you get a computer!  Alan is an interaction designer, and has observed that, as virtually everything is being equipped with computer technology, those who develop these products have often abdicated their responsibility to make these products easy to use.  They may think they’re making their products easy to use, but they’re really making products that are easy to use for others like them. 

It is the engineers who are designing these products and running the show.  In Alan’s terms, we are letting the inmates run the asylum!  The problem is that engineers are designing products in ways that make it easier for them to develop, using approaches that make sense to them and others like them.  However, the people who use these products are generally not engineers, and engineers are different from other people.  What makes sense to engineers often does not make sense to others, and what makes things easier for engineers to develop products often makes those products more difficult for non-engineers to understand and use.  Furthermore, the fact that a particular approach makes it easier for engineers to develop products is generally of no interest to an end user. 

End users quite simply do not want to be made to feel stupid, and just want to be able to use a product easily and intuitively.  They would really love to be delighted with computer-based products, but far too often have to settle for being able to muddle along with them, to tolerate them, or in some cases to actively hate them but have no choice but to use them.

This craft of interaction design is new and unfamiliar to software developers and many others.  When programmers do design, they tend to think of themselves as users, but this does not reflect the reality of their users.  Programmers are often willing to trade simplicity for control, and success for understanding.  They focus on what is possible to the exclusion of what is probable while everyday users do just the opposite.  They develop software that forgets, making users reconfigure to their workflow every time it runs.  They develop software that doesn’t focus on what the user really wants it to do.  They develop software that doesn’t give the user enough relevant information, such that when it fails the user has no idea of why it failed.  They develop software that is inflexible and always works the same way even when humans would adapt the work process in the same situation.  They develop software that doesn’t help its users; when it fails, error messages should be accurate and helpful to the use but often are not.  They develop software that won’t take responsibility; instead of annoying “are you sure?” dialog boxes, software should allow for operations to be undone if the user wasn’t sure.

End users want their products to be easy to interact with.  This is the role of the interaction designer, and their role is distinctly different from that of the engineer.  The key to solving the problem of making products easy to use is to do the interaction design before the programming.  Interaction designers focus on how products behave, communicate, or inform.  They focus on the way end users see and interact with software-based products.  Interaction designers first think conceptually, then in terms of behavior, and last in terms of interface.  A really well designed product will create fierce loyalty in customers.  It will create desirability.  Desires are not needs; they have an even more profound effect on people’s behavior than needs.  Many of Apple’s products are strong examples; think iPod, iMac, PowerBook.

The way interaction designers often work is to create personas.  A persona is a precise description of the user and what he/she wishes to accomplish.  It is not a real person, but the persona must be well-defined and believable as a person.  A persona is sufficiently defined when its needs are clearly unique.  The purpose of this is to make it possible for the designer to design for that persona instead of for himself, to truly get into the mind of the persona.  Multiple personas are typically created, and after careful review, one primary persona is identified and that is the persona to be designed for.  Personas end feature debates.  A feature might be useful for a number of users, but if it is not desired by the primary persona, then it need not be included, or at least should not interfere with the operations of the primary persona.

Trying to please different user groups who have contradictory needs by compromising never works; in these cases multiple interfaces should be designed. Features that are not needed by the primary persona, but are desirable for other lesser personas may be appropriate to include, but it may take some effort on the part of that lesser persona that may not even be evident to the primary persona.  Users who want/need these special capabilities are generally willing to put effort into getting to these capabilities because they feel it is a fair exchange for the reward of having the capabilities.

The essence of good interaction design is to devise interactions that let users achieve their practical goals without violating their personal goals (i.e. the need not to feel stupid).  It is such goals that should be designed for.  By defining persona’s goals, the interaction design of the persona with the product can be fleshed out and defined.  The primary focus should be on daily-use and necessary-use scenarios.  Necessary-use scenarios are those that the user must be able to do, but are only done infrequently or under special circumstances.  It is the daily-use interactions that should be as polished as possible.  Interfaces can often be simplified by placing daily-use controls and data prominently and moving all others to secondary locations, out of sight.  Edge case scenarios (rare use) can be largely ignored in interaction design; they must be implemented, but should receive little emphasis in the interaction design phase.  No matter how “cool” a user interface is, less of it is almost always better.


Interaction design
teams should not include programmers or managers; they should have specific training in interaction design.  Such teams should be kept small, with no more than 2-3 designers per product.  They should be kept insulated from managers and programmers while they are researching and designing personas.


There is so much more to be explored in interaction design.  This e-Newsletter barely scratches the surface.  The key is that end users want products that they truly love, but they have been conditioned to expect much less.  If you want to succeed beyond your wildest expectations, you must design products to absolutely delight your customers.  To do this properly requires a different approach that is not driven by engineering.  It must be driven by designing for the end user.  That takes a different approach, to really concentrate on the interactions end users will have with your product and make that design truly outstanding.

__________
[1] Alan Cooper, “The Inmates Are Running The Asylum”, Copyright © 2004, Sams Publishing.


Copyright © 2005 
Effective Engineering Consulting Services, All Rights Reserved

Back to e-Newsletter Archives:

 

   

Society of Professional Consultants

  

Copyright © 2002-2013 Effective Engineering Consulting Services, All Rights Reserved