There’s a well known rule that we are only able to process 7 plus or minus 2 pieces of information at a time – it’s the magic number 7. We can improve the usability of our products by taking this in to account and reducing the cognitive load for our users.

There are 3 kinds of Cognitive Load:

Intrinsic Cognitive Load

The Intrinsic Cognitive Load is the inherent complexity of the task in hand. Drawing a square is a lot easier than drawing a portrait. There is little we can do about the intrinsic cognitive load, some things are simply harder than others. However, we can manage it by chunking the information in to smaller problems so that each can be dealt with in turn before re-integrating the information back in to the whole.

Extraneous cognitive load

Extraneous Cognitive Load is the result of the way that the interface or information is presented and structured. As designers this is where we have the greatest impact. For any given task, a well designed and clear interface will have a lower extraneous cognitive load than a badly designed one. Obviously, we should not add to the complexity of the underlying problem by producing complicated interfaces!

Intrinsic and Extraneous load are additive – they combine to form the load of the task. A simple problem presented badly can have the same total cognitive load as a complex problem presented well.

Germane Cognitive Load

This is the “good load” and we want to maximise it. It’s the spare capacity to deal with the underlying information (the intrinsic load) – the capacity available to perform the mental work that leads to understanding. If a task has a high intrinsic load but a low extraneous load, then the Germane load will be high as the user is able to focus their available resources on understanding the problem. If the same task has a higher extraneous load then the Germane load decreases because the user is having to expend resources on dealing with the extraneous elements.

How to lower cognitive load

• Minimise the “noise” in your interface by remove unnecessary visual elements. These increase the cognitive load as they need to be processed in order to determine their relevance.
• Chunking – reduce number of things that a user has to worry about at once by breaking the task down in to chunks. For example a “Wizard” style interface can help reduce the amount a user has to focus on at any one time.
• Consider having an “Expert Mode” for the more advanced settings
• Ensure the information relevant to the task in hand is available (so the user doesn’t have to remember it) people are much better at recognising the thing they want than they are at remembering it!
• The time it takes to make a decision increases with the number of choices available (Hicks Law), so try to reduce the number of choices (e.g. by writing opinionated software)

Fotolio

I’m going to base this example around an imaginary website. I’ve called it Fotolio, it’s a portfolio site for photographers to upload their photos. Imaginative names aside, I want to stress the below isn’t really how I’d design this kind of site, it’s a forced example to help illustrate the point. However, it is fairly representative of 100s of web applications out there:

So, Fotolio has 2 features:

• You can create albums to organise your photos
• You can upload photos to albums. Photos must live in an album

That’s all it does (well there’s some user profile stuff too – but it’s completely imaginary so it can do what ever you want!)

So, let’s look at a mock-up of how it would look fully populated:

There’s albums, a list of photos – once a user has got to this point they will have a good grasp of how to use the software. By this time it will be obvious that they go to the manage albums tab to create a new album; it will be obvious that they then go to the upload pictures tab, select the album then start uploading.

This is the state that the developer and other internal people will likely have the software. There is already content in there, they have context. If you can see other content in context you can link things all up in your head – it’s pretty powerful stuff. Without this you are left guessing. So, how might this app look to a new user in its empty state?:

Here we’ve just got empty lists, the system is outputting something meaningful e.g. “You have 0 Albums” so that’s a good start, but where do we go from here? Is it obvious what to do next? Let’s use the process I outlined on Monday. What does the user need to do to start using the software:

1. Create an album – this involves:
   1. Switch to the Manage Albums Tab
   2. Click the New Album Button
   3. Complete the details and click save
2. Start uploading photos – this involves:
   1. Switch to the upload pictures tab
   2. Select the album they want to upload against
   3. Upload their photos

So, we expect the user to know that’s the steps. However, is that obvious? No not really – there is nothing to stop the user blindly going and straight to the upload pictures tab to be stopped in their tracks when there isn’t an album for them to select. Granted, this is hardly the end of the world, but you’ve just slowed them down. They’ve now got to back track and create an album. Grrr.

So what can we do to improve things?

A small improvement

You don’t have to make major changes to your application in order to have a big difference on its usability. All we want to do is give the user a hint to suggest what to do next. A simple quick fix could be the following:

Here we’ve added 2 buttons to the front page. The button for creating a new album is shown immediately below the empty list – this creates a visual grouping between the empty list and the means to add items to it. We’ve also introduced the dependency between the albums and the pictures – the upload pictures button is disabled and re-labelled to instruct them to create an album first.

This isn’t a major change, a few minutes work. But we are giving the user a crucial pointer as to what they need to do to next.

A bigger improvement

But let’s go further. This is our first impression – let’s make it a good one. Let’s hold the user’s hand, guide them through the process. We’ll do away with the empty list altogether and replace it with some instructions. They can’t upload photos until they’ve created an album so let’s remove all mention of it. We’ll even include a screencast showing them how to do it:

Great, the user is left in no uncertain terms as to what they need to do next. We can now go even further; we can progressively introduce the interface – the user now has an album so we’ll show that control; but they haven’t got any photos yet – at the position where their photos would be we can show them some further instructions:

The above approach progressively replaces instructions on how to create content with the actual content itself. The user sees one of two things 1) Their content or 2) Instructions on how to create it. This makes it easy for them to get up and running.

Granted this is a fairly trivial example, but it should be evident that as applications get more and more features it becomes harder and harder to join up the dots. You don’t need to go to the extent suggested above, but you should take steps to ensure that a user always knows what they need to do next.

What is the empty state?

The Empty State is your software in its initial state before the user has entered any data or set anything up. It’s what your new users are exposed to the first time they use your application. It’s a crucial phase; this is before your users have experienced what your application can do for them; before they have fallen in love with it and realised they can’t live without it. It’s where you are at your most vulnerable of losing a user because your software is “too hard”.

However, despite this importance it is it is often neglected. Developers have their test data and the software works great! Salesmen have sample data and run their demonstrations using that – it all works just fine! Nobody ever deletes it and sees what happens. So a new customer installs the product and is faced with a blank slate! In many cases they have to fumble their way through guessing what steps are needed to start being productive.

How do you do it right?

So how do you do it right? How do you help your user through this crucial phase?

First of all you need to recreate the problem: Perform a new install of the software, delete your sample data, create a new account. Do whatever you need to do to get your application in to the same state as it is received by the user. Once you are looking at the same thing as a new user would you can take stock of the situation:

• Is it obvious what a user needs to do next? Do you tell them that or are you assuming it’s obvious?
• Where ever there is an empty list of things are you explicitly saying that it is empty or are you just outputting nothing? (“Nothing to display”, “0 Records Found” or any other equally generic statements count as nothing!)
• Are there any errors because your software assumes “there will always be at least one of those”

Ok, so you’ve had a quick look around, now to address the problem. You would know what needs to be done next if you were asked to set the software up. For example, you might know to start by creating some more user accounts; that a user needs to add a project before they can add any task items etc. Assume your user doesn’t know this. Take a pen and paper and make a list of what you would do to start using the software. Put the list in order. Now, ask yourself, how does my user know that this is what they need to do?

Make your interface reflect your list. Hold your user’s hand:

• If a feature is unused or empty. Add text to explain what the feature does and how to set it up or create the first record
• Provide a link to jump to the settings/creation page for that feature
• Would a demonstration video be even better?
• Are there a series of steps that the user must go through in order? Why not create a set-up Wizard dialogue to guide them through the process?
• Sometimes an example works the best. Why not give the user the ability to pre-populate the application with sample data? WordPress does this to help you set up a Blog – it can be useful when you’re a new user. You could go further and provide sample data for different kinds of user/market so that they are presented with relevant data.

Make sure you never leave your users unsure as to what their next steps should be.

I want to take this further, so I’ll be writing a bonus 2nd post this week on a simple case study to illustrate the above. Make sure to check back here on Wednesday for the follow up post.

Movements to a target occur in 2 distinct parts: firstly a big movement to get approximately in the right place, followed by a series of fine tuning motions to lock on. You can see these in action – watch your finger as you point at a small object at the far side of the room you are sat in now e.g. a light switch. Chances are you’ll move your arm in a big movement, probably overshoot, then make a series of smaller movements until you are pointing directly at it. Now try it with a bigger object – maybe you have a big TV hanging on the wall. Here you will make the same big arm movement, but because the target is so big you don’t have to make as many (or any) fine tuning motions – so it’s easier to acquire the target.

Lets look at some examples. In all of the below graphics the red box is the target; the dashed line represents the travel from the starting point to the target and the area marked over the target represents the dimension in which the user can decelerate and acquire the target:

Here we have a big target on the far side of the screen, because it’s big it shouldn’t be a problem to click on quickly:

The big target area means that the fine tuning motions aren’t necessary before the cursor comes to rest over the target.

In this next example we have a much smaller target on the far side of the screen so it’s going to be harder:

Because we have to move the cursor a long way and it’s a small target it’s going to take a series of fine tuning movements before the pointer is correctly aimed at the target.

However, if the small target is close by – it is less of a problem to hit because the initial movement to get there is smaller – reducing the risk of needing to correct an overshot.

It is important to bear in mind that for irregular shaped targets, size is relative to the plane of movement. In the following example, if you are moving to the target horizontally the button is quite big, however, when approaching from above or below the target presents a much smaller area.

In addition to the size of an object, we can make a target easier to acquire by placing it at the edges or corner of the screen. This is because they are “infinitely targetable”; that is – you have an ‘invisible barrier’ to work against. You make the initial big movement then you don’t need to make the smaller fine tuning motions as any excess overshoot is ignored.

This is used by both of the major OS vendors to good effect:

Mac OS X has the Dock at the bottom of the screen; this is infinitely targetable as you can’t point your cursor at a point lower than the dock so it’s always clickable:

On Windows, the Start menu is in the bottom left corner of the screen – the corner is infinitely targetable as if you make a big mouse gesture towards that corner you will always end up over the start menu button.

One of the big differences between Mac OS X and Windows is the location of program menus. Mac OS X has the menu across the top of the screen whereas Windows has them attached to individual application windows. Fitts’ Law shows that in many cases the Mac approach is superior: On the Mac you throw your pointer to the top of the screen and you automatically end up over the menu. On Windows you have to go through the full sequence of making a big movement, then smaller correcting movements before you end up over the menu. There is no region of infinite targetabiltiy.

However, the Mac’s approach is starting to see limitations. Whilst it is infinitely targetable, Fitts’ Law includes a measure of your current location. As large monitors and multiple monitor set ups become more and more common, the Mac user is having to travel a significant distance to reach the menu at the top of the screen, potentially outweighing the time saved by reducing the need for finer movements.

Fitts’ Law Applied

One of the biggest disappointments for web developers is that we can’t easily take advantage of the edges and corners of the browser window. So we have no infinitely targetable areas we can use to our advantage. So what can we do:

• Make your links bigger by increasing the targetable area. Use padding around links so that the user has a little forgiveness around the text they are trying to click
• When you have several clickable items or links together either make the items larger or space them out a little. Page navigation links on search results is very often done badly. For example, this results page has far too much too close together: Whereas Amazon do a much better job, nicely separating the individual links:
• Make the button a user is most likely (or most wanted) to click bigger. E.g. Make your OK button bigger:
• Group actions together – if related interactions are near to each other this not only increases their relatedness in the eyes of the user but also reduces the mouse movements necessary to move between them

Finally, don’t be afraid of experimenting! 37 Signals have a really interesting use of Fitts’ Law on their “Signup” button for Sortfolio – as you hover over the button it grows and shows more information – so as you begin to make the fine tuning movements to precisely acquire the button, the need for them is reduced by the target button growing! Fantastic stuff!

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!

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

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!

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.

Category

What is it? Grouping by a shared similarity. For example; Churches with and without a spire, Subject in a book shop such as fiction, non-fiction or autobiographies, departments in a department store etc.
When should you use it? When people will naturally look for something by category – e.g. if you want a new blender you would expect it to be grouped with other kitchen appliances. Bear in mind categorical grouping has weaknesses:

• Not everyone will group things the same. This is especially a problem where there is overlap between categories – for example should a waterproof shower radio be in the electricals or bathroom department?
• Categories can break down when there are large numbers of items within each category; leading to sub-categories and sub-sub-categories. This can make things even harder to find especially when compounded by the above differences in categorisation!

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!

When you held your first MP3 player you (probably!) instinctively knew how to play and pause a track. You’d never used one before, but you knew how to do this because the manufacturer correctly followed the control conventions from CD players, which in turn had followed the conventions of cassette players. You didn’t need to learn anything new.

A convention has built up for audio playback that vertical bars are used for volume controls and both Windows XP and Mac OS X use them. This fits in with previous conventions, audio mixing desks have vertical sliders too. It also has a good affordance – you push the slider up to turn the volume up and pull it down to turn it down.

Horizontal bars, by convention, are used for indicating the progress of a track. For example, in iTunes, the shaded area represents played audio, the unshaded area represents unplayed and the diamond is the current position in the file:

Other applications follow similar conventions, so why, when designing the iPhone’s volume control did Apple do this?:

To my eyes, the controls at the bottom are skip back, pause, skip forwards then a track position indicator. It even follows all the conventions: It’s horizontal, it has a shaded area to show the elapsed audio, an unshaded area to represent the unplayed and a marker to show the current track position! Fantastic, until you try and use it to skip to the end of a track and then painfully find out it’s the volume control! I’ve seen so many people do this when showing them my iPhone – I probably should warn them actually!

So, what could Apple have done to follow the convention and have a vertical slider?

1. Use a vertical volume slider running down the side of the screen
2. Have a smaller slider to the height of the control pane
3. Have a pop up volume control

Ok, 1 is just ugly. We don’t do ugly so that one can be discounted. Option 2 sacrifices fidelity of control (or would at best make it fiddly) and for something as personal as volume this would be unacceptable. Also, 1 and 2 would stop the interface looking nicely balanced and symmetrical which wouldn’t do! So that leaves us with option 3. This is no good either as it makes changing the volume a 2 step process and for a common interaction like changing the volume this would be annoying!

So, it appears Apple had a legitimate reason to ignore the convention – a tall thin screen makes a horizontal volume control the best choice. However, where they went wrong is that they broke a convention but then kept it secret until you discover it through making a mistake! They should have done something like this:

This simple addition of volume icons removes any questions over what the slider does and that is worth the price of a slight reduction in slider length.

We notice when conventions aren’t followed and get tripped up. This doesn’t mean it’s wrong to break them as long as your reasons are good and you make it clear to your user that you have done so!

The other system was written by different team of people. Any team working towards a common goal becomes a microcosm and develops its own way of doing things. This is likely to differ from yours. Sometimes, the differences are small things such as international date conventions (dd/mm/yyyy vs. mm/dd/yyyy) or maybe your application saves a user’s work automatically whereas theirs requires a save button click to commit changes. Unfortunately, these seemingly minor inconsistencies add up and have a huge impact on the overall usability of the product.

If you tightly integrate the external system, your users will be unaware of where your product ends and the other starts. Actually, they wont care; they’ll just be angry that it behaves differently in different places and they keep making mistakes.

So, what can you do to mitigate these issues?

Don’t integrate the front end

When the opportunity presents itself, by far the best approach is to write a new user interface from scratch for the system you are integrating – following your own standard conventions. This gives you an opportunity to make the experience completely seamless; taking advantage of the other system’s tried and tested business logic without compromising the user’s experience. Of course, this is not always possible, you can’t easily replace the interface of something like Google Maps – it’s simply too visually focussed, alternatively, you simply may not have the skills in house to do so. In these cases one of the below approaches must suffice.

Act as a Portal

If rewriting is not an option, consider only partially integrating the systems. Perhaps you can connect behind the scenes to display some ‘totals’ or other summary information but defer to the other application for the detailed view or for making edits. For example, if you wanted your application to integrate with a finance system; rather than embedding ways to create orders and invoices etc. simply retrieve the totals so that this information is available in context, but then redirect to the finance system to view order line details or create new invoices. This approach has the following benefits:

• It cuts down your work and reduces the chances that you’ll introduce any inconsistencies
• It lets the user perform the external task quickly in a, possibly familiar, tool designed explicitly for the task
• They won’t have to learn your implementation
• You still get the benefits of showing some data in context with your application
• You just integrate the features that really matter

You’re not in Kansas anymore

Sometimes you are stuck in the awkward position of not having the time or resources to rewrite the entire interface and a partial integration effort is not sufficient. Unless the external system fits in well with the rest of your application, the best approach is to not pretend that it is a part of a whole. Make the integrated features look like they came from somewhere else (maybe even going so far as to say so?). If the user is aware that the functionality they are using is from another vendor they will be much more forgiving of any inconsistencies – they will almost expect them.

If you take just one thing away from this, remember don’t integrate the look without the feel!

A Cautionary Note

Whenever you integrate another application’s functionality, by definition, you are expanding the scope of your own. Ask yourself if this is wise. Make sure the user will gain something from the integration – your application doesn’t need to do everything, it’s fine for them to go to another application! You will be positioning yourself as the focus of any bug reports and complaints for a component that you may have little or no control over.