“Predictable” means that the user, before performing an action, can imagine the results of that…

“Predictable” means that the user, before performing an action, can imagine the results of that action. As a side effect, the user can plan a whole series of actions. Predictability is important — users need to be able to focus on their actual tasks, instead of focusing on second-guessing the behavior of their tool.

UI designers have largely tried to increase predictability by implementing uniformity — individual widgets and groups of widgets look and behave in the same way regardless of which application they occur in. However, this only increases predictability when the behaviors are already familiar and both fully and properly understood — in other words, uniformity makes behavior predictable among power users and UI designers, but someone who uses a computer relatively rarely or only uses it for a relatively small set of tasks has no opportunity to learn the often-complex underlying general behavior that informs all the various specific (and often seemingly unrelated) ways that widgets behave in practice.

Understanding how (for instance) radio buttons work requires either familiarity with a lot of different radio button behaviors in a lot of different contexts (which is how power users learn) or being told the rules explicitly (which is how programmers and professional UI designers learn the specifics — they read documents like UI style guides that define rules that keep the interface uniform).

Interface uniformity, in other words, privileges the intuitions of experienced users. However, applications are intended to solve particular problems, and those problems have an underlying logic that informs how solutions to them are most easily and naturally expressed.

Applications that embrace the way that users already think about the problems they are meant to solve will be more easily understood and used by these users — whether these models are based on other existing software tools (such as older applications — seasoned users of some application are going to be more comfortable with a new application that behaves similarly), purely mental tools (like mathematical orthography — mathematicians are a lot more willing to use theorem proving software if that software doesn’t contradict their existing skills in reading notation), the important aspects of physical tools (while CD playing software does not benefit from skeuomorphic touches like a round volume knob, familiar conceptual touches like skip-forward and skip-back are vital; likewise, ebook reading software benefits from supporting highlighting, marginal notes, and multiple bookmarks), or widespread ideas or practices (tracking changes in documents, double-entry bookkeeping). Well-designed applications will embrace useful features that are already familiar to a non-technical end user even when such features don’t fit well into patterns that have been formalized in UI standards documents (for instance, good ebook-reading software should allow freeform hand-drawn notes to be drawn on top of the text, to simulate how many people draw in their books as part of active reading). Well-designed applications that solve problems that do not already have acceptably-good solutions will invent whatever UI habits make the use of that application efficient, even when it violate style guides.

Whether or not an application confuses someone who is never going to use it is irrelevant, so embedding widespread domain knowledge is an important part of this: an interface that lowers its initial learning curve at the cost of making it absolutely unusable by the folks for whom its function is vital is worthless outside of the context of introducing people to the field, and even then we are usually better off just teaching those users the principles necessary to use a more powerful version.

Usability for a professional looks very different from usability for an amateur, and both look very different from usability for an amateur who also has a deep familiarity with the UIs of unrelated applications. When we adopt totally uniform interfaces, we sacrifice the ability for self-described non-technical users to do important work in favor of making a demo feel non-threatening to power-users who have no familiarity with the problem domain.

One way to combat this is to make heavy modification of the behavior of systems accessible to these ‘non-technical’ users and allow them to adapt the applications they use to their own (potentially idiosyncratic) habits and models — in other words, to completely sacrifice the idea that UI designers have control over the look and feel of applications. (Technical users already take advantage of the customization available to them to create incredibly idiosyncratic work environments, and the concept of customization is not something one needs a computer science degree to understand — only the particular methods current software systems expose to make this customization possible.) The alternative is to work closely with a representative cross-section of actual users when designing interfaces (as is sometimes done with particular fringe types of professional software like circuit design systems, mostly because there’s a heavy intersection between the users and developers of these systems) and nevertheless fail in the 80% of cases that a user’s mental model or problem domain does not precisely match some statistical norm.

(All of this has been a summary of points I’ve made elsewhere. For clarification, I recommend reading my other posts on interface design.)