Published 05 Sep 2014
"The following principles are fundamental to the design and implementation of effective interfaces, whether for traditional GUI environments, the web, mobile devices, wearables, or Internet-connected smart devices."
These principles of interaction, created by Bruce Toganazzini, are used by many usability professionals as heuristics for Heuristic Evaluation and Cognitive Walkthroughs of user interfaces.
Allthough these principles have been around a long time Tog recently revised them and added more details and examples. You should definitely also check out the source site to get even more details.
Generating artificial obsolescence through fashion is a time-honored and effective way to sell everything from clothing to cars. A new fashion should not and need not detract from user-performance: Enormous visual and even behavioral changes can be carried out that either do not hurt productivity or markedly increase it.
User test after aesthetic changes have been made, benchmarking, where applicable, the new design against the old. Ensure that learnability, satisfaction, and productivity have been improved or at least have stayed the same. If not, newly-added aesthetics that are causing a problem need to be rethought.
Software and hardware systems should attempt to anticipate the user’s wants and needs. Do not expect users to leave the current screen to search for and collect necessary information. Information must be in place and necessary tools present and visible.
Anticipation requires that designer’s have a deep understanding of both the task domain and the users in order to predict what will be needed. It also requires sufficient usability testing to ensure the goal has been met: If a tool or source for information is there on the screen, but users can’t find it, it may as well not even be present.
The penalty for failing to anticipate is often swift and permanent, particularly if you do not have a captive user, as is the case with public websites and apps, for example. Those users will probably never return from their search. Even if you do have a captive user, you probably don’t have a captive client, and if the client’s employees are wasting time trying to find required resources, your competitors will have a good story to tell when it is time to make their next pitch.
Give users some breathing room. Users learn quickly and gain a fast sense of mastery when they are placed “in charge.” Paradoxically, however, people do not feel free in the absence of all boundaries (Yallum, 1980). A little child will cry equally when confined in too small a space or left to wander in a large and empty warehouse. Adults, too, feel most comfortable in an environment that is neither confining nor infinite, an environment explorable, but not hazardous.
Autonomy means users get to decide what keyboard they want to use, how they want their desktops to look (even if they like clutter), and what kind of apps they want to run. When developers take that kind of control away, users can be left frustrated and angry.
Allowing users latitude does not mean developers should abandon all control. On the contrary, developers must exercise necessary control. Users should not be given so much rope they hang themselves. However, some developers today are not only taking excessive control, but making huge HCI errors in the process, like restricting text to fonts and sizes that people with ordinary eyesight can’t read. They offer editing schemes that require the user to use their fat finger to place the text cursor with pixel-precision accuracy just to avoid adding the necessary arrow keys to their aesthetically perfect, but functionally crippled, keyboard.
They also set an arbitrary timing and movement threshold for determining whether a user is or is not pressing a link on purpose, rather than her just pausing for an instant at the start of an upward swipe for scroll, for example. They then offer the user no way to alter that threshold, so many users find themselves triggering links to unwanted pages many, many times per day. That is an irresponsible application of control. We learned 30 years ago that users needed access to a slider for mouse double-clicking. Touch users need the same thing for link timing.
No autonomy can exist in the absence of control, and control cannot be exerted in the absence of sufficient information. Status mechanisms are vital to supplying the information necessary for users to respond appropriately to changing conditions.
Users should not have to seek out status information. Rather, they should be able to glance at their work environment and be able to gather at least a first approximation of state and workload.
Status information can be up to date, yet inaccurate. At the time of this writing, when a user updated an iPhone or iPad to a new generation of system software, a progress indicator would appear showing that it will take approximately five minutes to complete the task. Actually, it typically takes an hour or more. (The new system itself would update in five minutes, but then all the other tens or hundreds of megabytes of information on the phone had to be re-uploaded.) The user, having been lied to, was left with no way to predict when she might actually get her device back. Such a user is not feeling autonomous.
Most people have color displays nowadays. However, approximately 10% of human males, along with fewer than 1% of females, have some form of color blindness.
Search Google for simulation tools. For example, for websites, you might try http://enably.com/chrometric/. For images, http://www.colblindor.com/coblis-color-blindness-simulator/.
Color is a vital dimension of our limited communication abilities. Stripping away colors that a person who is color blind can’t see does no more for that person than turning off the entire picture does for a person who is completely without sight. It’s the presence of an alternate set of cues for that person that is important.
Generating artificial obsolescence through fashion is a time-honored and effective way to move products from clothing to cars. A new fashion should not and need not, however, detract from user-performance. User test after making aesthetic changes, benchmarking the new design against the old. Ensure that learnability, satisfaction, and productivity have improved or at least stayed the same. If not, newly added aesthetics that are causing a problem need to be rethought.
The following four consistency principles, taken together, offer the interaction designer tremendous latitude in the evolution of a product without seriously disrupting those areas of consistency most important to the user.
The following list is ordered from those interface elements demanding the least faithful consistency effort to those demanding the most. (Many people assume that the order of items one through six should be exactly the reverse. This can lead to real confusion as users confront pages that look familiar, but act completely different.)
Top level consistency
Platform consistency: Be generally consistent with de jure & de facto standards
In-house consistency: Maintain a general look & feel across your products/services
Communicates brand and makes adoption of your other products and services easier and faster
Consistency across a suite of products, e. g., Microsoft Office
General look & feel communicates family
The overall look & feel of a single app, application or service–splash screens, design elements, etc.
A visual designer should establish a purposeful & well thought-through visual language, shaped by usability testing. User behaviors should be fully transferable throughout the product.
Small visible structures, such as icons, symbols, buttons, scroll bars, etc.
The appearance of such objects needs to be strictly controlled if people are not to spend half their time trying to figure out how to scroll or print. Their location is only just slightly less important than their appearance. Where it makes sense to standardize their location, do so.
Invisible structures refers to such invisible objects as Microsoft Word’s clever little left border that has all kinds of magical properties, if you ever discover it is there. It may or may not appear in your version of Word. And if it doesn’t, you’ll never know for sure that it isn’t really there, on account of it’s invisible. That is exactly what is wrong with invisible objects and why, if you insist on using them, rigid consistency becomes so important.
Apple apparently thought this was a good idea and started copying Microsoft by adding invisible controls from scroll bars to buttons everywhere. The situation on the Mac got so bad that, by the early 2010s, the only way a user could discover how to use many of the most fundamental features of the computer was to use Google to search for help. (For more, see: Discoverability)
Some objects while, strictly speaking, visible, do not appear to be controls, so users, left to their own devices, might never discover their ability to be manipulated. If you absolutely insist on disguising a control, the secret rule should be crisp and clean, for example, “you can click and drag the edges of current Macintosh windows to resize them,” not, “You can click and drag various things sometimes, but not other things other times, so just try a lot of stuff and see what happens.”
Objects that convey information, rather than being used to generate information, should rarely, if ever, be made invisible. Apple has violated this in making the scroll bars on the Macintosh invisible until a user passes over them.
Interpretation of user behavior
Changing your interpretation of a user’s habitual action is one of the the worst things you can do to a user. Shortcut keys must maintain their meanings. A learned gesture must be interpreted in the standard way. If the button that carries the user to the next page or screen has been located at the bottom right for the last 30 years, don’t move it to the top right. Changes that require a user to unlearn a subconscious action and learn a new one are extremely frustrating to users. Users may not even realize what has happened and assume that something has failed in their hardware or software.
If you want to attract existing users of someone else’s product to your product, you should try to interpret your new user’s commands in the same way by, for example, allowing them to reuse the same shortcut keys they’ve grown used to.
Make objects that act differently look different. For example, a trash can is an object into which a user may place trash and later pull it back out. If you want to skip the “and pull it back out” functionality, that’s fine. Just make it look like an incinerator or shredder or anything other than a trash can.
Make pages that have changed look changed. If someone encounters an unfamiliar page on an updated website or in a revised app, they know to look around and figure out what’s different. In the absence of such a cue, they will attempt to use the page exactly as they have always done, and it won’t work.
If you come out with a completely re-worked area of your product or even a completely new product, it is important that people instantly recognize that something big has changed. Otherwise, they will jump into trying to use it exactly the way they always have and it just isn’t going to work. “Uniformity” would mean that your next product would be identical to your last, clearly wrong, but “consistency” is little better in a field where so much growth will continue to take place. Our goal is continuity, where there is a thread that weaves through our various products and releases, guiding our users, but not tying us to the past.
It doesn’t matter how fine a logical argument you can put together for how something should work. If users expect it to work a different way, you will be facing an uphill and often unwinnable battle to change those expectations. If your way offers no clear advantage, go with what your users expect.
When a user activates a field, the current entry should be auto-selected so that pressing Backspace/Delete or starting to type will eliminate the current entry. Users can click within the field to deselect the whole, dropping the text pointer exactly where the user has clicked. The select-on-entry rule is generally followed today. (Sloppy coding, however, has resulted in the text cursor dropping at various unpredictable locations. )
Not everything should have a default. If there isn’t a predictable winner, consider not offering any default. It takes precious cognitive cycles to look at a default that covers maybe 25% of the cases and make the decision not use it. That same time could be spent entering the choice actually desired.
Users rarely have any idea of what “Default,” in a given situation means. (They do know its literal meaning, of course, which is that the bank is going to take away the user’s house. That always cheers them up.) Replace “Default” with “Revert to Standard Settings,” “Use Customary Settings,” “Restore Initial Settings,” or some other more specific terminology describing what will actually happen. User test to find out what terms enable your users to accurately predict what your software will actually do.
Make sure, through user testing, that users understand the extent of the restoration: Are they signing up to a benign restoration of just a few recent and localized items, or are they about to spend the next four days re-entering usernames and passwords in every app they own?
User-test your restoration options to find out what users think the result of pressing the button will be. If you are going to do something benign, but they interpret it as potentially destructive, they won’t use the option, leaving them with the same broken or partially broken system that made them consider using it in the first place. Likewise, if you wipe out hours of careful customization without properly preparing them, they may not be nearly as grateful as you might expect. (I once had a young chap in India help me out with a minor problem on my DVR. When he was finished, he had led me to reinitialize the hard disk, erasing every single program on the machine. That was a bit more restoration than I was looking for. After that, I was able to carry out the rest of my conversation with him without even using the phone. I had no idea I could yell that loud.)
When designing tabbed objects, such as properties and preference windows, ensure that the visual design makes the scope of a restoration button clear. Individual tabbed “cards” should be visually separated from the surrounding window so that buttons may be placed either within the individual card or in the surrounding area, indicating whether the button action will apply only to the current tab or all tabs. There is never an excuse for leaving such a scope ambiguous. This is not a fashion decision.
Functional software does not have to look like a tractor; it can look like a Porsche. It cannot, however, look like a Porsche that’s missing its steering wheel, brake, and accelerator pedal. Yet many tech companies in the late 1990s began purposely hiding their most basic controls, often to the serious detriment of their users. Why? Because they found it more important to generate the Illusion of Simplicity for potential buyers than to reveal the extent of complexity to their actual users.
Businesses are driven to hide complexity from buyers because it can pay off in the short term: Most consumers who are potential buyers make judgements as to whether they can conquer a new machine not by sitting down and spending a day trying to learn it, but by gazing at the screen for ten minutes while the salesperson gives a demo. Stripping away scroll bars, hiding buttons, doing all the things that this section tells you not to do can all lead to increased profits, at least in the short term.
You need never decide whether to support potential buyers or eventual users. We are not working with fixed pieces of hardware. We work with either pure software or hardware driven by software. A designer can easily create a system that will fully support both buyer and user, switching appearance depending on current need. You can design the software for an operating system, for example, that will present itself in a very simple form in the store only to slowly open up like a flower, offering the user more and more accessibility and functionality as the user becomes progressively more skilled and more comfortable.
Crippling an interface might help make the initial sale, but in the long run, it can lead to having your most important “sales force,” your existing customer base, not only leave you, but tell your potential buyers to stay away as well.
Not all buyers are naive. Even those that are don’t stay that way long. Only the most persistent buyers/users will travel the web searching for a treasure map to features that you choose to hide from them. Most will simply turn to your competitors, taking you at your word that you just don’t offer whatever they were after.
With Active Discovery, you cease waiting for people to find something and, instead, offer it to them. In its ideal form, your system “realizes” they now need it and offers it to them. In most instances, we are far from being able to do that. A workable compromise:
The messaging might take the form of a “Did you know…” hint that you show during startup. (If you see a large percentage of your users are turning off these hints, it reflects that you are prematurely mentioning features, are giving them too many hints too often, or continue to tell them about features they have adopted. It is not necessary to give a helpful hint each and every time the user starts up your app. They are more likely to be read and appreciated if they occur on occasion.
The object itself should either be view or enclosed by an object or series of objects (documents within folders, menu items within a menu, for example) that, in turn, are visibly accessible at all times.
Exceptions can be made for systems that are used habitually, such as a mobile browser or reader, where:
These exceptions cover standard and widely-used operating system objects and behaviors on mobile devices, as long as users are given simple and obvious access to a help guide for using them.
A few designers, having fallen in love with the clean lines of smartphone apps, thought it would be great to visit those same clean lines on giant-screen computers. Wrong! Hiding functionality to create the Illusion of Simplicity is an approach that saps user-efficiency and makes products an easy target for competitors.
Smartphone and tablet controls are sometimes forced into the content area because the screens are so small, that’s the only area there is. Even there, you need to provide a standard trigger, such as a tap in the middle of the content area, that will simultaneously expose all the icons and buttons representing all the hidden controls so that users don’t have to carry out a treasure hunt.
On laptop and desktop computers, controls, and, in particular, hidden controls have no place inside the content area.
Include a help page that shows the gestures your app can understand. Present the page when the user first opens the app and make it clear where the user will find this help page after that. In a mobile app, make the icon representing the page constantly visible or have it form part of the standard set that appears around the periphery when the user touches the triggering area of the mobile screen. For a magazines and similar media objects, make it the first open page (after the cover) of each and every issue, always there and available.
It is not 1980, when most people had never seen a computer, and we necessarily made everything highly visible. You can use subtly in design: Don’t put an info icon next to every single item on the page. Instead, use overlays like this one from Google+ Snapseed that explain every symbol and every gesture at once:
t is difficult to see with the overlay in place, but the developers have reinforced their Cancel and Apply arrows with permanent, written labels. How do you find out if such reinforcement is necessary? How do you find out whether the user can figure out what to press (in this case, an always-visible question mark at the extreme top right) to get help to begin with? Follow the next principle and apply the results.
To discover what information you need to communicate and to ensure you’re successfully communicating it, you must do routine usability tests throughout a project. Test using a population that has your expected level of experience with the system and task domain. See if they can locate, identify, learn, and use the tools they need to perform the tasks you expect your users to perform. If they cannot, iterate the design until they can. Make use of Active Discovery, Dealer Modes, whatever you need to to ensure your users can discover and learn the features of your product.
Not one of the errors I’ve discussed above would ever make it into production were user-experience groups conducting usability studies and altering the design based on those results.
In judging the efficiency of a system, look beyond just the efficiency of the machine. People cost a lot more money than machines, and while it might appear that increasing machine productivity must result in increasing human productivity, the opposite is often true. As a single example, forcing customers to enter telephone numbers without normal spacing or punctuation saves a single line of code and a handful of machine cycles. It also results in a lot of incorrectly captured phone numbers as people cannot scan clusters of ten or more digits to discover errors. (That’s exactly why phone numbers are broken up into smaller pieces.) The amount of time wasted by just one person in your company trying to track down the correct version of an incorrectly entered phone number would sweep away the few minutes it would have taken to code the entry form so users could scan and correct their errors. Wrong numbers also can and do result in a lost sales. How many trillions of machine cycles would the profit from a single lost sale have covered?
Typically, the highest expense by far in a business is labor cost. Any time an employee must wait for the system to respond before they can proceed, money is being lost.
Large organizations tend to be compartmentalized, with each group looking out for its own interests, sometimes to the detriment of the organization as a whole. Information technology departments often fall into the trap of creating or adopting systems that result in increased efficiency and lowered costs for the information resources department, but at the cost of lowered productivity for the company as a whole. It is your job to run the studies that prove out whether new designs based on new, money-saving technologies will increase or decrease overall productivity among the affected workers and, if so, by how much and with what result to the corporation’s bottom line.
Work with HR or department heads to find out the average cost per hour of affected employees. (An honored rule of thumb is to take their hourly wage and multiply it by three to include all the other overhead associated with an employee, from rent to heat, lights, computer support, etc.) Multiply the overhead cost x the number of affected employees x the time an activity takes x the difference in productivity, positive or negative, in carrying out the activity to find the actual cost of a change. A positive number will help you sell your group and your design. A negative number will help your company from making a costly mistake.
This simple truth is why it is so important for everyone involved in a software project to appreciate the importance of making user productivity goal number one and to understand the vital difference between building an efficient system and empowering an efficient user. This truth is also key to the need for close and constant cooperation, communication, and conspiracy between engineers and human interface designers if this goal is to be achieved.
Look at the difference between the iPad and the netbook computers it crushed. The differences had nothing to do with what key you pressed to open an email. They had to do with things like not having to press any key at all.
Error messages must be written by a skilled writer to:
“Error -1264″ doesn’t do any of these. Rare is the error message that covers even Point One well. Yours should cover all three. Your Quality Assurance group should be charged with the responsibility for reporting back to you any message that does not fulfill the criteria.
Many other principles in this list affect efficiency, Latency Reduction and Readability in particular.
Mimic the safety, consistency, visibility, and predictability of the natural landscape we’ve evolved to navigate successfully. Don’t trap users into a single path through a service, but do offer them a line of least resistance. This lets the new user and the user who just wants to get the job done in the quickest way possible a “no-brainer” way through, while still enabling those who want to explore and play what-if a means to wander farther afield.
The earlier your users are on the experience curve, the more you need to guide them. A single-use application for accomplishing an unknown task requires a far more directive interface than a habitual-use interface for experts. The deepest ruts are wizards.
Stable visual elements not only enable people to navigate fast, they act as dependable landmarks, giving people a sense of “home.” A company logo on every page of a website, including every page of checkout, all enabling the user to escape back to the home page, makes users feel safe and secure. Paradoxically, such cues make it more likely that people will not escape back to the home page, secure in the knowledge that they easily can.
People explore in ways beyond navigation. Sometimes they want to find out what would happen if they carried out some potentially dangerous action. Sometimes they don’t intend to find out, but they do anyway by accident. By making actions reversible, users can both explore and can “get sloppy” with their work. A perfect user is a slow user.
The unavoidable result of not supporting undo is that you must then support a bunch of confirmation dialogs that say the equivalent of, “Are you really, really sure?” Needless to say, this slows people down.
If you fail to provide such dialogs, in the absence of undo, people slow down even further. A study a few years back showed that people in a hazardous environment make no more mistakes than people in a supportive and more visually obvious environment, but they work a lot slower, taking great care to avoid making errors. The result was a huge hit in productivity.
We usually think of the absence of Undo as being the sign of lazy programming, but sometimes people do it on purpose. For example, some ecommerce sites want to make it hard for you to take things back out of your shopping cart once you’ve put them in there. This turns out to be a backwards strategy: An ecommerce study we did at the Nielsen Norman Group looked at what happens when merchants make it really easy to take things out of shopping carts. As might be expected, people visiting these merchants were much more willing to throw things in, figuring, “oh, well, I can always take it back out later.” Except they didn’t take them back out, because the deletion rate was no different. These user just bought more stuff.
Users should never feel trapped inside a maze. They should have a clear path out.
Use large objects for important functions (Big buttons are faster). Use small objects for functions you would prefer users not perform.
Use the pinning actions of the sides, bottom, top, and corners of your display: A single-row toolbar with tool icons that “bleed” into the edges of the display will be significantly faster than a double row of icons with a carefully-applied one-pixel non-clickable edge between the closer tools and the side of the display. (Even a one-pixel boundary can result in a 20% to 30% slow-down for tools along the edge.)
While at first glance, this law might seem patently obvious, it is one of the most ignored principles in design. Fitts’s law (often improperly spelled “Fitts’ Law”) dictates the Macintosh pull-down menu acquisition should be approximately five times faster than Windows menu acquisition, and this is proven out.
Fitts’s law predicted that the Windows Start menu was built upside down, with the most used applications farthest from the entry point, and tests proved that out. Fitts’s law indicated that the most quickly accessed targets on any computer display are the four corners of the screen, because of their pinning action, and yet, for years, they seemed to be avoided at all costs by designers.
In attempting to “Fittsize” a design, look to not only reduce distances and increase target sizes, but to reduce the total number of targets that must be acquired to carry out a given task. Remember that there are two classes of targets: Those found in the virtual world—buttons, slides, menus, drag drop-off points, etc., and those in the physical world—keyboards and the keys upon them, mice, physical locations on touch screens. All of these are targets.
Fitts’s Law was not repealed with the advent of smartphone or tablets. Paul Fitts, who first postulated the law in the 1940s, was working on aircraft cockpit design with physical controls, something much more akin to a touch interface rather than the indirect manipulation of a mouse. The pinning action of the sides and corners will be absent unless the screen itself is inset, but the distance to and size of the target continue to dictate acquisition times per Fitts’s law just as always.
Like so much in the field of human-computer interaction, you must do a timed usability study to test for Fitts’s Law efficiency.
Human-interface objects are separate and distinct from the objects found in object-oriented systems. Our objects include folders, documents, buttons, menus, and the trashcan. They appear within the user’s environment and may or may not map directly to an object-oriented program’s object. In fact, many early GUI’s were built entirely in non-object-oriented environments.
Human interface objects that can be seen are quite familiar in graphic user interfaces. Objects that are perceived by another sense such as hearing or touch are less familiar or are not necessarily recognized by us as being objects. Ring tones are auditory objects, for example, but we tend to just think of them as ring tones, without assigning any higher-level category to them.
Buttons are pressed, sliders are dragged, etc.
Dropping a document on a trash can does not delete it, it stores it in the trash can. Selecting “Empty Trash” is necessary to actually delete it.
If dropping a document on your delete-document icon will destroy it instantly and permanently, do not make it look like a trash can. People come with expectations about previously encountered objects. It’s important not to confuse or water down such expectations. For example, if you use a trash can icon, but instantly destroy documents dropped into it, it broadens the rule for trash cans. Instead of the rule remaining: “Dropping a document on a trash can does not delete it. Rather, it stores it in the trash can. Selecting ‘Empty Trash’ is necessary to actually delete it,” it will shift to, “Dropping a document on a trash can will destroy it either right now or sometime in the next six months to a year.” That is not only confusing for your users, it is damaging to every other developer that uses the trash can icon in the proper way.
Latency can often be hidden from users through multi-tasking techniques, letting them continue with their work while transmission and computation take place in the background. Modern web browsers can pre-fetch data, reducing the dead time when the user reaches the end of a task and must wait for the next page to appear.
Because the Internet is slow, people tend to press the same button repeatedly, causing things to be even slower.
Eliminate any element of the application that is not helping. Be ruthless.
The sluggish speed of the early web set users’s expectations extremely low. (It also burst the Internet bubble when people realized they could get in their car and drive round-trip to the shopping center in less time than it took to “trick” the website into selling them something.) They have become less forgiving as time has passed.
Mobile, which has an architecture more in keeping with traditional GUI applications than web browsing, has been reminding people that computers can be fast, and they are even more impatient with slow-downs. Wearables will come with an even higher level of expectation: No one waits to see what time it is, and they will not wait to see who is calling, what the temperature is outside, or any other information to be displayed.
Automotive applications today are oftentimes sluggish, suffering from a fatal cocktail of weak hardware, poor design/coding practices, and high latency. Consider the car hurtling down the road at 88 feet per second (27 meters per second) while the user, eyes fixed on the flat panel display, waits to learn which of ACDC’s many fine works he’s currently enjoying. Imagine the rich irony when the accident report reveals it was “Highway to Hell.”
Ideally, products would have no learning curve: Users would walk up to them for the very first time and achieve instant mastery. In practice, however, all applications and services, no matter how simple, will display a learning curve.
Learnability and usability are not mutually exclusive. First, decide which is the most important; then attack both with vigor. Ease of learning automatically coming at the expense of ease of use is a myth.
How do you decide whether learnability or usability is most important? The first thing you must do is identify frequency of use: Are you working on a product or service that will be used only once or infrequently, or is it one that will be used habitually? If it’s single-use, the answer is clear: Learnability. If someone will use this every day, eight hours a day for the rest of his or her life, the answer is equally clear: Usability.
Next, who is the buyer? If the person who will use it habitually will also make the buying decision, a product’s reputation for learnability may be a key factor in making the sale. That’s why you want to identify the most important of the two, then attack both.
Much usability testing involves running a series of tests at regular intervals with your spending only 20 minutes to an hour with each subject you recruit. You end up knowing everything about the initial learning curve and nothing about either the long-term curve or the end-state level of productivity.
If you are working on an application that will be used habitually, go about it entirely differently: Work with HR to hire temporary workers. Then, have them spend a week or two coming up to speed on the interface, monitoring them with time tests to see what the overall learning curve and the eventual efficiency of your interface actually prove out to be.
Good metaphors generate in the users’ minds a strong series of connections to past experiences from the real world or from a previous cyberspace encounter, enabling users to form a fast and accurate sense of your system’s capabilities and limitations.
Try making your concepts visually apparent in the software itself. If that proves impractical, make it visual apparent through an illustration. The illustration should be compact and meaningful. Test it to see if it works, then embed it in such a way that every user that needs to see it will see it.
Most metaphors evoke the familiar, but can and usually should add a new twist. For example, an electronic newspaper might bear a strong resemblance to a traditional paper, but with hyperlinks than enable users to quickly dive as far into articles as their interest drives them, something quite impossible with their paper counterparts. Not only is there no need to slavishly copy a real-world object (skeuomorphism), but unnecessarily limiting the functionality of a software counterpart just to “perfect” the imitation is most often bad design.
The inverse of skeuomorphism is abstraction, a prominent feature in so-called flat design, a fashion that took hold in 2013, turning once well-understood icons and other elements into meaningless abstractions and even false symbols. (For example, the icon for the browser on the iPhone became a compass, only connected to the concept of the web through the vaguest of abstractions. The iPhone has an actual compass, so they turned its icon into… another compass! Two compass icons: One tells you which way is north and the other connects you to your bank account. The Settings icon had originally looked like the inner workings of a clock, clearly carrying the message that this is an app that will let you see and affect the inside workings of the iPhone. That was abstracted to the point that it looks exactly like a large industrial fan.)
A metaphor is intended to empower your user. However, there are times when it can also hold back your design.
This principle is all but absolute. Users should not lose their work as a result of error on their part, the vagaries of Internet transmission, or any other reason other than the completely unavoidable, such as sudden loss of power to a client computer without proper power protection. We’ve gotten so used to being the victim of data loss that we often don’t even notice it. So consider if what happens routinely on the web happened in real life:
You go into Harrod’s Department Store in London. After making your selections, you are asked to fill out a four-page form. A gentleman looks the form over, then points to the bottom of Page 3 at your phone number. “Excuse me,” he says, “Look there. See how you used spaces in your phone number?” When you nod, he continues, “We weren’t expecting you to do that,” at which point, he picks up the four-page form and rips it to shreds before handing you a new, blank form.
Of course, never in a thousand years would such an event take place at Harrod’s, but another venerated British institution did exactly that to me almost twenty years into the miracle of the world wide web when I was invited to give them my emergency contact information for an upcoming flight into London. Every time I would fill out all eight fields on the form, it would come back with an error message about at least one field, having destroyed the entire contents of all eight of them! I’m sure it was carrying out this wanton destruction for my own good, but I could not for the life of me figure out from the messages what it actually wanted. 20 minutes and two browsers later, I gave up. I’m sure other passengers are abandoning their effort far earlier.
Travel sites, in general, think nothing of repeatedly tossing all the information the user has entered about cities, times, days of travel, frequent flyer numbers, anything that takes time and trouble to type in. The user may attempt nothing more radical than leaving a half hour later, but that is apparently grounds to destroy their choice of departure city and date as well as arrival city and date. If the user is impolite enough to go to the bathroom, well, that sort of activity poses a significant security risk, so of course their entire evening’s work must be destroyed, with a message explaining its been done for their own good.
Travel sites may be the tip of the iceberg, but websites in general, are notorious for their cavalier attitude when it comes to their user’s hard work, and it doesn’t stop there: Traditional applications continue to crash and burn, and the excuses for entire computer systems crashing and burning are at an end. Small portables can survive a power outage. It’s no longer acceptable that many of today’s high-end desktop computers and operating systems still do not support and encourage continuous-save. That, coupled with a small amount of power-protected memory, could eliminate the embarrassment of $5000 machines offering less reliability than 10-cent toys.
Favor black text on white or pale yellow backgrounds. Avoid gray backgrounds.
You must demand of your marketing people that they tell you what the expected range of your customer’s standard displays will be. You then need to work with your graphic design and engineering people to ensure that your code will show up in appropriate sizes across that range of displays. It need not be one-size-fits-all. For example, CSS can mold itself to the system in which it finds itself.
For example, the label, “Last Name,” can afford to be somewhat small. Habitual users will learn that that two-word gray blob says “Last Name.” Even new users, based on the context of the form on which it appears, will have a pretty good guess that it says “Last Name.” The actual last name entered/displayed, however, must be clearly readable. This becomes even more important for numbers. Human languages are highly redundant, enabling people to “heal” garbled messages. Numbers, however, unless they follow a very strict protocol, have no redundancy, so people need the ability to examine and comprehend every single character.
Experienced users read only as much of an item name to differentiate among items. Highly experienced users actually trigger on the difference in the external shapes of the entire first word(s) without ever actually reading anything.
Presbyopia, the condition of hardened, less flexible lenses, coupled with reduced light transmission into the eye, affects most people over age 45. Do not trust your young eyes to make size and contrast decisions. You cannot.
Specifically, anti-aliasing softens the edges of a font, giving it a much smoother appearance on the digital page. The problem is that the human vision system responds to sharp edges, so, in smaller font sizes, an anti-aliased font, while often appearing more attractive, can be quite difficult to comprehend.There are anti-alias techniques that specifically increase the sharpness of the edges the eye is seeking, so this is not strictly a black and white issue (so to speak), but it is definitely something of which you should be aware and not something in which every graphic designer has been schooled. You will want to run some reading speed and comprehension tests on proposed font changes.
As designers, we need to strive to simplify users’ lives. That often requires a delicate balance between our effort to make installation of a product easier and making subsequent use of that product easier or better.
Consider the autofill feature for browsers: The user is required to enter and maintain a database of information the browser can then drop into a form at the user’s command. It takes time to set it up, and every time anything changes, it’s just one more record that has to be altered. What’s more, it often fails to work, either not responding or putting incorrect data all over the place.
Apple has simplified the setup process by enabling the user to link Safari’s autoFill to the user’s contact card in his or her address book. However, the ability of Safari to actually fill out a form is just as dismal as it’s ever been, largely because there is no standardization of labels, locations, or anything else in forms.
I have solved the autoFill problem with a more technically complex solution: I use an app called Keyboard Maestro that sits in the background looking for certain key combinations. When it finds one I’ve programmed, it automatically replaces the text I’ve typed with a string of text I’ve previously stored. Setup was definitely more difficult, but now when I open a form and a field calls for my first name, I type, “bbbb” and it’s replaced with “Bruce.” I type “aaaa” and my address appears, “pppp” and my phone number pops into place, etc. It takes me 30 seconds to fill out a form, longer than autoFill would if it actually worked, but this method works on every single form every single time. It saves me time, effort, and frustration.
Often, you can assume that one user in the house will be technically inclined. When you have a trade-off between simplicity of installation/set-up and ease-of-use, get together with your marketing people. If they tell you that you can depend on at least one reasonably clever or sophisticated user, do make life a bit more difficult at first if it will make subsequent use a lot simpler for everyone else. However, expend effort making both installation and operation as simple as possible. That’s the approach that Nest took, where one person in the house must go through a complex and confusing process to tie their products to the Internet, but thereafter the lives of everyone in the house become simper.
(In Nest’s defense, they are doing their best to overcome a major flaw in the way Wi-Fi set up to work. It requires users to leave their normal Wi-Fi and log in to a new “network” with a gobbledygook name which is, in fact, their Nest device. This is a weird, backwards activity that throws most users the first time they encounter it. It also requires their going into the “basement area” of their phone or tablet, a place most users avoid whenever possible. It’s all-around bad, and the committees that oversee the Wi-Fi protocol need to address the issue if connected devices are to take off on an expanded basis.)
In the early years of this century, Apple became so focused on generating the illusion of simplicity for the potential buyer that they began seriously eroding the productivity of their products. They thought they had a good reason: They wanted new products to look bright, shiny, and simple to potential users. That’s an excellent goal, but actual simplicity is achieved by simplifying things, not by hiding complexity. (See Visibility.)
It’s just fine to make your showroom products look simple, but, to the extent you want to hide complexity to avoid scaring away buyers, do so in the showroom, not in the home or office of the purchaser now trying to accomplish real work. I started putting a special Dealer Mode into Apple software in 1978, so that the product would look and act differently in the showroom than in the buyer’s home. Computers allow that. Somewhere along the line, people forgot.
It is OK to make the user’s environment simpler when they are learning by hiding more advanced pathways and capabilities, revealing them when users come to need them and know how to handle them. This is distinct from the illusion of simplicity, where necessary controls are made invisible or hidden in obscure and unusual places so that users have to go on treasure hunts to find the tools they need to use right now.
Progressive revelation can cut down on support costs by eliminating calls from users trying to understand advanced capabilities before they have learned enough about the task domain to need them. It can also raise costs if advanced features are not introduced when they are needed or are too well hidden.
This became another Apple problem after the release of their mobile devices. In 2014 on a Mac, you can set an alarm that will trigger 90 minutes before a calendar event. On the iPad, you can set a trigger for either one hour or two, but not 90 minutes. If a person needs a warning 90 minutes before the event, that’s when they need the warning. Apple has “simplified” the interface by giving the user no way to set an arbitrary time. No weakness or defect in the underlying interface would prevent Apple from giving users this capability. It is a conscious decision to limit what people can do with the product.
The way you set a 90 minute warning on an iPad is to create a second event, 30 minutes before the real event, and set a 60 minute warning.
How is that simpler?
Likewise, they have a very simple interface for finding photographs in your collection: You look through all your folders of photographs, one at a time, until you find the picture you’re looking for. Apple will neither display nor allow you to sort/search on the title, caption, or keywords you’ve carefully associated with your images. One can argue that the interface is simple: If you want to find a specific photo among that 20,000 on your iDevice, just look through your 73 folders you’ve created in iPhoto or Aperture to hold them until you find it. You don’t have to learn about searching, you don’t have to remember the name, you just have to have 10 to 20 minutes on your hands to spend the time looking.
How is that simple?
Fortunately, after many years, help is at hand: Apps like Photo Shack HD (the HD is important) enable you to search on all the criteria that Apple is importing but refusing to show you. That’s OK for really advanced features. However a remarkably high percentage (100% to be exact) know how to search.
Our systems should “know”:
and myriad other details. In addition to simply knowing where our users have been, we can also make good use of what they’ve done.
One site with which you are familiar is so involved in and good at tracking state that it could be described as a state-tracking system that happens to do other stuff. That site is amazon.com. Their uncanny ability to make suggestions on what we might want to explore and buy is the result of their understanding our full history on their site. They know what expensive items we’ve come back to repeatedly in the past, what we’ve lingered over recently, and what would go well with what we just or recently purchased based on like-minded individuals.
Users should be able to log off at work, go home, and take up exactly where they left off. Following the principle of Protect Users’ Work, whatever they were last working on should be preserved in its current condition.
A private service for doctors, Physicians On Line, does an excellent job with this. Doctors can be 95% of the way through a complex transaction, log off, log in again six weeks later from another part of the world, and the service will ask them if they want to be taken right back to where they were.
“Track State” came late to this list, in 1996. Up until then, everyone had been tracking state on their own, without question. Because the web browsers failed to provide any tools beyond the purple color of a link indicating that link had been previously visited, engineers took this to mean they no longer needed to concern themselves with state at all. To the contrary, what it meant is that, from that day until this, applications engineers and designers have had to take over the full responsibility for tracking state that had historically been shared with the systems engineers, making the job that much harder.
Most users cannot and will not build elaborate mental maps and will become lost or tired if expected to do so.
The World Wide Web, for all its pretty screens and fancy buttons, is, in effect, an invisible navigation space. True, you can always see the specific page you are on, but you cannot see anything of the vast space between pages. Once users reach our sites or web-based applications, we must take care to reduce navigation to a minimum and make sure the remaining navigation is clear and natural. Ideally, present the illusion that users are always in the same place, with the work brought to them, as is done with the desktop metaphor. This not only eliminates the need for maps and other navigational aids, it offers users a greater sense of mastery and autonomy.
While you may have a thousand pages on your site, if every one of them has the same heading and the same main and secondary menus, the illusion to the user will be that she is always on the same page with content changing in one panel of the page. They can still be lost if they don’t know what panel they are viewing, so reinforce it by highlighting the current menu items that resulted in that particular panel, as well as offering them, in development systems that support it (and they all should), bread crumbing, such as:
NN/g Home > AskTog > Interaction Design Section
to help them build a mental model. As with the inherent statelessness of the web (see Track State, above), we must go beyond blindly accepting what the web’s architects have given us by adding layers of capability and protection that users want and need. That the web’s navigation is inherently invisible is a challenge, not an inevitability.
In designing complex apps, strive for a minimal number of screens, each representing a separate and distinct task the user will be performing. When a user needs to perform a subtask, bring up an overlay that is smaller than full screen, so that users can see a darkened image of the main screen still present in the background. What is seen need not be memorized, so users need not remember how that overlay maps onto the screen behind it.