My Photo

Recent Comments

« Lower Power - It’s all In the Architecture... | Main | In Pursuit of Efficient Lighting »

August 24, 2009

The Energy Loss of Poor User Interface Designs

Bookmark and Share

IStock_000001511231XSmall I was fueling my car the other day and the pump I was using had one of the worst user interface designs I have ever come across (the brand of pump will remain nameless... but you know who you are).  As I struggled with the poor response time, lack of feedback and just overall bad programming (and this was a simple fuel pump) it made me think... what energy is lost due to users taking extra time using a system with a poor UI design?

I’m sure you know what I mean... most software is delivered with very little user testing.  Of course the designer knows how to use it, but the real test is someone with absolutely no knowledge of the software.  How fast can you use it and get the information you need.  I see this in web designs and other information server applications.  If I have to drill... and drill... and drill... to get to the level I need, I go crazy - especially if I made a bad choice somewhere along the way.  It’s like the old style "wizard" help dialogs. It’s when you get to the end, and it tells you that the software is about to do unnatural things to your data and asks you if you are sure you want to use the original file... is when you realize that twenty steps back you should have specified a new file name!  That’s what I’m talking about. 

Or what about unresponsive code - oh, this is really high on my list of bad software behavior.  If I have to wait for a task to complete before starting another one (especially if they are unrelated), then I start counting the seconds like I’m in prison.  Some software engineers didn’t get the memo that we’re in the 21st century and multi-threading applications are not some lab curiosity!  Or how about the lack of user feed-back... when pushing buttons on some piece of equipment yields nothing in return?  Is the equipment not working? Is the equipment busy doing something else?  Is the button broken?  We just don’t know, but the time it takes to complete whatever task I’m doing certainly increases.

Ok, so much for the rant.  But what amount of energy is lost if any?  Something certainly must be lost? Let’s examine a fictitious, but real-world example - an ATM or Automatic Teller Machine - something most everyone is familiar with.  The ATM has an LCD touch screen and the unit sleeps when no one is around to conserve energy.  Only when someone walks up to it (motion sensing) does the LCD and backlight come on and the processor wake up. 

In this thought experiment, two revisions of software were released - revision A which has UI issues and revision B which was revised to improve the UI.  The only difference between the two releases is the user interface - everything else is the same.  The ATM is in a high traffic area (of course) so that it generates the most revenue for the bank through access fees.  Revision A lacks the "beep" for user feed-back, and uses one thread for all the functions. Revision B has a "beep" when the screen is touched and is multi-threaded so the UI is independent from other activity.

Input speed is slower for revision A due to the single thread and users may think they have not entered their PIN correctly due to the lack of audible (or tactile) feed-back causing them to touch twice.  Revision B has a thread dedicated to the UI, so the "beep" and character representation for the touch is almost instantaneous.  I would imagine that 50% of the time, revision A will cause an incorrect entry of the PIN - at least during the first attempt.  The total time delay would be roughly an additional 10 seconds.  The next hurdle would be entering the amount for deposits or withdrawals - probably 90% of the usage of the machine.  Assume the same 10 second error recovery time when an error is made. Using these simple estimates and assuming and average of 30 users per hour, table 1 shows the total run time the systems are up (not sleeping) for each revision (assuming only withdrawals and deposits).

Table 1 – Software revision unit run time comparison

Rev A time (sec)

Rev B time (sec)

PIN entry

(7 + (10 * 0.5)) * 30 = 360

5 * 30 = 150

Transaction selection

6 * 30 = 180

4 * 30 = 120

Amount Entry

(10 + (10 * 0.5)) * 30 = 450

8 * 30 = 240

Communications Time

15 * 30 = 450

15 * 30 = 450

Accept / Dispense Time

5 * 30 = 150

5 * 30 = 150


1590 (26.5 minutes)

1110 (18.5 minutes)

So, looking at this hypothetical ATM, we see that in every hour, a bad user interface which causes errors in entry may increase the run time by 8 minutes.  If the unit is sleeping the remainder of the hour (simplified), then every hour the run time increases by 8 minutes or 3.2 hours per day (assuming an average of 30 users per hour for 24 hours).  A more accurate model would take into account usage and sleep times for the entire day, but it is obvious that a poor UI will increase the run time of the machine. 

In this model, If the ATM consumes 200 watts in run mode and 20 watts in stand-by, the energy consumption increases by 576 watt-hrs per day, or an additional 210.4 kW-hrs per year simply due to errors caused by the poor user interface… makes you think about the next time you start writing code, doesn’t it? Till next time...


TrackBack URL for this entry:

Listed below are links to weblogs that reference The Energy Loss of Poor User Interface Designs:


Feed You can follow this conversation by subscribing to the comment feed for this post.

The comments to this entry are closed.