These are some tips to try to keep in mind when designing workflows and interfaces in addition to the general concepts mentioned in the previous post.
- Always try to minimise the number of clicks and keystrokes required to perform a given task. Extra clicks and keystrokes are fine for more advanced items, but basic functionality and actions that are repeatedly performed need to be quick and easy to do.
- This one can be tough working in Microsoft environments since it is so easy to use the standard message boxes, but try to always avoid generic buttons like “OK”, “Cancel”, “Yes” and “No”. The buttons should really indicate the function they serve. Consider “Would you like to format your hard-drive? OK / Cancel” as opposed to “Would you like to format your hard-drive? Format / Don’t format”. This avoids people blindly clicking OK messages without reading them whenever they show.
- In general though, modal message boxes are best avoided, if at all possible. When they are used, ensure the correct notification icon is used with them: either the critical red cross, the warning yellow exclamation mark, the information i, or the question mark. I usually find the critical red cross is used inappropriately; it should only ever be used sparingly when the error is sufficiently scary, such as the inability to complete an essential task. Other minor errors should use the warning icon.
- Related to this is the use of exclamation marks in error messages. It looks extremely unprofessional, especially multiple exclamation marks!!! Exclamation marks are most often found in error messages, but they should generally be avoided throughout the software.
- Always try to use text in addition to icons when you have enough room available. Tool-tips aren’t always appropriate as a replacement for text since they have a delay before being shown. Icons aren’t meant to be used to portray meaning by themselves, they’re supposed to be used in conjunction with text to allow you to quickly pick out the option you want.
- On the other hand, icon design needs to be carefully considered so that it actually somewhat portrays the function without having to resort to reading the text. This may be a tough concept to balance, but especially when there is no room for text the icon must be obvious.
- An important thing to keep in mind when using colours is users who are colour-blind. Quite a large percentage of the population is colour-blind, so reliance on colour to convey meaning is bad for accessibility. NEVER rely solely on colour to differentiate one thing from another; always use a different icon or different text in addition to the different colour.
- As the guidelines posted previously say, always maintain any metaphors you’re using and keep concepts consistent across all designs. Mixing metaphors and inconsistent ideas can make a concept confusing for users.
- Try to make progress bars progress in a useful manner that represents the actual time the user will be waiting. Also avoid using decimal places for status (86.72% complete) as it starts becoming meaningless. Round numbers are fine, unless the operation is expected to take several minutes to complete 1%.
- On the subject of decimal places, always consider presenting numbers in a meaningful format. Unless the numbers are used for scientific purposes and need to be exactly accurate, it is more meaningful to the average person to present numerical information in common terms. For example, 4.2 km is more meaningful than 4.1973 km, or even 4197 m. 2 days, 7 hours is more meaningful than 2.586 days. You lose some accuracy but gain some understanding in your user.
- Avoid putting important messages in status bars. As a rule, avoid status bars altogether since no-one ever notices them.
- I’m not really a fan of having a bunch of functionality available only through the top menus. If possible I like to avoid menus altogether, but in overly-complex software they may be necessary. If you do feel they should be included, then make sure that all functionality available on the main interface has a counterpart in the menu bar as well, since a user will often scan through the menus when they can’t figure out how to do things (I feel the need to point out that this is why Office 2003’s expanding menus sucked so much, because you couldn’t scan them easily).
- On a similar subject, avoid putting vital functionality in only a right-click menu, and generally avoid essential right-clicks. Not only are right-clicks not intuitive, but on some devices such as Tablet PCs they are quite hard to perform. Right-click contextual menus are useful for advanced users, but again they are not intuitive so the functionality they provide should be mirrored in other parts of the interface as well.
Always remember that if technology is designed sufficiently well, it shouldn’t matter how “dumb” the user is. Communication is crucial so that the user knows what they’re doing at all times, but even experienced users make mistakes and they should be able to remedy those mistakes with relative ease. This is obviously tough to get right, but if a user does something “dumb”, consider why they may have done this and whether there is something that can be done in the design to avoid this in the future. Some procedures that you as a computer-savvy person may think to be trivial are not necessarily for users. For example, one of the customers I worked with in a previous job jammed a USB plug in the wrong way so hard that it broke the computer. Was the user dumb? Maybe, but the fact is that USB connectors look the same both ways, so there is a significant design flaw that contributed to the mistake. Now the shape of the USB plug is not something I can change, but just because we don’t have control over the design doesn’t mean we are powerless. We could provide tips and instructions in our software that guides users through tasks and highlights possible mistakes. When ready for a USB connection: “Connect the USB plug carefully, ensuring the pins line up. Do not force the plug.” Pictures could be used to reinforce the correct usage. Of course this isn’t guaranteed to avoid mistakes, but it would certainly help. The key is to not make tips and instructions too wordy, and avoid phrases that could be considered condescending (“insert the plug in the correct way”). Obviously this isn’t appropriate for all applications, but always keep the user in mind and how familiar they may or may not be with computers in general.
