Usability Friction | Usability shouldn’t be a drag

The 80/20 Rule

By Ashley Towers | April 14, 2010

The 80/20 rule, also known as Pareto’s Principle, states that 80% of an observable effect is caused by 20% of the variables at play. The first recognition of this rule was by Vilfredo Pareto, who in 1906, recognised that 80% of Italy’s wealth was owned by 20% of Italy’s population.

The same 80/20 split can be seen in many places; management, economics, software/interface design, quality control systems and many more places. Whilst the rule is called the 80/20 Rule – the actual percentages are not all that important: 90/10, 70/30, 80/20 are all valid variations. Indeed – it is perfectly valid to say 70/10 as there is no requirement that the two sides add up to 100 – the important thing is the principle that a large number of outputs are determined by a relatively small number of inputs.

So using the 80/20 rule we can say:

80% of users only use 20% of features
80% of bugs are caused by 20% of the code
80% of development time is spent on 20% of the code

This rule of thumb is useful when focusing our time and efforts on improving our products. We first need to find out what our most important 20% is. The easiest approach to this is to simply ask customers what their favourite features are or maybe observe them using the product. Developers of web applications could use tracking software such as Google Analytics to provide detailed information on which pages customers are accessing the most. Alternatively, simple logging could be added to a desktop or web application.

Armed with this information we will know which 20% of features provide 80% of the value of our products. We can then spend time polishing these features rather than diverting efforts on to rarely used features. This approach will lead to the greatest improvements and make the biggest contributions to customer satisfaction. If we make a change that benefits 80% of our customers then that’s a big win and is going to generate a lot of good feelings. Much more so than adding a similar scoped feature to an area that falls under the less used category.

This isn’t to say we should completely neglect the less frequently used features – that proportion is likely to be very important when it is needed – but when we are faced with limited time and resources, focussing our efforts on the most used 20% will gain a disproportionately large benefit to our product and users. It is rarely considered a bad thing by users when we make improvements to the benefit of our most used and popular features!

Share this post:

How to write an alert box

By Ashley Towers | April 7, 2010

Alert boxes are a user interface element that pops up to alert the user of some critical piece of information. This post explains how to write them.

Lets start off by getting something out of the way. Don’t use alert boxes. They are jarring, often steal focus, interrupt the flow of what a user is doing (which is kinda their idea but that’s not my point) and are generally unpleasant. It’s like you are shouting something at the user. They tend to be overused (Crystal Reports XI I’m looking at you…) when they really should be reserved for the most critical of information.

So, always work on the assumption that there is a better way. Here’s some typical uses:

Validation Errors: If a field is invalid, don’t pop up an alert box; simply highlight the field that has the error (e.g. by putting a border around it) and show an explanation next to it. There might be a reason they haven’t filled in the box correctly (e.g. returning to it later) so making the user dismiss an alert box is annoying
Information Messages: Telling a user something has changed. Ask yourself – do they care – do they need to know? Can they (or do they need to) do anything about it. If not then you don’t need to interrupt work flow to tell the user about it! If the user doesn’t need to know and can’t do anything about it but you STILL want to tell them – this is a strong contender for a log file message!
Completed MessagesThese are when an alert box is thrown up to tell the user that something is complete. Is it that important that you stop the user doing what they were doing; make them dismiss an alert box before allowing them to continue just to tell them that something is complete? I suspect in most case it isn’t that important. Replace the alert by maybe showing a subtle message in the tool bar (or a Growl message for the Mac). When a CD has finished importing iTunes plays a sound. You know it’s done – but you don’t need to do anything about it if you don’t want.

Remember that you are interrupting the user. The things that you want to know about and be alerted to whilst programming the app are likely to be very different to the things the end user wants to know about! Put yourself in their situation and ask yourself if you would like to be interrupted for that reason. So let’s have a look at a couple of valid alert box uses:

“You have been inactive and will be logged out if you don’t start using the system”. This use is valid. The user is alerted to the fact that their inaction is going to have a consequence. The user needs interrupting for this. It’s like telling you “if you don’t get a move on you’ll miss the bus”
“The operation could not be completed because….”. This one is a grey area. It is a valid use – the user expected the operation to complete so they need to be interrupted to say it didn’t. However, does it require their immediate attention? Can you say with any degree of certainty that your alert is more important than what they are working on in another window? Probably not. So use with caution

There aren’t many scenarios where an alert box is the best choice. But if you must have an one for whatever reason, bear the following in mind:

People probably wont read them – they are often just OK’d without being read
So, keep them short
They are modal so the user wont be able to follow any instructions once they’ve dismissed the message. If your instructions are more than 1/2 steps make sure there’s a way to see the instructions after the alert box has gone
There probably is a better way that you haven’t thought of yet

Share this post:

Posted in Tutorials | Tagged Annoyances, Confirmation, Interface Elements | Leave a comment

Aesthetic Usability Effect

By Ashley Towers | March 30, 2010

The aesthetic usability effect is where a user will perceive an attractive product as easier to use than an ugly one. It doesn’t actually matter if they are easier to use or not they are perceived as such so users will make subconscious concessions and overlook many difficulties. The seminal work on this principle is “Apparent usability vs. inherent usability: experimental analysis on the determinants of the apparent usability”. This is available for ACM members to download from the ACM Portal (If anyone knows of a freely available source for this paper please share it in the comments!). The conclusion from their abstract nicely sums things up though:

These results show that the apparent usability is less correlated with the inherent usability compared to the apparent beauty… This suggests that the user may be strongly affected by the aesthetic aspect of the interface even when they try to evaluate the interface in its functional aspects and it is suggested that the interface designers should strive not only to improve the inherent usability but also brush up the apparent usability or the aesthetic aspect of the interface.

The aesthetics of a product have far reaching consequences. The desire to posses attractive items is an innate part of the human condition and we should use this to our advantage. All other things being equal, when comparing two products:

The attractive product will be perceived as easier to use. Ease of use is often a criteria in purchase decisions – easy to use products require less training and support. So by improving the attractiveness it increases the perceived ease of use – improving the chances of making a sale
Users will be more likely to develop positive feelings towards the attractive product. This can lead to:
- Positive reviews – leading to more sales
- They’ll tell their friends – resulting in more sales leads
- They’ll tolerate faults more – reducing support calls
The attractive product will be perceived as of higher quality
And, perhaps most importantly; customers may overlook feature deficiencies so they get to use the more attractive product

Spending time and money on the outward appearance of your product makes a lot of sense and that it can more than pay for itself in increased sales. So, if users are complaining that your product isn’t user friendly it might not be a problem with the interface mechanics – it might be their way of saying that it isn’t pretty enough!

Share this post:

Posted in Tutorials | Tagged Aesthetic Usability Effect, Design | 37 Comments

Reducing Damage Through Usability

By Ashley Towers | March 23, 2010

I spent my weekend installing a new central heating system. When I unpacked one of the radiators (the largest one at 1.2m x 0.5m ) it was damaged. Most of the radiators had the odd dent in the grills but could easily bent back in to shape. This one however had been in the wars so it had to go back. A trip to Toolstation later and I was unpacking its replacement. This one was even more damaged than the last! Feeling stupid for not checking it out in the shop; I made another 40 minute round trip.

During this second journey I started thinking about why so many had been damaged and how can you stop things from being damaged in transit. There are 2 main approaches to reducing damage:

Make the product physically tougher so it can withstand harder knocks
Add more protective packaging

Unfortunately, both of these options increase costs. Making the product tougher also adds to its weight, size, appearance etc. so it might not even be an option in all cases.

So, what about increasing the protection from the packaging? Now, a certain amount of returned products due to damage is to be expected – no matter what you do a certain amount of damage is inevitable. So a manufacturer must carefully trade off the cost of the packaging vs the expected cost of returns at any given level of protection.

My radiator was actually pretty well packaged; covered in bubble wrap; thick corrugated card to protect the ends then plastic corner pieces to protect the corners. So, I wouldn’t think adding more protection would be cost effective (then again I suspect that 2 in 3 radiators being damaged can’t be acceptable either!)

Examining the damage it was obvious that they taken a knock whilst being carried/moved. As I drove along I thought about the struggle it had been to carry and load them in to my car. Then it struck me – the problem isn’t with the radiators or the packaging – it’s a problem with the usability of the package as a whole!

These things are bulky – not desperately heavy; but large – you need 2 people to carry them. The problem is – there’s nothing to get hold of. When packaged they are completely smooth – so you need to get your hands underneath them to carry them properly – and trust me after a few squashed fingers you soon stop that! This leaves you with trying to carry them by gripping the edges. When doing this there is a tendency to drop them as you lose your grip when putting them down. You can just imagine how many get dinked by a delivery driver in a rush to unload dozens of them!

I suspect that if some handles were added to the top and sides of the radiator that the number of returns due to damage would reduce markedly. This could be done cheaply by wrapping some heavy duty tape around the edges of the radiator but leaving some loops of tape unstuck to form some handles. This would make the radiator easier to handle and become less likely to take a knock when being carried.

If you find that your products are getting damaged and your returns rate is unacceptably high; don’t forget to take in to account the period between the factory and the store. Usability doesn’t just relate to the product itself; the whole experience including the packaging are worthy of attention and if a slight change to your packaging reduces returns that goes straight on the bottom line!

Share this post:

Posted in Usability Bites | Tagged Annoyances, Packaging | Leave a comment

Call to Action vs Mental Models

By Ashley Towers | March 19, 2010

After reading John Gruber’s post An Ode to DiskWarrior, SuperDuper, and Dropbox over at Daring Fireball, I decided to give Dropbox a go.

So I went over to their site for a look:

Nice and clean looking. I watched the video and was sold – sign me up! But, this is where the trouble started. The service is subscription based (with a free option). So I started looking for a link so I could “sign up”. There’s a big download button…. no that’s not it (I need to sign up before I download anything surely!)…. there’s the log in fields in the top corner (so I certainly need to sign up before I can use those) …. but nope no option to sign up there either…. a big list of links at the bottom of the page… still no sign of a “Sign Up” button!

The problem is the wording of the main call to action (the big button in the middle) – it says “Download Dropbox”. However, this is not what my mental model says my next step should be.

A mental model is built up in your mind as a representation of how you perceive something works in the real world. It is based on conventions and previous experiences. It gives your brain a short cut to understand new things. It’s why people who use computers a lot “know” how software they’ve never used before works – their mental model sets expectations and as long as they are met it’s easy to just focus on the differences.

In this case – my mental model was based on using many web based systems in the past. I expected the following:

Sign up
Download software (if applicable)
Start using the service

When your mental model isn’t matched by what you encounter, it takes some time whilst your brain reconstructs a new model based on its input. But your brain doesn’t like forming new models so all along the way it’s trying it’s hardest to try and graft the new information on to the old model. This takes time and leads to feelings of confusion whilst it’s going on.

The big button in the middle of the page is great – it should be obvious that you click it – but because it didn’t match my mental model the thought didn’t occur to me immediately. By saying “Download Dropbox” it is forcing an implementation detail to be my next logical thought. But it isn’t.

It turns out that you actually sign up when you run the application the first time through the software itself. Given this, I accept labelling the button “Sign Up” would also be wrong. I’d recommend that the main call to action button should be relabelled “Get Started” (or similar) taking you to a page that explains how to install and sign up. Then maybe have a separate link for people who know how it works and just want to grab the installer. I think this would make it clearer what you should do next, regardless of any preconceptions.

In fairness, when you click the “Download Dropbox” link you do get shown a list of your next steps for installing the product. However, even this page doesn’t tell you that you sign up during the first run!

This example illustrates that when you are asking people to do something, before you’ve even asked them anything they have built up an expectation of what you will say. If your proposition does not match their expectation they will have a few moments when they feel confused – and confused people often don’t make the decisions you want!

Share this post:

Posted in Usability Bites | Tagged Annoyances, Conventions, Mental Model | Leave a comment

Why We Test

By Ashley Towers | March 15, 2010

The 2 buttons in the above picture are for a toilet flush. One button does a big flush using lots of water; the other does a smaller flush using less. Using a small flush when that’s all that is needed avoids wasting water and that’s a good thing.

As you can see the 2 buttons are of different sizes. As an interface designer this poses us a problem – which button should trigger which flush? There are 2 options:

The big button is for a big flush and the small button is for a small flush
Or, we assume the small flush will be used more often so it should have the bigger button to make it easier to use. The less frequently used big flush can have the smaller button.

The problem is that neither approach is ‘wrong’ – each is a valid implementation. That’s why we test – once we have seen how people naturally interact with our product we know which decision we should take.

The above example is quite trivial but it illustrates the point – for any given interaction there are multiple valid interpretations. If we want our products to be enjoyable we need to know which interpretation the majority of people hold. This is especially important for new products – as we develop them we are totally immersed – living and breathing it every day (and night!). We know how it works. When we created the interface, we could see no other way that it could be interpreted. However, as soon as we see someone use our product for the 1st time, all that certainty can be washed away in an instant.

Testing reveals the truth. We don’t test to be proven right or wrong; we test to see how things are.

Share this post:

Posted in Usability Bites | Tagged Conventions, Design | 3 Comments

Five Hat Racks

By Ashley Towers | September 29, 2009

The Five Hat Racks was first developed by Richard Saul Wurman in his book Information Anxiety. It’s a bizarre name, but makes sense: the hats are information…. hat racks organise hats…. and there are 5 ways to do it. Fine, call it what you like – at least it’s memorable! In a nutshell, there are 5 ways to organise information: By Location, Alphabet, Time, Category and Continuum. Every way you can think of to organise data will fit in to one of those groupings.

Location

What is it? Organising by physical location; either geographically or a location in space. For example, this could be showing landmarks on a map or sorting objects as nearest to furthest relative to your position.
When should you use it? When giving directions (e.g. order you will encounter landmarks) and whenever relative position is important e.g. landmarks on a map

Alphabet

What is it? Ordering alphabetically, for example how the dictionary or phone book sorts entries.
When should you use it?Whenever efficient random access is needed (applies to most reference material – dictionaries, encyclopaedias, book indexes etc.). It should also be used as a back up when no other sorting strategy makes sense.

Time

What is it? Sorting by chronological order. For example Cinema Schedules, Bus Timetables, Time lines of historical events etc.
When should you use it? Whenever a time based order of events is needed e.g. cooking instructions; when comparing events over a period of time (especially if there is an element of causation between events) or when things happen at set times.

Continuum

What is it? Grouping by a magnitude e.g. Best to Worst, lowest to highest, happy to unhappy etc. For example Football league tables, Star Ratings on products, energy efficiency, size etc.
When should you use it? Use continuum when a shared measurement to compare things is available that will naturally be used in comparisons by the user

Conclusion

Don’t be afraid of using more than one hat rack at a time – you could have items sorted by category then within each category you could sort alphabetically.

Just remember that you are trying to present the information in a way that is accessible to the user. Usually this means you may have to allow them multiple ways to view the data. This leads to more usable products as you will be allowing your user to see the information in a way that is relevant to their current goals rather than just the way you thought of when you designed it.

If you are having trouble guessing where/how your information should be sorted and/or grouped – leave a comment and I’ll try and help out!

Share this post:

Posted in Tutorials | Tagged 5 Hat Racks, Basics | 4 Comments

Leading the Eyes

By Ashley Towers | September 16, 2009

Every good magician knows how to lead an audience’s eyes with their gestures. This allows them to make the audience look in one direction, and whilst their gaze is averted, the magician is free to perform a sleight of hand or develop his illusion.

This same effect can be used in design. Here in the UK, or at least near where I live, pedestrian road crossings are being replaced with a new generation that exploits this principle. It’s going to save lives.

The old generation had a button on the pole to start the crossing timer, then you looked across to the other side of the road to above head height where the green/red man (Walk/Don’t Walk) display was located:

Press the button on the pole...

...then look away from the traffic

The new generation have the green/red man located on the pole, but crucially, your attention is directed so you are forced to look in the direction of the oncoming traffic:

New control has the wait signal in line of sight of the oncoming traffic

This is fantastic, by moving the interface element that has your attention, it puts a secondary element (the oncoming traffic) in your peripheral vision. Personally, I’d argue the oncoming traffic shouldn’t be the secondary element – cars hurt more than crossing timers….

You can apply this same principle when designing software interfaces:

Spend time thinking about what parts of your interface will have your users attention then carefully position these so that other events can occur within the same field of vision
Progress indicators guide a users eyes from left to right as the percentage complete increases. Use this to direct a user’s gaze to the next element they will interact with – e.g. the ‘next’ button that will become enabled or a region that will fill with content
Group conceptually related elements. When laying out your interface if related controls are grouped together, your software will feel more fluid. People will look near related controls first and they’ll be happy if they consistently find things where they expect them to be.
If you need to lead someone’s eyes to an element that is not currently visible … make sure that you scroll it in to view!

Share this post:

Posted in Physical Interfaces | Tagged Eye tracking, Proximity | Leave a comment

iLife and the Untitled Document Syndrome

By Ashley Towers | February 21, 2009

There’s a fantastic article over at Daring Fireball about the friction of saving an ‘Untitled Document’ – It’s so true! Well worth a read.

I completely agree with his observations about the iLife suite. Both iTunes and iPhoto abstract away the location of their actual files from the user. Recent switchers to the Mac have a really hard time with this concept – “But where are my files?!” they cry!

The files are there; if you really must see them they are easily findable. The uncomfortable leap of faith comes with letting go; not caring where they are physically located. The files are an implementation detail – what you as a user care about is can you find the photo or song in order to use it. In both cases, an app specifically designed to manage that kind of media makes for a much better experience than a general purpose hierarchical directory browser. If you then need a copy of that file for whatever reason – just drag it out of the app on to the desktop then you can use and abuse it at your leisure – safe in the knowledge that the appropriate iApp is keeping the originals safe.

I remember going through the transition myself and it is an odd feeling for someone accustomed to managing their own data. But, once you let go it’s very liberating!

Anyway, without further ado, over to Daring Fireball: Untitled Document Syndrome

Share this post:

Posted in Links | Tagged friction, Links | 2 Comments

7 Ways to Annoy Your Users

By Ashley Towers | December 29, 2008

Your users will probably mess things up. Some are just down right stupid. Don’t trust anything they say, it is probably a mistake. The best way to deal with this sort problem is to ask them lots of questions, even when it’s obvious they meant to do what they just did. Are you sure you want to do this? Absolutely sure? This will interrupt their workflow so much that they wont have time to do any damage. Or work. Which is probably for the best.
Make sure any text in your application is as verbose as possible, your users will appreciate having something to read. So avoid short labels such as “User Name” they want to see descriptive text like “Please type in your username in this text box over here:”
Make careless errors throughout. Where possible make any choices ambiguous so that they don’t know what the impact of decisions will be. You can also save time by not doing any spell checking on your application or worrying about how things line up on the page in to natural groupings.
Your users have all the time in the world to trawl down long lists of data. Any mechanism for filtering and sorting that data would lead to confusion so it’s probably best left out.
Avoid any form of established conventions – it will probably be obvious what you meant. Whilst you are at it, fit as much information on one page as physically possible and don’t worry about its location either. Users will almost certainly be able to spot the pertinent piece of information amongst all the clutter. If you want something to aspire to, John Gruber found this beauty. I think we all can learn from that!
Don’t provide any easy way of getting data out of your application. Why would users want to when they can use the features of your app? If they want to do advanced work with their data using specialist tools then that’s an opportunity for you to enhance your app! They can just wait until you’ve implemented those features (obviously, once you’ve charged them for the privilege!)
Treat your users as criminals by making sure you have draconian security measures in place. Bonus marks if your app dials-home every time it is run, just in case the user has stolen it since the last time they ran it. Of course, it’s better to devote time to making a poor product hard to steal than releasing a quality product that people are happy to pay for!

If you were in any doubt; the above is very much written tongue in cheek. However, the amount of times I’ve seen these mistakes in the wild you’d think that people were deliberately trying to alienate their customers and users or taking the above seriously!

I’d be interested to hear of things that you have encountered in software that almost seem like they were added for the sole purpose of annoying you!

Share this post:

Posted in Software Interfaces | Tagged Annoyances | Leave a comment

Categories
Subscribe in a reader
Follow me on Twitter!
Search
Pages
- About
- Advertising
- Contact
- Home
- Links
- Privacy
- Store
Archives

Popular Posts

Usability shouldn’t be a drag

Location

Alphabet

Time

Category

Continuum

Conclusion

Categories

Search

Pages

Archives

Popular Posts