The last in the Learning from Lusers series.
The whole band- my woman, her parents, her sisters and their guys and the kids -had moved down to the shore to look for clams and whatever might’ve washed up. On the first day I’m walking up the beach heading back to camp with an armload of clams, and I see Oog trying to pry an enormous clam out of the gravel with his bare hands. I can tell it’s Oog from a distance by that scar on his ass and that fox bone in his hair. Anyway, he’s growling and snarling because it’s slow, and he’s struggling with all his might, and the sand is getting under his fingernails, so I go up and say, “Oog, it’s a lot easier if you use a stick,” and I hand him mine so he can see for himself. He studies the stick, like, really slowly. I have to take his hands and show him how to wedge the stick next to the clam. So, he smiles this big smile like he gets it, and lunges down on the stick with all his weight. I mean, he had no concept of mechanical advantage whatsoever. And, sure enough, the clam pops out of the ground so fast it flies up and hits Oog right in the forehead and knocks him out cold. Some people just don’t get technology.
Meet Oog, the world’s first luser. Surprisingly, Oog and his genotype failed to be naturally selected out of countless of years of evolution. His offspring are still with us today. She or he may even be your boss. For as long as there has been technology, there have been lusers. Who are these lusers, and where do they come from? Why do they persist or even seem to multiply? What is a luser anyway?
A luser is someone who could not control technology. They were unable to use a technical product or feature effectively or efficiently. In a battle of wits against a problem with a technical solution, they lost. Anyone who has ever been frustrated by technology is a luser. The lusers are you and I. Well, me anyway.
As part of working on a network problem, I follow advice from Symantec’s knowledge base and re-installed Norton Anti-virus (NAV). It didn’t solve the problem, but that’s another story. Since then twice I’ve discovered NAV running a scan on its own. I figure there must be a default auto-scheduled scan, which would be great if it were running quietly in the background, but instead it snarfs enough resources to noticeably interfere with performance (e.g., typing this paragraph). Look in NAV Options. See nothing about scheduled scans. Look in Help under “scanning” and find “automatically.” Documentation directs me to the Scan for Viruses panel and says to select the scan I want to remove the schedule for. I see one of them, Scan My Computer, has an icon:
The clock imagery might be trying to tell me it’s a “scheduled” scan. Okay, I select the Scan My Computer link, expecting to see details about the scan. Instead it immediately launches the scan! Now I have TWO instances of the same scan running simultaneously sucking up even more resources. I try right-clicking the scan, looking for a way to stop it. No response. I click on the computer icon instead of the link. Oh crap! Now I have ANOTHER instance of the same scan running! Just then, a broom busts into my room carrying buckets of water.
The above is from my personal list of computer frustrations, December 22, 2006. Except for the bit about the broom. But my point is I’m a complete luser. Using my understanding of computer terminology, I thought “select the scan” in the documentation meant click on its name. Wrong. Using the analogy heuristic, I thought a Scan My Computer link would, I don’t know, link to some information, like links normally do on the web, rather than execute an action, like a command button does. Wrong. I thought to use the proximity heuristic and try to stop a scan at the same place I started it, right and left clicking around the Scan My Computer link. Wrong.
Users are Designers
Some have suggested that designers have fundamentally different mental processes, that they are naturally gifted at problem-solving because they have “design thinking.” Robert Hoekman has suggested that this elite form of thinking can be generalized to other domains than web design. He’s even coined a name for a person who uses design thinking to solve problems: A Solutionist. That would look cool on a business card, no?
That’s wholly unnecessary. We already have a name for a general-purpose problem-solver. It’s “Smart Guy.” Put that on your business card. All humans are problem-solvers, both users and designers. That’s what defines human intelligence. Certainly humans vary in their general intelligence, but I’m skeptical that designers as a group are more intelligent than members of any other profession. Rather, smarter and more creative designers tend to make better designers, just like, say, smarter and more creative accountants make better accountants, Enron being a debatable exception.
While the reality of lusers make it seem like users are a breed apart from designers, at its most elemental level, users and designers are doing the same thing. Both are working out solutions to problems with the materials they have available. When designers create a new email client, they are solving the problem of sending messages cheaply, easily, and quickly. When users delay sending an email until the evening when “the long-distance rates go down,” they are also solving the problem of sending messages cheaply, easily, and quickly (at least, quicker than snailmail). Users and designers try to solve problems by essentially following the same design principles.
What makes designers different than users is knowledge and experience. This is not a consequence of designers being generally smarter but rather simply a consequence of designers spending a lot more time designing in a particular area. They have studied design and technology, and have developed the tools and intuition to anticipate what potential technical solutions will and won’t work for a particular class of problems. To design a web app UI for example, you need to know about links, menus, buttons, and other controls. You need to know about the effects of layout, color, typography, and imagery on the average human. It helps to know what HTML, CSS, Javascript, XML, relational databases, and various APIs can and can’t do. Users, in contrast do not know these things nor will they ever know them as well as the designer. They simply don’t have time to learn it. They aren’t full-time designers, but full-time something else. What makes designers different is that they know the technology better than the users, where technology is broadly defined as anything made by humans for doing something.
Users, in contrast, know themselves better than the designer. They understand the problem the technology can potentially solve for them, because, after all, it’s their problems. For example, they know what they want in the products they seek on a e-commerce site, they know what they want to say or share on a social site, they know what points they need to make in a slide presentation, what questions to answer in a database query, or what process they need to complete at the plant. Users know their goals, or, at least, they know when their goals are not being met. Designers in contrast don’t necessarily know the users’ goals. That’s why they need to do user research. It works like this:
Through user research, we scope out a problem the user has, where by “problem” I mean whatever the users need or want or would be useful or enjoyable to them, along with whatever limitations, capabilities, inclinations, and tendencies the users have. Our perception of the problem may be imperfect, but hopefully close enough to the problem the users actually confront.
Given this problem, we as designers assemble available technology to construct a design solution that fits with the users’ apparent problem. Available technology may not fit perfectly with the problem, but we do the best we can. The solution is then deployed as a product for the user, who is faced with a similar situation: how to assemble the products available so they best fit with their particular set of problems.
Understand Your Job Better Than Users Understand Your UI
If designer and user engage in parallel problem-solving processes, then it follows that they should make parallel errors. If there are loser users, then there should also be loser designers. Designs can fail because designers fall prey to the same thinking that trips up lusers.
I sat with the head developer in her cubicle going over my proposed user interface design specs, simplifying the design of my predecessor. “So I’d like all these windows to be combined as a single window using tabs.” The developer furled her brow. “Our API doesn’t support tabs,” she said. Her comment puzzled me. It was my first real job on a development team, and I didn’t know the lingo. To me “to support,” means “to assist,” as in, “I support the Boy Scouts,” but she made it sound like a fatal flaw. “Does that mean you can’t do it?” I asked honestly. In retrospect that probably sounded like I was questioning her coding ability. “It doesn’t support it!” she reiterated emphatically. I was left to guess if that meant “utterly unfeasible” or merely “less pleasant.” The tabs stayed in the spec. A few days later I presented to the entire team the specs, including the tabs and several other brilliant UI innovations. The team reached a unanimous conclusion: I must be on crack.
I managed to last a few more months at that job.
When you misunderstand a user’s (or a developer’s) domain-specific or idiosyncratic language in your research, you’re having problems with terminology much like users can have problems with your UI’s terminology. When in usability testing, you associate a user problem with the wrong user interface element, you’re often incorrectly using the proximity heuristic. When you misapply a design solution that worked before to a current design problem, you’re often incorrectly using the analogy heuristic. When you dismiss an user’s comment as irrelevant such as dismissing a negative response to a new UI as the user just “resisting change,” you may be committing the same error as users that dismiss message boxes without reading them. When you select a design just because it has always seemed to work with users, you’re using a form of the magic heuristic. When you mis-apply a technology, tricking it to get something that sort of works in a kind of usable manner, you’re performing a workaround, much like user do. An HTML web app is one big kludgey work-around, sacrificing basic usability features like incremental undo or preservation of input, and using a paging model of navigation that is ultimately unsuitable for an application, in order to have something easy to deploy.
You can avoid such design errors the same way users can avoid parallel usage errors: by cultivating a deeper understanding of the technology and user problems. Only then can you properly fit the technological pieces to the user’s true needs or wants. For example, up until 2007, the designers of Microsoft Office continued to employ the Magic Heuristic, updating the suite with ever more toolbars and other subsidiary menus to try to cope with the suite’s increasing complexity. The proper solution was to provide the user the ability to select from various menu bars dependent on their task, which is essentially what the Ribbon does. But before 2007, designers couldn’t bring themselves to do that -or it never occurred to them. You can’t have the user swapping among multiple menu bars! That would be against every GUI standard out there! And following standards is how you get a usable UI. It’s magic. The standards do allow for users to swap among multiple toolbars -to hide and show them using the View menu -so that’s how the Office designers tried to cope with increasing complexity. They complied with the standards, but if they thought more deeply about the problem, they would have considered that standards have a certain scope and they fail when applied to extreme situations -like an application with over 1000 commands. They would have realized that hiding functionality as unlabeled icons on unseen toolbars is worse than breaking a standard of multiple menu bars.
Getting a deep understanding of the technology and the user problems is difficult, and can take years of experience, but that’s the biggest part of your job as designer. Lusers have an excuse: your product is, contrary to what you might think, not even in their top 10 of most important things to understand.
Humane Adaptation
Recognizing the commonality between users and designers sweeps away false dichotomies that limit our ability to design solutions. For example, it’s a false dichotomy to believe you have to choose between people adapting to your product and adapting your product to people. All design is adapting things to people. When Oog’s companion selected a stick to dig out clams, he was adapting the situation to solve his own problems, modifying things to make life easier for himself. Design can be defined as planning to modify the environment to achieve some human end. The environment always imposes limits on the design -Oog’s friend could use a wooden stick to dislodge a stubborn clam, but PETN was not an option. Nonetheless, the difference between a valuable design and a worthless design is whether they make things better for people.
The only question is which humans are benefiting from your design solution? In user-centered design and UX, the goal is for the user to benefit, but you could alternatively design to benefit the users’ supervisor, the product’s developers, the maintainers, the client, or yourself. The question isn’t whether the product should adapt to user or should users adapt to the product. The question is, do you adapt the product to the user, or to ease of manufacturing or coding, or to product reviewer habits, or to marketing and fashion, or some high aesthetic ideal. By the very act of building something, you are adapting to something. Certainly, if you expect users to adopt a consumer product you’re designing, they have to at least believe it benefits them, so any successful design likely has to make some concessions to adapting to the user.
[A technician] is creating a new account for a longtime employee but first-time user… an older mechanic who had been there for years. [The technician] explains to user that he needs to choose a password -one containing at least one capital letter, one small letter, one number and one special character, totaling 8 to 14 characters. User nods -and stares at the keyboard…. Maybe he just can’t think of a password, [the technician thinks] to himself. He writes a few examples on a piece of paper. User thanks him -and keeps staring at the keyboard, obviously puzzled…. [Finally, he says] that he didn’t see any small letters on the keyboard. After a quick lesson on the function of the shift key, he explained that he’d never touched a computer or typewriter before. No need -he’d been a mechanic all his life. (Shark Tank)
At the same time that the design always means adapting the environment to people, design also always means that people are adapting to the environment. Adapting the product to the user doesn’t mean the user never adapts. Indeed, we’ve seen that anything new must include magic. For a product to make a difference to the user, there must be something different, which means the user is going to have to learn something. Design means adapting the environment but also means users must adapt. Users evolve with the technological environment, becoming different people with different problems. And that’s okay, because in addition to all humans being natural designers, we are also all natural learners. Learning ability is the other side of problem-solving that defines human intelligence.
The only questions are how much learning? Is it worth it for whatever benefits the product provides? These are questions each user tries to answer each time one considers acquiring a new product. It’s a question we designers must consider with every product we design. In your designs, you want to maximize the ratio of new functionality to adaptation. Furthermore, you should tailor the amount of adaptation to frequency and total usage. Learning an entirely new interaction device is probably not worth it for your lowly website the user only uses a few times per year.
On the other hand, users adapt quite radically to new technology if the benefits are sufficient. It used to be that typing skill was something only secretaries and writers needed. Executives would consider it beneath themselves to touch a keyboard. The benefits of the personal computer changed that. Now, even mechanics see the benefits of learning to type. As little as 25 years ago, a college student with typing skills could make good money typing up other student’s term papers and theses. In a single generation, we’ve all become typists, a skill so ubiquitous, the job category doesn’t even exist anymore.
This is how technology changes us. Consider an alternative universe where handwriting recognition turned out to be technically much easier than it is. The Apple Newton would be remembered as the most significant innovation of the end of the twentieth century. Keyboards would only be seen in museums, where we’d stare through the glass and wonder how anyone could ever write so quickly with them, the way we wonder how Homer could have ever memorized The Iliad. Today, technology has evolved so that handwriting recognition is just barely feasible, but it’s too late to spark a revolution in personal computers -the human need it would fulfill is gone now. Now handwriting recognition is relegated to niche uses. Maybe we should complete the path of adaptation, and change alphabetical order to start Q-W-E-R-T-Y.
Designing a new product means users must learn, and users learn well. But for designers, there remains a paradox. If humans are such natural learners, why do they resist learning so much? We’ve seen in this Learning from Lusers series how much users appear to resist learning, sometimes actively. Any school child can tell you that learning is hard, boring, and sometimes anxiety-riddled. Learning the UI of your product is like being back in grade school. The subject matter doesn’t interest the users/pupils, except for a few weird enthusiasts. Most would rather be doing something else. At the same time they know there are real consequences for failing to learn -pupils lose if they fail a test, and users lose if they fail your design.
The answer to the paradox is some learning is more compatible to human make-up than others. Some things required high effort and focused concentration to learn, but a lot of things we learn unconsciously. The trick to creating usable designs isn’t to eliminate user adaptation. It’s to provide for humane adaptation, to design for easy or unconscious learning as much as possible. You want to make the adaptation itself consistent with human abilities. In previous Learning from Lusers we’ve seen users attempt to come to terms with technology by:
- Thinking by analogy.
- Noticing spatial and temporal relations.
- Absorbing simple logical rules for interaction.
- Recognizing a familiar term.
- Filtering out things that experience show are irrelevant.
These make learning the result of simple exposure. It comes down to making an intuitive user interface, something we all know we’re supposed to do. Making something intuitive means designing to cater to the above list. Specifically, an intuitive UI has the following:
- Affordances. UI elements have a natural shape and position that communicates the expected interaction.
- Clear Labels. UI elements have short clear labels that communicate in the user’s own language.
- Organization. Similar and related items are proximal to each other in the UI.
- Compatibility. Positions and directions of motions are consistent with UI responses and user mental models. For example moving forward means moving down or right for Western users.
- Feedback. The effects of user actions are immediately apparent where the user is focusing attention.
- Appropriate metaphors. The UI makes explicit associations to physical and cultural analogues and the UI behavior is consistent with that analogue.
- External consistency. Given one thing in your UI and another thing outside your UI that the user knows well, if the two things appear the same then they have the same meaning; if they have the same meaning, then they should appear the same.
Pretty much all the above depends on your users’ experiences up to the point of confronting your design -what they’ve already learned and adapted to. Being intuitive primarily means leveraging user learning and experience. Thus, how intuitive your UI is depends on your users, and the experience and knowledge they bring to it. The last lesson we can learn from lusers is thus the first lesson for any user interface designer: Know thy User.
Summary Checklist
Problem: Designing so users can learn to control their technology.
Potential solutions:
- Recognize that the process for using a product to solve problems is subject to similar errors as designing a product to solve problems.
- Explore user problems and design technologies deeply so you understand the trade-offs that apply in each context.
- Design for humane adaptation by making learning effortless.