Often, one of the hardest goals to achieve in software development is to create user-friendly software systems that delight users. Over the years, there are a few key things we’ve noticed make all the difference. Below is the list:
1. Always optimize for fewer clicks – To a user in your software, the number of mouse clicks makes a huge difference – if a user has to click four times to do some action, they will be irritated. Don’t try to just solve their frustration with a keyboard shortcut that people won’t learn – try to give them a way to do everything they need to do with two clicks or less. At the same time, don’t take away the power users’ ability to use their keyboard – give them keyboard shortcuts if possible, and also make sure your tab order is set up properly 
so they can tab between controls. The most common actions in the system should be the most accessible – if there’s a feature they use less often, you can bury it a little more in the menus or navigation, but again, only under one menu if possible to reduce the clicks they’ll have to make to find it. Developers sometimes like to cheat by using wizards, but that just means that users will have to dig through ten steps in a wizard to get to the data they want quickly – which is a pain.
2. Give Helpful Error Messages – your error handling messages shouldn’t be opaque – users shouldn’t be a message like “Error 52” – the message should detail to the user what happened, and if possible allow them to automatically tell a support person that something went wrong. Users love to be able to figure things out themselves, avoiding the need to waste their time calling a support person, but they need more details about the cause of the error. Ideally, give them a list of “Things that could have gone wrong” if you know that a certain error occurs when a certain problem happens (such as the database being down). As a general rule, don’t let users see technical exception messages if possible as those sorts of messages can be scary and will cause them stress (indeed, some users will worry they have broken their machine or gotten a virus based on funky error messages).
3. Be Stingy with Real Estate – controls that are too spread out and on too many screens are just as bad as everything crammed on one giant screen. Really try to think of how you would want to use this if it was your job to go in every day and grab this data. If something doesn’t need to be listed on the screen, bury it deeper in the UI, or put it on a separate page that relates to the type of information it is showing. Remember that the best thing a software application can do for users is to provide them with actionable data or intuitive controls – the best systems that “win” at this might only have 3-4 pieces of information on the screen at a time. This allows the user to know what to do at a glance. Since it is often impossible to limit the data on the screen of a business application to that degree, think hard about what really matters. If clients tell you they just need “one big screen” push back and make sure they understand the risks and detriments to usability this might cause.
4. Make the UI Job and Task Focused – Are the controls laid out on the screen in a way that will let them accomplish their tasks they have to do for their actual, real-world jobs? Think about point of sale systems at retail stores and how many function keys they sometimes have to hit just to look up your name or issue a refund – I’ve seen them have to press 10 buttons just to print a new receipt. Those types of commands ought to be some of their most common actions, but they are buried in the mainframe interface. If you’ve got menus or navigation, organize by job and task and not by “type” of command. So for instance, consider the “File” menu. What does “File” mean exactly – things you do with a file within the software? If so, why does that menu always contain “Exit Program”? What about “Preferences” which is always located there too? A better menu name might be “Application” or something else that indicates that commands in this menu occur at the highest level of the pile of features in the software.
5. Don’t Do Cute – Users don’t appreciate distractions that don’t let them get their job done quicker. Paperclips, Siri, and other toys like that are harder to figure out than they seem, and usually its impossible to guess a user’s actions ahead of time enough to show useful “tips”. Also, we’ve seen it happen where people will start to dislike the software just
because they dislike the “cute” character. For instance, in one system we saw, there was a “spinning clock” icon that had a worried look on its face. Users hated this clock, because the fact that it was worried made them worry that something was wrong with the system! Cutesy messages in software, such as “Don’t Worry” or “Wheels are Spinning” are very unprofessional, and can add to frustrations users have when they seem flippant at a time that calls for seriousness.
6. Interrupt the user gently – People hate pop ups because they increase the number of clicks they need to make, and usually distract them from the task at hand. Options might be to interrupt the user with dialogs that go away on their own, or error messages “in line” like a validation error in red that they don’t have to click. Reserve pop up messages in modal dialogs for only the most adverse of issues – for instance, it is appropriate to inform the user via a modal pop-up that the system will be going offline in 10 minutes and they need to save their work, but popping up a modal dialog informing them of “The list of new features we deployed last night” is not only self-aggrandizing, but annoying and unnecessary (I only wish more SAAS software companies would realize this, as these types of popups are becoming more prevalent).
7. Obey Metaphors – if something looks like a disk, it should save. If it looks like an arrow it should take you somewhere. These sort of visual cues are a part of “metaphors” in the software, which are visual elements that give us clues as to how a feature is going to perform. Best practices call for using subtle visual indicators to show people where to click, or using highlighting, colors or shadows to make it easier to tell what is a button (and therefore clickable) and what is a label (and therefore read-only). If something is a link or a button that a user can click, it should never have to say “Click Here” next to it – it should be obvious from the look and feel of the control that it is clickable.
While this list surely isn’t the comprehensive list of everything it takes for software to be user-friendly, we think there are a few key things in there that people often miss. We hope it’s useful to you or at least makes you think!
