is your monthly e-Newsletter from
Effective Engineering Consulting Services
If you would like to receive Effective Engineering e-newsletters as they
are published, please send an email to
email@example.com, and we
will add you to our distribution list. Comments and suggestions are
welcome and encouraged!
How Do I Get This D@#% Thing To Work!
By Tom Dennis –
President, Effective Engineering [firstname.lastname@example.org]
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
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
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
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
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