Making Things Easy Is Not an Add On

Making Things Easy Is Not an Add On

 

I am a busy guy.  This means I’m not the type of person who likes to spend lots of time eating lunch.  The quicker and easier it is for me to grab lunch the happier I am.  For lunch today,  I decided to get a sandwich.  I discovered that the sandwich shop downstairs allows me to call in my order ahead of time so I can just walk up to the cashier and pay.  There is a special, shorter line for call-in orders.  Further, if paying by credit card, it is one simple swipe and less than seven seconds later you have your receipt and you are out the door.     It is a true model of efficiency.

I am much more likely to be a customer of this establishment in the future because they have made it exceedingly simple for me to get what I want.  I didn’t waste time in line behind people who don’t know what they want nor did I have to wait for something as simple as handing over my money.  This simple yet important principle seems to be lost on so many of us in technology.  As engineers, we are used to dealing with the complex.  We don’t mind jumping through hoops to configure web servers, navigate deep directory structures, or manage the dozens of windows on our desktop.   We seem to forget that not everyone has the same love affair we have with computers.

We tend to think of usability as an afterthought.  We figure that if we got you your sandwich that should be good enough.  Are you still hungry?  No?  Great, requirements met.  It did not matter how we got you there it only mattered that you got there.  This started to change in large part thanks to Apple and Steve Jobs.  The introduction of the iPod and then the iPhone changed the way people talked about creating products.  When I worked at Microsoft, I cannot tell you the number of times the words “iPod” and “iPhone” were said in discussions about design.  It became a running joke in my team and others that no matter what we talked about, we eventually had to tie it back to how great the iPod experience was.   Before this, engineers used to talk about cramming more and more features into a product and did not worry about people were going to access those features.

Ease of use should be a basic product principle, not an afterthought bolted on after all the functionality is complete.  If you are working on a feature, and there is not a clear and intuitive way for your users to access it, you should honestly question whether your user will derive any value from it at all.  Even worse, having even one hard to get at feature can remove the whole usefulness of all the other hard work you put into the product.  To use my analogy further, imagine what I would have thought if I got all the way to the payment portion of my sandwich transaction only to realize I had to wait five more minutes to pay.   The “payment” feature needed to work in concert with “ordering”, “taste”, and the rest to ensure a great overall experience.

We are living in an ever more complex world.  While it is very hard to mask this complexity from your user, it will be an ever increasing differentiator between those who succeed and those who do not.  Not treating ease of use as a first class citizen when it comes to design, requirements, and planning is just handing over victory to your competitors.

 

Comments

  1. Great point Terrence!! If only everyone would adopt this view!

Trackbacks

  1. [...] paradigm from the very beginning and therefore it seems bolted on.  Like I said in my last post, easy is not an add on.  Facebook Groups is not intuitive to use and because it was bolted on later, it seems too [...]

Speak Your Mind

*