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!

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

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!

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

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!

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!

I’ve not had chance to read it all yet, but what I have read so far is very good, so I saw no point in delaying sharing it with you all!

Working through Screens is a reference for product teams creating new or iteratively improved applications for thinking work. Written for use during early, formative conversations, it provides teams with a broad range of considerations for setting the overall direction and priorities for their onscreen tools. With hundreds of envisioning questions and fictional examples from clinical research, financial trading, and architecture, this volume can help definers and designers to explore innovative new directions for their products.

It is available in 3 formats:

• Online html
• A 143 page pdf
• A highly summarised ‘Idea Cards Edition’

I love the ‘Idea Cards Edition’ idea – so much valuable information is lost when it’s bound up in a book that people haven’t the time to read!

He’s generously released it under the creative commons license (Attribution-NonCommercial-ShareAlike) so if you enjoy it you can share it with your friends!

Grab yourself a copy from the Working Through Screens mini site

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?

The list is mainly usability/UX pages, but there’s also a few links to other pages I enjoy that might be of interest to you.

On a related note, I’m now posting on Twitter, so if you like you can follow me here!

This made me notice a parallel between learning a new piece of software and learning to juggle. The more features your software has the harder it is to learn; the more balls you have the harder it is to juggle. Notepad is the juggling equivalent of one ball – it’s easy. Let’s say this man on the train made the leap to Word Pad, or even worse to Word. Now he’s got more to worry about; formatting, fonts etc. More features, more balls. The formatting can get messed up, the fonts might keep reverting to the wrong size – he’s just dropped his juggling balls and is frustrated.

The problem is; people want features (whether they need them or not!) so will put pressure on you to add them: features add complexity, complexity increases bugs, bugs increase support issues …and…erm… support issues lead to the dark side…

Users are selfish. I don’t mean that as a criticism – they have their problems and they bought your software to solve them, so it’s only natural that they will ask for features so that solve them exactly. When you only have one customer the problem is contained – you are writing it just for them. Unfortunately, the more customers you have the more incompatible their requests become. You will eventually reach a point where 2 customers want completely the opposite thing. Adding all the features your customers want doesn’t scale – you can’t be everyone’s girlfriend. The further you go down the path of trying to please everyone; the more complex your product becomes, the harder it is to maintain, the harder it is to learn, the harder it is to use. Ultimately, you’ll please no one. Each feature must add to, rather than dilute, the value of your product to your entire community. Simply say no to the rest.

This philosophy will upset some customers, they may even go as far as to threaten to abandon your product. But, they bought your software for what it is now, they have already decided that what you offer is the best on the market – otherwise they would have taken their custom else where in the first place. Had you said yes to every feature earlier customers had requested you might not have won the customer who is now complaining!

It’s a difficult balance to strike, especially when you are starting out and grateful for every sale. But there comes a point when your product becomes bigger than any one customer. You must use your judgement and recognise your role as the software’s custodian; challenge the value of each feature so that your application stays focused on being the best in its niche rather than a poor product in many. If your goal is the best user experience then you must aspire to give your software the best features, not just the most.

“You know you’ve achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away”
–Antoine de Saint-Exupéry