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.

The 80/20 Rule

The 80/20 rule is well known and has wide applications – in this case you can say:

• 20% of your applications features are used 80% of the time
• 80% of errors are caused by 20% of interactions

So, the first thing you need to figure out is what are the 20% of features your users really care about or are causing problems. You can do this a number of ways: ask them (crazy idea, I know!), watch them using the product or you could add logging functionality to your application (probably the most reliable way – what users think they want and what they actually want are very different ).

Once you have arrived at these features you can focus on polishing them:

• If they are going to be used the most frequently, see how you can make them easier to access e.g. make their icons more prominent, add shortcut keys etc.
• If a user is getting stuck somewhere try and identify why; is there a clash of terminology? is the next step of the process not obvious?

By focusing your efforts on this 20% of features and issues you will greatly increase the overall perceived usability because you are focusing on the areas that matter the most.

Open Office toolbar shows frequently used commands to allow quick and easy access

Aesthetic Usability Effect

Make your application pretty. When your users ask for usability improvements, secretly they may be crying out for it to be less ugly!

This is actually a known phenomena, attractive applications and products are perceived to be better and more user friendly than ugly ones. So ask a designer for some help, spruce up the CSS and you may be amazed about how much more user friendly your application becomes – just by making it prettier!

Constraints

Use constraints to stop the user from using your application in ways that you didn’t intend and ensure only they only enter valid data. This will cut down on errors and make interactions more intuitive. There are a number of ways you can do this:

• If your database column only accepts a certain number of characters – prevent the user exceeding this limit. Stopping them make the mistake is better than throwing an error or, worse, truncating their data.
• If a field should only accept numbers, don’t let it accept letters in the first place! Don’t wait until you are validating the input to tell them they’ve got it wrong!
• When a user is entering a delineated field (e.g. a MAC address, serial number or credit card number) don’t make them guess whether they should put spaces, colons, hyphens etc. between the blocks of input – have one field for each block and display an uneditable delineation between them.
  
  

  Windows XP Product Key dialogue removes the uncertainty as to whether to enter the dashes

• You wouldn’t have a user entering 1 and 0 or True and False for Boolean values; you’d have a checkbox! So, consider using controls such as sliders or dials for entering other data so that users CAN’T enter invalid values
• If a control can’t be used at a particular time grey it out or remove it altogether. Don’t tell a user off for clicking a button when they shouldn’t!

Make it CRAP

Ok this is 4 things for the price of one… but they all fit in to one acronym so only take up one place on the list. CRAP is an acronym from the field of graphic design; it stands for Contrast, Repetition, Alignment and Proximity. I wrote an in depth article about using CRAP to improve user experience in: How to make your user interface CRAP. These principles are easy to apply and can make a big difference without a huge amount of effort.

Lighten the load

Dealing with large amounts of information increases a user’s cognitive load and makes your application harder to use. Cognitive load is the amount of mental activity used to accomplish a task and includes things such as memory, perception, thinking/understanding etc. You can take steps to reduce this load and make your application more user friendly:

• Ask for as little as possible. Long forms, asking for lots of information, are intimidating. When a user can get away with it they’ll not bother filling them in. Where the user has a means to fill in the detail later, try to ask for as little information as possible to complete the task and let them move on.
  
  

  Creating a new project in Base Camp. Just the name and who's involved. The rest can follow later.

• Where you need a lot of information that can’t be deferred for later entry, break the form up in to a number of pages and walk the user through page by page. Make sure you indicate progress so they know how far they are through the process!
• Remove unnecessary information from the display. Each piece of information on a display should add to understanding rather than clutter. If it isn’t relevant or adding value then remove it.
• If possible, explain fields near where it is entered so your user doesn’t have to think about what it means. This is even more important when you are dealing with technical terms and acronyms – it saves a user’s blushes if they haven’t heard of it before! The screen shot of Base Camp above shows a good example of this by explaining what they mean for the field “Name the Project”

Use less words

Users hardly read anything. You’d be amazed how little they read. Your application isn’t a news article – if it has lots of descriptive text it simply wont be read. In fact, the shear amount of text will scare your users and make them think your application is complicated and hard to use. Most will just click OK or Next and hope for the best. When this is the wrong thing to do they will resent you.

If you need to prompt your user; use a declarative active voice. You don’t need to be polite and it wont come across as terse. For example don’t label a field “Please type in your full name:” just say “Full Name:”. The user doesn’t need to be asked politely and telling them to type it in is unnecessary – they can’t enter it via the medium of expressive dance. Even if they could – does that label preclude them from doing so? If there is too much to read there is a risk that important information will get lost in the crowd.

Above the fold

The ‘fold’ is a term from Newspaper layout design. The fold literally being where the paper is folded in half. Information above the fold will be seen by more people as you don’t need to unfold it to see the information. This term still has relevance in interface design, but the fold now is the bottom of the visible area without scrolling.

• Consider rearranging the page so the user can see the most important data without scrolling. Does it make sense for you to eliminate scrolling all together?
• Some applications display and group all the errors at the bottom of the page. As far as the user is concerned, they clicked submit and the form was just redisplayed to them. By the time they have thought to scroll down they already have thought that it’s a problem with your product rather than their use of it. So, lay out error messages so they are displayed above the fold (ideally, near to where the error occurred, but make sure you scroll the page so they are visible).

Sorting and Grouping

The way you organise the information in your application has a big impact on its usability. Sorting applies widely – from the order your menu items are in to the facilities you provide when displaying a list.

The 5 Hat Racks theory states that there are 5 ways to organise information:

• Alphabetical: Simply in alphabetical order. This is a good approach when the information can’t be grouped in a meaningful way or a user needs to access any of the information quickly. It’s a popular choice for application menus where the user can access any item in any order
• Location: Information is grouped by by physical space. If your data relates to the real world you could use this approach in conjunction with a map to show the information in its physical context.
• Time: In time and date order. Whenever you have a date or time associated with information make sure you can sort by them so the user can view the information chronologically.
• Category: Information is grouped based on some shared attribute. This could be what they are (e.g. books, dvds etc.) what they are used for (e.g. cold remedies, hair products etc.), colour, flavour etc. Categories are good to use for menus when there are natural groups that a user would expect e.g. financial information such as budgets, orders and invoices
• Continuum: Ordered in a continuous series. This could be best to worst, highest to lowest, popular to unpopular etc. Where there’s a common measure, provide a means to sort by it

Have a look at how you have presented lists and menus, consider what the information will be used for and how your users will approach finding it. Your users may approach the information differently depending on the context of what they want to do at the time. They will appreciate the ability to change how it is organised to meet their present goal.

Forgiveness

A great way to improve the user friendliness of an application is to look for ways you can make it more forgiving. Forgiveness is the name given to a number of approaches that help users avoid errors or reduce the impact when they do occur.

• Undo: Let people change their mind if they don’t like the impact of an action. This can be hard to retrofit at a late stage in development but it is one of the best ways of making your application forgiving.
  
  

  When you delete an email in gmail it doesn't ask for confirmation; it just makes it easy to change your mind

• Confirmation: Make actions 2 step by prompting the user to confirm the action they have requested. Confirmation steps increase the friction of the interface and can be annoying if used too often. You don’t need confirmation steps if the actions are easily undo-able (for example the “Are you sure you want to delete the file” dialogue in Windows XP is unnecessary as the files can be simply removed from the trash). You don’t need to just have OK/Cancel dialogues to add a confirmation step, it could be an additional separate action in an “Arm/Fire” sense. I wrote an article about Google mail’s creative use of a confirmation step to forgive users even when they are drunk!
• Warnings: Display warnings to alert the user of implications. This is the least intrusive of the forgiveness measures, you could add information in context to explain the consequences of currently selected options.
  
  

  Feedburner uses a warning near the confirm button to alert you to the implications without interrupting your flow

• Help: Finally, you can greatly increase your application’s forgiveness by including help and instructions! This is especially important if you find you have made a major irreversible error in your design and need to explain how the application is and perhaps how it differs to how it should be! At least until you can address the problem!

The Empty State

This is something a lot of software neglects and is a really easy way to improve your application. When you are testing or demonstrating your application it is full of test data. However, when a new customer first starts using it; it’s empty! You know that collapsed area over there will hold the whatsits and the big list at the bottom will contain dooberys – but your user might not! If a user doesn’t know what something is or what it should do they are likely to get confused; you can help them out by:

• Rather than displaying nothing when there is no information – use place holders e.g. “There are no dooberys to display”
• If it’s a user’s first time, tell them about the features in the place their content would be.
  
  

  Basecamp shows the ultimate empty state. It is empty, but has lots of information so you know exactly what to do next!

• Give a user an option to pre-populate the application with example data. If the data is accurate and meaningful to the user this is a really good approach. It lets the user see each feature in action with some concrete data. However, once the user has a feel for the application, make sure there’s an easy way for them to remove all the test data – making them do it manually record by record won’t win you any friends!

Conclusion

Products tend to be better if usability is thought about all the way through development. However, there are always other pressures and knowing this doesn’t help you much when you find yourself in the above situation! Hopefully, these tips will point you in the direction of some simple tweaks and reorganisations you can make to improve your applications usability when you thought it was too late!

Have you ever found yourself in this situation – how did you improve your application’s usability?

As far as I know its quite an old term from the field of Graphic Design. But if I cast my mind back, I think I first heard about it in Robin William’s book: The Non-Designer’s Design Book. I really recommend getting hold of a copy of her book – I loved every page of it, it’s very easy to read, full of practical advice and good examples/case studies. Once I’d finished it I was applying what I had learned to everything from my CV to reports I was writing at work! Only trouble with my work reports was the admin team would then butcher them to apply the “corporate style”. Arial 12pt – the philistines!

Just reading that one book will change the way you look at page layout. It’s also a great starting point if you choose to read deeper into design in the future. I really can’t recommend it highly enough!

Here’s a link to the book at Amazon (aff):

Contrast

In design avoid things that look similar; if 2 elements are not exactly the same make them very different. Don’t do your titles in 12pt Arial and your body text in 10pt Arial – they just look too similar to stand out. You can create contrast in many ways for example:

• Different fonts
• Different sizes
• Colours and backgrounds
• Borders
• Differing alignments
• Spacing

Our eyes are fond of contrast, it helps us prioritise and sort through the information before us. So how can we use contrast to improve usability?

Emphasise Primary Interactions

Use contrast to put emphasis on the most common or likely interface interaction and reduce the weight of secondary choices.

Figure 1.

Figure 1 shows a good use of contrast. By reducing the visual weight of the cancel action, emphasis is put on the OK button. This makes the cancel button less prominent and therefore less likely to be quickly clicked by mistake.

Highlight Important Notices

Contrast can be used to highlight important notices requiring attention. For example, when showing an error message it is important that this immediately stands out otherwise the user will not see that they have made a mistake and will assume that something is broken!

Figure 2.

Figure 2 shows the default look for error messages displayed when writing web applications using Ruby On Rails. The bright red box jumps out against the rest of the page and the user is in no doubt that they need to correct something before continuing. The field on the form containing the error is also outlined in red to increase its contrast with the accepted fields.

Group Related Elements

Contrast can also used to group related interface elements together and make them stand apart from each other.

Figure 3

Figure 3 shows the posting controls in WordPress. Notice how background colour contrast is used to group together the actions for Save, Publish and Delete Post. Bonus marks go to the WordPress interface designers for using contrast to reduce the visual weight of the “Delete post” link!

Repetition

Repeat visual elements throughout the design. Repetition creates unity and ties together things that would otherwise be perceived as separate. Repetition in usability at its most basic is simply to “be consistent”. If you have a way of interacting to achieve a certain goal in one place, make sure you repeat it everywhere to promote internal consistency. If you aren’t internally consistent across your system it gives the impression that the product was thrown together and there was no clear guiding vision. So, it is important to either ensure that team members working on different parts of the system stay in contact, or appoint someone with overall responsibility to maintain the consistency of the interface.

Consistency helps improve the learnability of the product. People are very good at recognising things they have already seen, and will be confident in their expectations of the results of their actions. Take advantage of this to speed up learning of the system by letting them apply things they already know.

Consistency doesn’t stop at the boundaries of your product. Repeat pre-existing conventions to achieve external consistency. For example if you are writing an application for the Mac take advantage of the existing skills people have and follow the conventions of that platform.

Google Web Search

Google Map Search

Google Product Search

The search interfaces are consistent across Google’s suite of products allowing users to rely on their existing knowledge of how to use the system and how it will react.

Alignment

Alignment is probably the most obvious of the 4 design rules; it is the placement of elements such that the edges (or their centre lines) line up horizontally or vertically. No element of a design should be just thrown on the page randomly, it should have some connection with another element on the page to create a unified, cohesive feel.

Alignment can be used to guide people through a design; such as arranging form fields in to columns to indicate the order the elements should be filled in. Users will naturally go down the form vertically, but if they reach a row containing more than one element horizontally they will follow that alignment before continuing vertically.

In a nutshell, unless you are drawing attention to a specific element (by increasing spatial contrast), ensure that elements of your page are neatly aligned to ensure a clear reading order.

Figure 4

Figure 4 shows the print dialogue from Firefox 3. Notice how the labels down the left are right aligned to the central column of colons and the controls are left aligned. This creates an association between the labels and their controls. The row of colons lead the eyes down the page vertically and where more than one control appears on a row your eyes are led horizontally.

Proximity

Related items should be close to each other. Grouping related controls together helps to organise the interface. Controls that are close together are perceived to be more related than ones that are far apart. The related items create a single visual unit so your interface is perceived as being made up of a small number of related units rather than as a page full of many individual controls.

Figure 5

Figure 5 shows the left hand side of the iTunes interface. The playback controls are grouped together and perceived as one visual unit. The Library, Store and Playlists elements group their own sub-elements as 3 distinct groups, but their proximity to each other allows the sidebar to be perceived as an interrelated whole.

Contrast, Repetition, Alignment and Proximity are good and simple ways to improve the look and the usability of an interface. So next time you are designing a user interface, look for ways you can make it more CRAP!