Examining: “Easy to use”
What do a fruit peeler, iPod and fighter jet have in common?
At the beginning of a product project (new website, app etc) you inevitably hear this line:
“…and we want it to be easy to use.”
Everyone nods, the meeting moves on, no one ever asks how easy.
This is odd because if someone says:
“…we want to charge a fee for that.”
Someone will immediately ask: “How much? How will they pay?”
There’s a number of options if you want to make something easier to use.
Option 1: Improve the interface
Make the interface (UX/UI) better. Better grouping, labelling, element expression, layout, modalities, form factors and other HCD principles. This is a skill in itself, but basically it’s presenting the same functions/information in a better way.
Option 2: Improve the technology
Using new technology can give you the option of making things go faster, bigger, lighter, automatically or enable the user operate at a higher level of abstraction.
These two approaches have limits. What about when you need more?
Going deeper
Making your product five times easier to use is a huge competitive advantage.
Improvements of this order of magnitude require choices about the very foundations of what your product is and isn’t.
But before I get into that, lets take a step back to the beginning of that project.
Every digital project ever…
Digital projects usually revolve around features, so your requirements always end up looking like this:
- Feature a
- Feature b
- Feature c
- Feature …
- Feature z
- Make sure features are easy to use
That list can be reduced to three “meta requirements”:
- Let people do some things
- Let people do those things efficiently and precisely
- Let people learn how to do those things quickly
These are things you have control over, “product elements” that can be tuned to make your product easier to use. Which gives us…
Option 3: Improve the products feature balance
I’ve named each of these elements:
Functionality
How many things does the product really need to do?
Finesse
How much efficiency and precision is needed when doing the things?
Learnability
How much time or ability does the user have to learn these things?
Tradeoff
The key is finding the right balance.
The rules of this tradeoff are:
- Changing one element always impacts the other two somehow.
- At most, you can max two out of three. You can’t have it all.
- But you can still use technology and interface improvements in combination with tuning your product balance.
Imagine each of the boxes bellow control the same system. Which one is easier to use?
The answer is entirely dependent on who your audience is.
Removing buttons means there’s less to learn. Adding sliders gives you more control, but more to learn. Perhaps your audience is time poor or has diminished mental capacity informing what they can learn. You may be forced to make make balancing decisions if either function, finesse or learnability is non-negotiable.
For most consumer products this can be viewed as a battle between mass adoption, power users and product scope.
Examples
Lets look at some real works examples.
Example 1: A fruit peeler
- Number of functions: 1 (Low)
- Learnability: Seconds
- Finesse: Acceptable (you get what you get, but usually don’t need any more than that)
Imagine adding more functions (like a flip-out knife and an apple corer) to this fruit peeler.
Suddenly it’s ease of use plummets as these extras get in the way of it’s primary purpose.
While this may seem like a silly example, the humble fruit peeler shows us a product with 1 function and a tiny learning time. This leaves the finesse to play with, so it’s not surprising that the ease of use comes down to the particulars of the handle and ergonomics that give the user control.
Example 2: iPod (Generation 1)
- Number of functions: About 10–15 primary functions using 6 physical inputs. (Moderate)
- Learnability: A few minutes.
- Finesse: Just enough where it counted.
The first iPod is a master class in product balance combined with interface and technology choices that boosted ease of use.
As few buttons as possible, compared to other MP3 players at the time, meaning less to learn. You won’t find physical buttons for repeat, random, bass boost etc.
The scroll wheel provided a high level of finesse for song and volume selection using a mechanic that was worth learning.
Technology improvements included pairing it with iTunes which reduced the onus on users managing their music, transcoding audio files (this was a thing). Firewire made transfers quicker and a bigger hard drive made them less required.
Interestingly, its the addition of the large hard drive and ability to have thousands of songs (more function) that necessitated something like the scroll wheel (higher finesse) to keep it easy to use. You still see the equivalent level of finesse in todays iPhone (with finger drag scrolling) because the need is still there.
The first iPod is about as good as it gets. I mean that literally. The form design here is so optimised for it’s product balance that it would hardly accommodate an extra button or function set without needing a complete overhaul. How awkward and out of place would an extra button look if it had been added last minute?
The easier you make something for your target audience the less easier it may be for those outside that audience. Which brings me to…
Example 3: EF2000 Eurofighter Typhoon Fighter Jet
- Number of functions: 1000’s
- Learnability: Years
- Finesse: Extreme level of control and efficiency
This is product balance ‘taken to the max’. Allowing the pilot to do lots of things and do them in a very efficient and fine-grained way is non-negotiable.
High finesse keeps all those functions easy to use (in relative terms), but it comes at the cost of needing years to learn how it all works.
Auto-pilot is an interesting sub-example. It takes time to lean how auto-pilot works (and adds more function) but the feature itself allows a pilot to temporarily reduce the amount of functions they need to worry about (at the cost of less fine grained control over the plane). It’s a microcosm of these principles.
Shortcuts
There’s one big shortcut in all this. Learned behaviour and prior knowledge.
A computer mouse is theoretically higher finesse but slower to learn than a set of simple push buttons. But everyone already knows how to use a computer mouse. Most people know how to use a joystick. Many people know how to use swipe gestures. Some people know how to drive stick. A few people understand what polyhierarchical menu systems are.
The point here is that if your users are already familiar with a control system (finesse) you get use it almost for free. There is still a small learning cost for them to understand how their prior knowledge maps onto your product.
Exceptions
Not everything has to be easy to use. Snapchat offers lots of extra functions but they are hidden away. They could be easer to use. Snapchat knows this.
Hiding them reduces the learning curve for all new users.
They know their power users are willing to spend the extra time to learn how to get at this extra functionality. Lots of things, from computer command terminals to Starbucks secret menus work this way too.
The requirement is never: “…it needs to be easy to use”
It’s: “…it needs to be this easy to use”.
Article first published on 18 March 2014 on dermotholmes.com
