The primary aim in creating software is to enable users to create, consume and manipulate available information. Treating users well by creating comprehensible visual designs (system images) is just as important when they are untrained and first encountering the software, as it is when they are familiar but discovering new functionality. Whether our intended audience is made up of casual users or experts, we succeed in creating communicative designs when those running our programs have a short learning curve and can comfortably locate and use core functionality. We fail when users have to open up crusty documentation files, search for tutorials and consult online forums for help; or worse yet, if we inspire worry that standard usage might produce unwanted results.
Producers and users of applications both undergo a subconscious process of forming conceptual understandings of how their software works. This simplified interpretation of a complex system is known as a mental model. While the user may pick out particular useful elements that have been given heightened importance, whether deliberately or accidentally, their mental model is understood as a gestalt in which the whole is greater than the sum of its parts.
When producers of software implement their designs, they form the design model. Ideally, they take into account the needs and desires of the user, but invariably there will be some disconnect between what they imagined initially and the system image they ultimately create. This gap can be exacerbated by low budgets, carelessness or a producer-centric mindset. Still, even the best designed system will result in a unique user model depending on who uses it. Consider that each user contributes their own set of preconceptions about software based on its similarity to previously used software. More significantly, users will assume functionality based on the software’s referential use of real-world interactions. With time, continued use of the product and, all too often trial and error, the user model is modified and gets closer to the initial design model.
Varieties of Users
Designers, engineers and other technical users often have an aura of confidence, navigating complex interfaces with ease and appearing to readily comprehend even the most obscure workings of software. Many believe that technical users’ seeming intuition is inherent and that there is something special about them. In truth, their learned comfortability is due to high levels of curiosity, patience and not fearing the consequences of pushing a system to its limit or beyond. Ultimately, technical users feel safe primarily because of their background – their mental model is at the outset much closer to the design model than the average user’s is.
Unlike their technical counterparts, average users approach software with caution. Unless the interface is carefully designed, the user will worry that they may cause harm to their data, or, though very unlikely, damage the device itself. (For most consumers, data loss is a real threat, and one that they are not sufficiently computer-literate to solve.) Don Norman, in his seminal book Design of Everyday Things, saw the danger of not taking into account these differing mental models in order to create a coherent system image and recognized that “a good conceptual model allows us to predict the effects of our actions, without a good model we operate by rote, blindly, we can’t appreciate what effects to expect or what to do if things go wrong.”
Take note that Norman uses the word ‘blind’ to describe the use of illegible system images. This is no accident. As will be explored more fully throughout Humanist Interface, the primary way we understand computers is spatio-visually. It is interesting to note Norman’s insistence that the computer be “invisible.” These two positions are certainly contradictory, but it must be near impossible to not experience some cognitive dissonance while attempting to be a practitioner of design while simultaneously holding the view that design should be disembodied.
Mental Model Projection
Technical software producers have an immense familiarity with the design models of software, with what can often be decades of experience with varying interface systems and platforms. Given this, they run the risk of myopically assuming that average users’ mental models have evolved to their same level of competence. The fact is that this is rarely the case. With never-ending updates to applications, operating systems and devices, even the most faithful technical users will inevitably run into new and unfamiliar design patterns. Since technical users do, in fact, expend significant effort to keep up with new developments, then regular users must struggle far more. It is thus inexcusable for software producers to ignore this disconnect between mental models and assume the user will just figure it all out.
A recent example of designers projecting their own mental models onto their users is the iOS software keyboard redesign from dimensional to modern minimalist. In earlier versions of iOS, realistic lighting, shading and expressive color were put to good use in order to differentiate the key states. In the modern minimalist interpretation on the other hand, the design was built on the assumption that multiple redundant, obvious and emphatic cues about the capitalization of text were excessive and unnecessary.
Many have been rightfully confused by Apple's new software keyboard design. Prior to iOS 7, the shift key was legible and you could determine what state it was in. Since the minimalist redesign, the shift key’s state looks exactly the same when activated as the rest of the deactivated keys on the keyboard. This has resulted in frustration even for power-users and developers in the community. Countless articles have been written about the topic, with one user putting up a website tutorial dedicated to helping users determine the state of the key. An independent developer has gone so far as to make a third-party keyboard to fix the problem. This developer advertised their keyboard with the humorous tagline: "The keyboard that fixes all the shift you hate." Another developer built a keyboard with only one feature, a fixed shift key. Their URL is shiftkey.fail.
Allen Pike, a former Apple employee and current iOS developer, wrote a blog post exclaiming that the iOS shift key is "the worst thing to happen in the history of software." Yet he hedged on this point and hastily returned to the 'law' of simplicity, "You can only be so negative towards it, because it's a great ideal: 'make something as simple as possible.' Sometimes in order to get as simple as possible, you need to go too far and say 'yeah that was too far and this is kinda dumb.'" Quite to the contrary, the existence of the original iOS keyboard proves that we knew all along how to make legible keyboards. Apple's making the iOS keyboard visually austere was absolutely unnecessary.
Somehow Apple remains steadfast about this decision to this day even with the release of iOS 8, an entirely new revision to their operating system. Something so core to the operation of a smartphone as its keyboard remains ambiguously designed.
What issue then do the modern minimalists have with the keyboard on iOS 6 and below? The problem for them is that the dimensional keyboard above uses metaphor to reference something real and tangible. In essence, it’s not abstract enough for their arbitrary sense of purity, thus it must be eliminated. Many designers, like Ed Chao of Dropbox, get cause and effect backwards: “The fact that this company has successfully moved from skeumorphic [sic] dominated designs to flat minimalism is evidence to me that the public has started to learn to go beyond obvious visual analogies to appreciate symbolism, subtlety and restraint.” Frank Chimero put it this way: “We’ve been living through that shedding process, and the interfaces of iOS 7 and Windows Metro suggest the keenness of our minds and our adeptness at navigating interfaces.” Jony Ive, the very person with final approval over the iOS keyboard, said that the reason iOS 7 turned flat was because he “understood that people had already become comfortable with touching glass, they didn’t need physical buttons.”
All who make this argument ignore that there are very few people who no longer benefit from overtly legible designs. Users have just been forced to suffer through ambiguous designs because there are effectively no alternatives on the market. It is in the nature of humanity to adapt. But the fact that users adapted to flatness says nothing about its relative value compared to expressive interfaces.
Users do not necessarily know that there are potential alternatives to the prevalent inexpressive and illegible flat designs. Nor do they know that these could be easily executed. Furthermore, the changes are not so abrupt that a user will explicitly notice dark patterns in a conscious way. Even if they could, they would not have the vocabulary to explain what was going wrong.
In no way should users be required to propose these alternatives. The truth is, users have better things to think about than what the most enjoyable and usable UI is, because that is ostensibly what designers are there to advocate for and produce. Users are thus easily swayed by marketing, because they trust that their interfaces are in good hands with industry designers.
Nevertheless, modern minimalists in the industry maintain a false belief that users have collectively evolved past the need for expressive user interface designs. They are consistently guilty of being unaware of, or worse, deliberately ignoring this gap between themselves as omniscient creators and the consumers who use their software.
When a user describes an interface as ‘simple’ they mean it is easy to understand and define a mental model. Modernist designers take this to mean that interfaces must be visually empty and contain as few elements as possible. Thus in their misguided push to reduce the ‘visual weight’ of system images, they end up imposing improper mental models on their users.
Norman, Donald A. The Design of Everyday Things. Reprint edition. New York: Basic Books, 2002, 13. ↩