Applied Logic Engineering, Inc.

Technology and Management Solutions

User Interface Design : The Problem (Part 1)

Copyright 2009

Kelly Nehowig, Applied Logic Engineering, Inc.

 

Overview

I have been involved with the design and development of software systems for over twenty seven years, going back to the very first consumer products that contained microprocessors.  In those early days, bad user interfaces (UIs) were fairly typical, both in embedded devices and in the early days of PC software.  This was a brand new world that was just beginning to emerge and the emphasis in the design realm usually revolved around functionality and not the corresponding user interface.

However, over a quarter of a century later, it is still too easy to find examples of bad user interfaces in the products that we buy and in the software that we use. 

 

This two-part series will initially discuss what makes for a bad UI and how it typically happens.  The second article will discuss common design issues and how to avoid creating bad UIs in the products in which you are involved.

 

No one sets out to create a bad UI

To my knowledge, no one ever sets out to create a bad user interface.  But they do occur.  In my experience, most bad UIs occur due to one of two issues:

 

No thought is given to the UI until the end of the product design cycle

or

The UI is overdesigned and overly complicated

 

There may be other reasons as well, but most of the situations I have seen can be placed in one or the other category above.

 

Lack of design foresight

In the first example, I have seen designs (particularly in embedded systems projects) where the first consideration to the UI is given well after the hardware is designed and is operational.  The UI is not a primary consideration and, like back in the old days, functionality is king.  In these cases, there are usually a few buttons and maybe a few Light Emitting Diodes (LEDs) that are set aside as the basis for the UI, but the details “will be figured out later”.  “Later” usually comes very late in the design cycle – typically the hardware may be “set” – printed circuit boards are made, plastic enclosures are tooled, and there is tremendous resistance to changing anything from a hardware standpoint at that stage.

 

So the firmware designer is left to do the best that he or she can do given the constraints that are already designed in.  The result is typically a klunky UI that is almost impossible to use and is as far away from intuitive as one can be.  Think of some examples from your past (or maybe even your present) – a clock radio in which you had to hold one button while pressing another repeatedly to change the time.  Or a car sound system in which it is impossible to figure out how to set the bass level.  Or everyone’s favorite – the flashing “12:00” on the front of the old VCR because no one could figure out how to set the correct time of day.  Most of these bad UIs can be attributed to lack of foresight from the part of the product designers.

 

Overly complicated UI design

The second factor regarding user interfaces is becoming more common, in my opinion.  The products we buy everyday have an ever-growing set of features that are typically used to differentiate them from the competition.  While I can understand the need to “one-up” your competitor, many products suffer from becoming overly complicated due to the additional functions or features included, which typically results in -- you guessed it  -- bad user interfaces.

 

Here is a great example – two summers ago, my wife and I had done some landscaping at our home that required regular irrigation.  A simple way to automate the daily watering of the flower baskets and other plantings seemed to be the solution, so I installed small watering lines to the plants and ran it all back to a watering spigot on the side of the house.  A trip to the local home improvement store provided (what I thought) to be the perfect controller solution – a simple, $40 embedded device that connected between the spigot and the main irrigation hose that turned the water on each day for a preset number of minutes.

 

Here is a picture of the display portion of the device (with the manufacturer’s name covered by my hand).

 

At first glance, you may begin to see some of the design problems I was about to experience.  First, the display is much too small for anyone with “over 40 year old” eyes.  It is almost impossible to read.  Second, the angle of the display meant that, once it was in place on the water spigot, it requires that one get on their hands and knees on the ground level to see it at all.  Clearly, no thought was given to the people that would use this device as far as practicality goes.  A slightly larger display and one that was set at the proper angle once it was in the operating position would have gone a long way to fixing these problems at little to no cost to the product.

 

Next, there was a confusing array of terms and icons that made up the user interface.  Remember, all I needed was the ability to set a time each day that the water would turn on and the ability to set the number of minutes that the water should flow.  That’s it.  Unfortunately,  I was confronted by a bunch of options that I did not care about (i.e. something called “automatic”, “manual”, “delay”, and “off”, something called CYCLE A, B, C, etc.).  Pressing the designated buttons on the UI did little to explain what was going on nor how to set up the device.

 

So I dug out the user’s guide and started reading.  I finally found the section labeled “Set Duration and Start Time for Watering”.  Aha!  Now we’re getting somewhere, I thought.  That is until I read the section below (quoted verbatim out of the User’s Guide):

 

Push MODE button to select SET.  The word SET will blink to indicate that it is selected.

Push CONFIRM button to begin the set mode.

Push CONFIRM button two more times and NEXT button once to move past the time/day setting and the watering days.  MINS TO RUN will show with two digits or “—“ flashing.

 

Folks, I am not making this stuff up.  That is exactly what the instructions said.

 

Long story short, by carefully following the instructions, I was (after a few miscues) able to get my plants watered.  However, after taking the system down for the winter months, I was then confronted with having to reprogram this device again the next summer  – and of course I had long since lost the user’s guide.  I went to the manufacturer’s website and requested a new copy of the user’s guide, which they kindly supplied to me.  In addition, the tech that emailed it to me asked if I would be interested in the video that shows how to properly set up and use this company’s product.

 

It was the best laugh I had had in a very long time.  Clearly, this company had experienced a number of customers that had either complained about this product and/or returned it because they were unable to get it to work correctly.  So instead of fixing the problem (i.e. simplifying the setup by creating a better UI for this $40 consumer product), they had gone to the expense of producing and distributing a video to try to appease their customers.

 

While it may have been too late for this particular product, I would contend that spending more time thinking about the real features that people want and then creating a simple, straightforward UI would have benefited the manufacturer in fewer product returns, less technical support costs, no need to bear the expense of producing a setup video, and ultimately much happier customers.  Including me.

 

In the next article in this series, I will discuss some common problems with conventional user interface design and make suggestions that will dramatically improve the way that your customer interacts with your product.

______________________________________________

Kelly Nehowig is President/CTO of Applied Logic Engineering, Inc., a Minneapolis-based consulting company specializing in software development products and services.  A 27-year veteran of the software industry, he has worked with companies from startups to large corporate clients.  Kelly holds a MS degree in Software Engineering from the University of St. Thomas and a BS degree in Electronic Engineering from Minnesota State University – Mankato.  He can be reached at kellyn@appliedlogiceng.com.