Usability evaluations (such as usability inspection and usability test) are helpful for identifying potentials for usability optimization. They reveal weaknesses that prevent user-friendly solutions, e.g. when user-system interaction is impaired.
There are several aspects that can be taken into account right from the start when designing a user interface, without feedback from usability evaluations being necessary. These “usability quick wins” can thus be realized early for laying the groundworks of a user-friendly solution. This can also be beneficial for potential usability evaluations that take place later in a project, because when certain usability problems are prevented right from the start, the usability evaluations can be focused more specifically on problems that are less easily detected or prevented.
Contrast
Insufficient contrast – especially between text and background – can impair usability, when legibility of critical information is impaired. Users then either fail to notice relevant information or efficiency is impaired when reading times are prolonged.
Problems like these can easily be prevented, e.g. by following basic visual accessibility guidelines. These guidelines shall ensure easy visual perception for people with impaired vision. But beyond that, also people with intact vision can benefit. Contrast ratios can easily be calculated with tools (e.g. WebAIM Contrast Checker) – including information whether the resulting contrast ratio satisfies the strict (AAA) or less strict (AA) accessibility requirements. It is recommendable to check text-background contrast ratios for critical information on the user interface and make required modifications in order to ensure optimal legibility.
Dual Coding
The principle of “dual coding” is related to visual perception of user interfaces, too. Perceiving visual information can be difficult for users when that information is color-coded only, e.g. when valid text entry in a field is visualized by green border color and invalid entry with red border color. This can obviously be problematic for people with a red-green blindness. But even “normal-sighted” people can have difficulties, e.g. depending on the calibration of their monitor or unfavorable lighting conditions in the room that impairs color perception. The dual coding principle says that important information shall never be conveyed by color only. There shall always be at least one additional code that supports perception when the “channel” of color coding fails. In the example given, where information regarding the validity of text entry shall be conveyed, one option can consist in employing symbols in addition to colors, e.g. a tick for “valid” and a cross for “invalid”. That way, users do not have to rely on color coding and can still decode the information.
Modeless Feedback
User interfaces provide feedback, e.g. to inform users regarding (un)successful input or the current status of data processing. Such feedback can impair the flow of interaction – and thus usability – when it is modal, i.e. when an explicit user action is required to return to “normal mode”, e.g. by confirming a feedback dialog.
Feedback shall thus be modeless where possible in order to keep interaction in “normal mode”. Examples for modeless feedback are information in windows’ status bars or using symbols next to entry fields, as described above, to indicate whether input is valid. In both examples, the user’s interaction with the interface is not impaired.
Feedback shall therefore be modeless as default, with a dedicated “justification” being necessary for using modal feedback. Modal feedback can, e.g., be justified when it is paramount that the user does under no circumstances ignore it because data would otherwise be lost. The rule of thumb therefore is: “Feedback shall always be modeless, except when it must be completely prevented from being ignored or perceived to late”.
Specific Button Labels
Dialogs that can either be confirmed or canceled are a user interface standard, e.g. when it comes to saving or discarding unsaved changes in a document that the user is about to close. It is still common to use the generic labels “OK” and “Cancel” for those buttons. This can result in usage errors, e.g. when users do not read the dialog text carefully and therefore gets the meanings mixed up. . If, e.g., a dialog reads “Do you really want to discard all changes?”, “OK” would be the “destructive” option, whereas “Cancel” maintains the data. In such a case, data loss can occur, when a user erroneously assumes that “OK” is the “good” option to be chosen when unsaved data shall be maintained.).
Button labels shall therefore be worded as specifically as possible for them to be clear even in cases in which users only scan a dialog text or don’t read it at all. Usually, it is possible to choose labels that are more specific than “OK” and “Cancel”, e.g. “Discard Data” and “Keep Data”. The guiding principle should be that the user can clearly understand the consequences of choosing a button from the label alone.
And Finally: Users Don’t Read
It has already been mentioned above and it is one of the facts that should be taken into account when designing user interfaces: users don’t read. This might be exaggerated in this absolute form – but not as much as one would think. It is actually the case that one should refrain from using extensive explanatory texts on a user interface, because it cannot simply be assumed that users will read them as carefully as would be appropriate. It is therefore generally not a good idea trying to resolve usability issues via providing explanation and help texts. Chances are that it will not work. For creating a user-friendly user interface is therefore recommendable to make a more limited use of descriptive texts and make it “self-descriptive” by adhering to principles of good user interface design – and, not least, by formative usability evaluations.
Conclusion
Keeping a few basic usability aspects in mind while creating a user interface does not render usability evaluations unnecessary. As shown in the examples, however, there are “quick wins” that can be realized during development without waiting for usability evaluation results. And this helps in creating a solid foundation for user interface development. Additional usability evaluations can then help in realizing additional usability optimizations that go beyond the already existing quick wins.