Effective Engineering e-Newsletter – 1/5/2006

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-060105:


How Do I Get This D@#% Thing To Work!
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]


You just found the product that looks perfect for your needs.  The information indicates that it has all the features, capabilities, bells, and whistles that you really want.  You buy it, get it home, open it up, make the necessary connections, turn it on, and . . . nothing.  You try a few obvious and some non-obvious things, and (gasp!) even look through the manual (you know how you hate to read the manual), and, again . . .  nothing.  You cry out in lament, “How do I get this d@#% thing to work!”  You frustratingly realize that you have just bought yet another disappointing product from yet another disappointing company.  You resolve that you will never buy another product from this company again!

In the last e-Newsletter (see eN-051208 – The Inmates Are Running The Asylum!), we talked about interaction design and ways to design a user interface that is easy and intuitive to use.  It is a great first step to have help from an interaction designer who can lay out an approach and framework that can make a product easy to use from a user’s perspective.  To turn that interaction design framework into reality that design must be turned into “User Experience Requirements” that the software developers can work with to actually implement the design.  If an interaction designer is directly involved, he/she may be the person to define these requirements.  In many cases, however, an interaction designer is not brought in and it is left to the Product Manager or the software developer or someone else to define the user interface.  Regardless of who does it, “User Experience Requirements” are a critical element of the overall product requirements specification process.

Most companies can do a good job of defining a product’s hardware requirements.  This includes defining the “goesinto’s” and “goesoutof’s” of the product – the physical connections into and out of the product, the knobs, the displays, etc.  It also includes the physical package for the product.  Careful definition of all of this information is absolutely necessary, but is hardly sufficient.  Even from a hardware perspective, this defines what is necessary to connect to or to interact with the product, but says nothing of the actual hardware design needed to implement the functionality of the product.  That is the “secret sauce” that the hardware developers will provide.

Many companies will attempt to similarly define the software requirements, thinking, “Well, we just defined the hardware requirements; now we should define the software requirements.”  But this is really not what is needed.  Just as it is not necessary to define the hardware architecture inside the product, it is not necessary (or even desirable) to define the software architecture in the product requirements documents.  What the software developers really need are “User Experience Requirements”.

So what are “User Experience Requirements”?  Simply put, they are what the user experiences when they begin to interact with the product (and recognize that there may be multiple types of users).  What happens when the user first approaches the product?  What do they see?  What can they do?  Is it a complex and confusing experience or a simple and intuitive experience?  When they take an action, what happens next?  What happens after that?  And so on.  The “User Experience Requirements” should go through every operation the user can experience, and should address what happens when the user gets confused or pushes or clicks on the wrong thing.

Think of them as a storyboard of a movie, where the hero is the user and he/she is interacting with your product.  At each step, one or more actions can occur, and when any action does occur, it can trigger more actions.  Thus a tree structure develops, and the “User Experience Requirements” should walk the user down (and back up) every branch in that tree.

In developing the “User Experience Requirements”, the writer will find surprises will arise that identify actions that may be confusing or frustrating.  The writer should actively work to find these surprises.  It is far better to identify these at the Requirements stage (and define ways to remedy them), than for an actual user to encounter them when the product is released, resulting in frustrations and anger from your customer.

This sounds logical and fairly straightforward.  So why isn’t this the norm?  Why isn’t this done for every product?  
► Because the requirements writers don’t know how or what “User Experience Requirements” really are.
► Because it can be hard to write them. 
► Because it forces the writers to think through every combination of actions and reactions, which can be a very big job depending on the complexity of the product.  
► Because the writers may say they don’t have the time (although they will be forced to make time when problems arise that force corrective actions to be taken). 
► Because they say they’ll leave it to the implementer to do the right thing.  [Indeed, much software creativity comes in the implementation, but you don’t want the software developers to show their creativity in the interface design itself, in the way the user experiences the product. You want a design that makes good sense and is not confusing to the end user, not one that makes sense to software developer, but may make no sense or be confusing to the end user.]

There are myriad reasons why “User Experience Requirements” aren’t often done, but none are really good reasons. Good “User Experience Requirements” can actually save significant time and eliminate problems and mistakes early on.  They can ensure that the interaction design is carried out faithfully.  They can result in products that truly meet their design intent.


How many products do you know where it is clear that the design just wasn’t well thought out?  How many times have you said, “How do I get this d@#% thing to work!”, or “Who was the idiot who designed this d@#% thing!”, or “Get me my money back; I can’t stand this d@#% thing!”  Far too many people experience this every day.  Sometimes they are forced to live with a product like this, and learn to hate it and, by reflection, the company that made it.  By carefully specifying “User Experience Requirements” you can make the product that is the exception.  You can make a product that people simply love and brag about to their friends.


Copyright © 2006  Effective Engineering Consulting Services, All Rights Reserved