Theory, the art of design, and the science of usability.
You’d want to be known as a designer with vision. Or maybe you don’t. “Vision” is double-edged term. It has been invoked to represent a brilliant if mystical insight, an intuitive leap beyond the mundane to something so beautiful it transcends reality as it is currently known. But it can also come across as some vague artsy term with little bearing on the real world and no practical use. Have all the visions you want, one could argue, but what really matters is how the product actually works with real people, not some high-brow concept of how things “should” be. It almost sounds like two mutually exclusive ways of designing: one can design from vision trusting in one’s own intuition, or one can design from facts, trusting in the results of user or market research.
Scientists often encounter the same dichotomous response to the word “theory.” To some laypeople, it connotes genius, a glimpse at the master blueprint of Nature, simple in expression, but sometimes incomprehensible to mere mortals, as in the Theory of Relativity. To others, a theory is just ivory-tower armchair pontification. To these people, what really matters are the facts, things actually known to be true by scientific measurement; everything else is “just theory.” Both of these points of view represent a misunderstanding of what theory really is to science.
Vision and theory have more in common than parallel connotations. Vision can serve the same function in product development as theory does in understanding nature. If you regard your vision as a theory, you’ll find it is hardly something divorced from reality. On the contrary, it grounds your vision in the facts and drives the research necessary to develop a product, just as theory drives research to understand natural phenomena. The research in turns validates or adjusts (or maybe refutes) the vision, and by extension improves the product. When used in this manner vision and research exist not in competition for the design but in symbiosis.
Vision Defined
A vision is a design principle that generates an image of a better experience for your users than what they have now. Take for example the problem of the television remote control. If yours is like mine, it’s a confusing array of tiny buttons with abbreviated labels that are hard to read and find, especially in a dimly lit room that people typically prefer for watching TV. Confusingly, some TV functions are accessed with dedicated buttons on the remote, while others are accessed through an on-screen menu using cursor buttons on the remote. So here’s the vision: Put everything on the screen. Let’s have everything –channel selection, volume, power –controlled by selecting things displayed on the TV screen. The TV screen is easy to see (otherwise users couldn’t be watching it anyway), it has room for larger easier-to-read labels, and it can make better use of the space by altering itself according to the task (e.g., by presenting different menus and virtual controls depending on the user’s precise input).
That’s an example of a vision. It’s not necessarily a good vision, but it’s a principle (Everything on Screen) from which we can imagine a better experience for the user (clicking on clearly labeled items on the screen, rather than fishing around for buttons on the remote). By being a principle, it’s more than an idea, because it covers multiple tasks and elements of the UI. If only channel changing were put on screen, that would be an idea. By putting everything on the screen, now we have a principle.
Being a principle also implies a cascading chain of changes. If everything is on the screen, the remote becomes simply a pointing and selection device. For that to be practical, we’ll have to ditch the awkward cursor buttons. Instead, let’s put a pointer on the screen and let the user direct it by where the remote is exactly pointed. Point and shoot, not click, click, click, to navigate through a menu. The remote can look something like this:
The trigger activates whatever the user is pointing the remote at, such as a volume setting. A Menu button, operated by the thumb, displays a menu of all actions that are available for a given spot on the screen (e.g., setting SAP or Surround sound, when pointed at the Volume on the screen). It’s like the Menu button is right-click, and the trigger is double-click.
With an adaptable display, forget about putting an Up and Down channel buttons on the screen, or calling up a virtual keypad to enter a channel number. As it happens, the average user has access to 104 channels but only watches 16. So list them all in a menu, by default sorting the display by the frequency that each channel is watched. With a HDTV probably having room to display a menu of 20 channels at a time, users can get to any of their favorite channels in one click. As an adaptable display, we can provide users the ability to display the network name right on the screen.
We don’t want to have these menus and controls on the screen when user’s not using them, so include touch sensors in the buttons of the remote: when they’re not being touched, the screen clears of all controls. All these design elements fall naturally from the principle of Everything on Screen.
As for the user experience, realization of this vision means no groping for little, poorly labeled buttons in the dark, fast one-click changes to volume and for the most frequently watched channels, no need to memorize the station numbers for each network, and a single consistent means of interfacing with all features of the TV. Life is good.
Ok, I never said a vision means a much better user experience. There’s vision and then there’s grand vision. Any vision has a certain scope, which specifies the impact on the user and the technical changes necessary to realize it. Greater scope implies greater change in the users’ task, environment (physical, organizational, etc.), and the users themselves (in the form of learning new things). It also implies greater changes in the technical context, with more new hardware or software necessary to deploy or develop.
For example, let’s expand the scope of Everything on Screen to everything on the screen, not just TV, but also video on DVD, hard-drive recorders, and personal computer videos. And also program guides. You see users looking up a show in a program guide, then selecting the channel number. How quaint. Let’s put all that information in the TV’s menus.
Suppose further that in the course of user research, you discover that users don’t really select by channel or network to watch as much as they select specific shows of interest –specific series, sports, and movie genres. It’s not that users say, “I feel like watching NBC tonight,” or “I feel like watching a DVD.” Instead, they say, “I want to see what’s happening on American Idol,” or “I feel like an action movie tonight.” If that’s true, then it would make more sense to display a menu of shows rather than channels or networks (click for full 1280×720 view).
The show menu is sorted by default to display first whatever is currently available that hasn’t been watched yet, whether it is currently being broadcasted, or saved to a hard drive, or on a PC on the home network, or on a DVD loaded in the DVD player. The user can use the same menu to select shows to record to the hard drive, and can change the sort and filtering criteria to find future shows to set to record. Copying among DVD, hard drive, and PC can also be effected (allowing we’re looking to improve the user experience, not the copyright owner’s experience).
This version of the vision has greater scope, more dramatically affecting the user experience, making it easier for users to find what they want to watch and watch it when they want to watch it. Recording by selecting shows is less error prone than recording by selecting time and channel, because it eliminates the cognitive step to translate a show to a channel and time. With program guide information in the TV, we’ve eliminated the need to enter the network names for the channels (as necessary in our narrower vision). Such a vision implies a change in the way users even think about watching TV.
But consider the far-reaching changes a vision of this scope requires. The user has to learn a new way of interacting with the TV, as I’ve alluded to (but hopefully one that is simpler to learn than learning how to coordinate DVD, hard drive recorder, TV, and PC video today). Technical changes are substantial: there needs to be standards for the TV to communicate with the cable/satellite service provider, DVD, hard disk recorder, and PC-based video server software (some of these may already exist). The TV needs to be built to interface with all these devices (e.g., it needs an Ethernet and/or wireless network adapter). There may also be some environmental changes necessary (did I mention that certain parties might take issue with all this recording and copying involving PCs?). Lots of work is implied by such grand scope, and we haven’t even gotten to making a workable remote. A big vision requires serious commitment. By that I mean time and money –if you have a vision to change the world, be ready to fork it over.
The Practicality of Vision and Theories
Vision and the Design Process
Having a vision for your products has practical impacts on both the design process and the quality of the ultimate user interface. For the design process, it consolidates an understanding of the context and guides planning. By being a concise statement of the problem and the solution, designers can focus on specifications and requirements that solve the problem and move the product towards the vision, and avoid being sidetracked by the lure of the latest technologies or the trendiest aesthetics.
When there’s vision guiding the process, it’s not enough to have a good idea for a feature or interaction method. The idea has to be consistent with the vision. Applying a vision can avoid acts of misusability, such as blindly taking feature and design suggestions from users in the course of user research. Many good ideas come from users, sometimes accidentally. However, probably most ideas from users are not particularly good, often being rooted to a narrow conventional view of the product. Vision provides a means of sorting out the good from the not-so-good, or a way to turn the not-so-good into better.
Suppose, in the course of doing user research for the big-scope vision for the TV, you find a deeply entrenched group of users that insist they have to have the ability to click through every channel in sequence. As whenever you get a feature suggestion from a user, you need to find out why it’s wanted, so you can determine the underlying problem the feature is supposed to address. Combine the problem with your vision, and you’ll often find an alternative to the user’s feature that is less complex and more consistent.
For example, suppose users like to click through every channel as an (often fruitless) attempt to see if something interesting is on. First of all, if the default sorting works well enough, the user should be able to tell by looking at the show menu whether there’s anything on or not. If that’s not enough, then perhaps a thumbnail video of a show can be displayed as the user highlights each show in the menu (as shown in the illustration above), allowing the user to more quickly sweep through the available shows to see what’s on. If users are going to be bored by TV, let’s at least help them give up quickly. Alternatively, maybe clicking sequentially through shows is itself a low-grade form of entertainment. If that is the case, then maybe our TV needs a show-scan feature, like the station-scan feature found on radios. I mean, if our users want to totally vege-out, let’s save them the effort of hitting a button for each channel
Vision and Buy-in
When everyone on the design team subscribes to the same vision, the design can avoid the confusion that typically comes from designing by committee. Being at least proximally the product of an individual’s intuition, vision, like theory, is often a personal thing. This can present a challenge to a designer on a product development team where the other stakeholders (least of all the client) may not be quite so enthusiastic about the vision. The result is a potential for pressure to compromise the vision based on the competing intuitions of other stakeholders. Not a good thing.
Some have suggested we solve this by invoking a political analogy for the design process, cautioning against democratic notions of stakeholders or users essentially “voting” on designs in team meetings or usability tests. Instead, it is argued, design should be driven by a “benevolent dictator” (as opposed to, say, an evil sadistic dictator). In this analogy, the vision is the dictator’s ideology.
This solution has a few problems, the first being how to know if your dictator is so benevolent, that they have some special empathy with the users. You can look at past performance on previous products, but products succeed or fail in the marketplace for many reasons other than usability. Also, if the new project involves new users or tasks or environments, whatever empathy the designer had in the past may not transfer. A second problem is that a role of dictator may not be realistic in the current corporate environment where multidisciplinary design teams are becoming increasing common.
Fortunately, there is an alternative to a political analogy, and that’s a scientific analogy: the stakeholders are a research team working on a research program to evaluate and develop a theory, where the vision is that theory. While a dictator requires allegiance to himself and faith in the ideology, all you need in the scientific model is commitment to the theory. By commitment, I only mean a willingness to fairly and fully test the theory through research. It does not exclude skepticism in the theory. Indeed, skepticism is essential in the scientific process to be sure the theory is fairly and fully tested. Healthy skepticism in vision is likely to have similar benefits.
As applied to vision, this means the stakeholders understand the vision and endorse the pursuit of the vision, at least for the time being. It doesn’t mean everyone has to necessarily believe in the vision, but it does mean that everyone has to agree on a vision to develop into a product. This is the same as a team of scientists working a research program: before a series of experiments can be planned, the team has to agree on the theory they will be testing with the experiments. I would expect that getting stakeholders to agree on a vision to test beforehand is going to be easier to achieve than, say, getting them to just trust the designer and whatever vision she or he spits out.
Vision’s Impact on the Product
The most compelling theories are elegant, providing extensive explanatory power with a relatively simple expression. Once a person understands a theory, it can be used to organize and appreciate many facts that otherwise would appear unconnected. Understanding the theory of plate tectonics, for example, explains why fossils separated by an ocean (today) appear so similar. It also explains why earthquakes and volcanoes appear along certain crooked lines on the globe.
Likewise, the most compelling visions have elegance, ultimately providing users with an ability to understand the UI at a deeper level than rote memorization of the steps for individual tasks. Rather, the vision binds the procedures for the tasks together.
An elegant vision is simple (for the user), coherent, and powerful.
- Simple. A simple vision is easy to express. It’s a vision than can be described as, “why not just have the user to this?” It’s not about providing the user with multiple ways of doing the same task, but instead one right way to do the task. The Everything on Screen vision has this characteristic, providing one interface principle, rather than three we see currently with TV remotes in the form of dedicated keys, a keypad, and on-screen menus.
- Coherent. Beyond simple, the best visions are coherent having an internal logic. It’s not a heap of unconnected little changes for the user, but rather each change logically implies the other. In addition to being the way to do one task, it’s the way to do multiple tasks. Everything on Screen is coherent too, where the decision to put the channel selection on the screen implies a show or channel menu rather than up and down controls.
- Powerful. Beyond coherent, compelling visions are powerful, solving not just one problem for the user but several problems. All the multiple tasks it affects are done more easily in the vision than in current reality. The big Everything on Screen vision, for example, solves user problems in using the remote, memorizing channel numbers for networks, cross-referencing the program guide with the channel selection, mis-recording shows, and integrating multiple sources of video entertainment.
For the user, an elegant vision, one with simplicity, coherence, and power, implies a better user interface. Simplicity implies a UI that’s easier to learn. If the product means users solving a problem in a different way, then users are going to have to learn the new way, but if it is simple, then there isn’t much to learn. For example, in our Everything on Screen vision, there’s not much to learn other than what the two buttons do on the remote -the rest can be discovered by looking at the menus.
Coherence implies consistency. To learn and remember one new way to do many things is easier than to learn and remember where to do the new way, and where to do the old way. A vision with coherence combined with simplicity makes the UI simple and intuitive to the user. Usually, we associate intuitive with external consistency, the degree the UI of your product is consistent with other products for the same tasks. External consistency means the user has nothing to learn because everything is just the same as it was before.
But a sense of intuitive can also come from coherence and simplicity. It’s intuitive the way a mouse or hypertext is said to be intuitive. By design, the remote for an Everything on Screen TV is also supposed to be intuitive in the same way, although the remote is clearly unlike your typical remote. Like the mouse or hyperlinks, a user who has never seen such a TV remote before has virtually nothing from previous experience that provides clues on how to use it (other than the physical affordances) –it’s just a handle with a couple buttons. However, once user sees how to use it, they can immediately use for almost anything on the screen. Simplicity makes it easy to learn, and coherence makes it widely applicable, encouraging exploration of the UI. For example, if the user points to Power on the screen and clicks the Menu button, they get options to turn the TV off now, or in 30 minutes, or 60 minutes… it’s the Sleep feature. Being easy to learn and heavily used, it is also memorable. Spirit a user away to in a low-tech monastery for a couple years and I bet you’ll still find that they remember how to use the remote on returning (along with how to use a mouse and hyperlinks).
Add power to coherence and simplicity, and you’re nearly assured a superior user interface because by definition it means multiple problems are solved. Simplicity and coherence make the UI easy to learn and remember. Power provides the motivation to learn. Learn a little to make life a lot easier. Who wouldn’t want that?
Vision Quest
Vision may be great but first you have to get one. The popular view is that there is no formula, but instead a vision comes from intuition. The same can be said of developing a scientific theory. In college, in an early lecture in an advanced sociology class I was taking, the professor began to list how you come up with a theory, which we dutifully scribbled into our notebooks: theories come from thinking, wondering, meditation, dreams, acid trips…. Then he turned to us and said, “I can’t believe you’re writing this down.”
Actually, while the moment of insight takes intuition (which may or may not be abetted by psychedelic substances), it’s pretty clear that theories come from knowledge, whether it be experimental results, other theories, perhaps in only tangentially related fields, or personal experience. Nearly all scientific work is built on the work that came before it.
The same is true for vision. Every invention has been built on the research and experience of others. Even if you think you pulled an idea out of your hat, you didn’t. Your ideas are the product of your experience, both direct and vicarious. The way to develop a vision is to cultivate experience: study what goes on around you the way a scientist studies nature.
In the case of user interface design, take a user-centered perspective. Study what users do. What do they do right and wrong? Where are their points of pain? Why? There’s an opportunity to learn every time a user curses a piece of technology. Sometimes the problems are more subtle than an emotional outburst, so be systematic in your research. Do task analyses, counting the number of steps, the information to be memorized, and the calculations or conversions that must be performed. What can be eliminated? Where are errors? (e.g., forgetting channels from a program guide, mis-entering recording times)? How is language used? (e.g., referring to shows or networks to watch, not channel numbers). Note that a vision doesn’t come directly from the user, any more than Nature hands scientists a theory. But as observation of natural phenomena begets theory, observation of users and their technology begets vision.
Initial user research is more than cataloging user goals and attributes for personas and more than gathering requirements. At its earliest stages, research results can provide inspiration for a vision through empathy with the users. European designers evidently have techniques for deriving inspiration from the study of users.
Equally important to studying users is to study user interfaces. For example, it’s pretty obvious the Everything on Screen vision draws heavily from GUIs, replacing the mouse with a pointing device that will work better from an armchair. The real moment of insight for me came from misunderstanding a user interface. I was reading on-line about the Harmony One remote, and I asked myself, “What’s the point of a remote with a built-in LCD display? You’ve got an enormous 720×1280pixel display right in front of the user!” (the reason for the LCD was because this remote was intended to operate home audio systems in addition to TV, but that’s beside the point). Look for the latest ideas for inspiration but it’s also worth looking at old user interfaces for ideas, and at what users currently use –not for what is wrong, but for what is right.
The image of the brilliant designer summoning vision from pure thought is an exaggeration. Certainly, some internal contemplation is necessary, but if you’re looking for vision, first look outward, read, watch, ask, listen. Newton couldn’t think of squat until he saw the apple fall to the ground.
Practical Vision and Theories
Why Dictatorships Fail
Even with buy-in from all the stakeholders, an elegant vision is important but not sufficient for an effective vision, one that actually results in a useful or desirable product. I’ve mentioned before the vision of the computer knowing what the user wants by intelligent evaluation of the context and past user behavior. That’s a vision yet to be effective except in the most limited way. Both Microsoft Bob and the Apple Newton sprang from elegant visions, but both ultimately crashed to earth when they had to answer to reality, be it the psychological and social context or the contemporary level of technological advancement. (Parenthetically, it appears the Newton’s problems were at least partially due to changing the vision halfway through development, an event that should signal substantial risk).
Any product from any vision ultimately has to answer to three overlapping realities:
- Technological. The degree the technology is present and mature enough for a working reliable product.
- Human factors. The degree the feasible application of technology is consistent with the physical and psychological limits of human users.
- Organizational. The degree the development of the product has the necessary resources and business relations, and is compatible with legal requirements.
The need to answer to reality is another problem with the notion of the designer as benevolent dictator. Speaking as one who once held supreme dictatorial authority over a project (I was the soul researcher, designer, tester, and developer), I can say it’s a hoot, but sheer faith in one’s own vision, however elegant, is no guarantee of success. A benevolent attitude towards the user is not enough. The dictator also has to be right. I’m sure Mao Zedong sincerely had the best of intentions for the people of China when he pushed forward his Great Leap Forward, but that didn’t change the fact that the associated agricultural and industrial practices were technically ineffective.
The same truth applies to dictators, designers, and all visionaries: no one person, however gifted, knows everything. Surrounding dictator with underlings who question him or her is little help. Either the dictator alters the design based the underlings’ questions (and we’re back to designing by committee), or the dictator doesn’t (and asking the question thus served no purpose). The problem is both the dictator and the underlings are working from opinion only. Without some sort of data, there’s no way to decide which is right, whether the decision is made by a design dictator or the design team as a whole. Betting on anyone’s ideas without empirical support is an enormous gamble.
You need some process that the design must answer to: demonstrate a level of user performance, don’t trust the dictator’s opinion just because he’s like so amazingly empathic.
Theory : Experiment :: Vision : …
My former boss had a sign over his desk: “In God we trust. All others bring data.” Rather than a Great Designer as the Great Dictator, treating vision as a theory means that the vision is systematically tested against reality, confirming that it is workable. This avoids the need for faith in the designer or the vision. Instead of assuming the designer is empathic based on reputation, we can require that such empathy be demonstrated. The worse that will happen is that the designer will become more empathic if the results of the test are contrary to expectations and she or he learns something new about the users or their circumstances.
According to Otto Lilienthal, the brilliant aeronautics innovator of the late 1800s and the first consistently successful hang glider pilot (except for his last flight), “Inventing a flying machine doesn’t mean anything; building it, not much; trying it out, everything!” Likewise, testing a vision is almost always more difficult but also more significant than dreaming up the vision in the first place. Otto was staking his life on his aeronautical theories. Fortunately for most UI designers today, the cost of vision disconfirmation is not so onerous. I’m not suggesting the design team or company figuratively jump off a hill and plop the completed product out in the marketplace to see what happens. The results of an experiment like that would be nearly impossible to interpret anyway because so many variables are involved: a product may fail due to a faulty vision or due to a problem in the implementation of the vision, among other reasons. The Apple Newton failed not because the vision of PDA was invalid, as was proved by the success of the Palm Pilot a short time later. It failed because the handwriting recognition software was inadequate, and because it was too big and expensive.
Scientific theories are tested piece by piece, implication by implication, in a program of many relatively small controlled experiments. There is an equivalent for testing a vision: usability testing. Just as theory drives research, you can use your vision to drive usability testing. While there is some value to free-form “let’s just see what users do” usability tests (just as there value in exploratory research), usability resources are more effectively used when focused on answering specific questions. Vision provides a means to derive those specific questions. As hypotheses are deduced from theories, usability test questions are deduced from a vision. You can create prototypes that are consistent and inconsistent with the vision and check for the hypothetical user performance differences you expect to see. Additional test questions are variations on, “What has to be true about our users for the vision to work?”
For example, our Everything on Screen vision prompts some pretty obvious research questions. Can users point to targets on the TV screen precisely enough? Will it be as quick or quicker than using a conventional remote? Will it be as accurate or more accurate? Can users read the options on the TV without using a font that takes too much space? What about accessibility –will a sound-feedback mode make the remote usable for the visually impaired? Will the appearance of the options on the screen interfere with watching a show? Should logos be used to identify channels, or abbreviations, or do we have to spell the channel name out? Will users learn this new way of interacting quickly, and can they apply it to new contexts (e.g., after learning to change channels, can they figure out on their own how adjust the volume)? You probably already thought of some questions on your own just by reading the description of the vision. You probably found yourself say, “yeah but what about….” That’s in all likelihood a research question.
Often each research question for the vision can be answered with relatively cheap and crude prototypes. The first question on how well can users point, for example, requires little more than some still images of targets on a test TV, a laser pointer (for the user), and a stopwatch. The last one looking at generalization to volume, can be done, at least for an initial test, using a mock up on a ordinary computer with a mouse. Using vision to drive usability testing can make the most of your usability budget by keeping down the cost of each test and focusing resources on a few significant tests.
Note that no one answer to any of these usability test questions is likely to mean the vision is simply unworkable. This is true of a scientific theory too. Rarely will one experiment disprove a theory (or for that matter prove a theory). This is because the theory was created to be consistent with past research that the theorist knows –in a sense, a theory is born already partially supported. However, if a hypothesis fails to be verified, the theory, at the least, needs to be modified. Theories are typically discarded only when the weight of the evidence across many experiments shows they’re wrong (likewise, they’re not considered right until the weight of many experiments says so too).
The same holds for usability testing of a vision. If the vision is based on sound user research conducted prior to design, chances are usability tests won’t flatly disconfirm it entirely. Rather, the vision or the design instance of it may need to be tweaked. If users have trouble pointing with sufficient precision, for example, we may consider other kinds of pointing devices, or we may investigate software methods to aid precision, such as dampening algorithms. Maybe users don’t have to actually point at a precise place on the screen at all -maybe each point on the screen should correspond to a fixed angle of the remote relative to the center of the screen, and if that means users have to point pass the TV for sufficient gain, maybe that’s okay. Tweaks like these result in more usability testing, which is to be expected. After all, iterative design is a typical characteristic of user-centered design. Only if results consistently show a weakness should the vision be outright discarded.
Also note that a vision cannot be directly tested any more than theories can be. There’s virtually no value in describing a vision to users (“suppose you had a menu on the TV screen to choose channels…”), and asking them how much they’d like it or be able to use it. You need to give users something concrete to work on, and, like in an experiment, you need to measure it systematically, preferably objectively.
When you regard vision as theory, the end result will not necessarily fit with the expectations or suggestions of all the stakeholders or users, but neither will you find yourself clinging to a utopian ideology that fits poorly with reality. There will be questions and arguments among the stakeholders, but they become questions and arguments about what usability test questions should be answered first, and how the data does or doesn’t support the vision. That’s a healthy debate, better than arguments based on opinion or conflicting assumptions, and different than just one person saying, “This is the vision. I have spoken.”
The one rule is that you can never ignore research results. A problem found in usability testing means there is a problem, which you should at least attempt to address in design, even if it means altering the vision. If you can’t alter the design, you may need to make an engineering trade-off, where a positive impact on one dimension for the vision is considered to compensate for a negative impact on another. Obviously that is sub-optimal, but, as with a theory, a vision is only as good as the evidence that supports it. I can even imagine situations when benefits that cannot be feasibly verified (e.g., the impact after years of usage) are considered to outweigh a negative finding. That, however, should be a very rare and extreme case. It means you are weighing a known problem against a presumed advantage. What are the odds you are actually right? For those of you who came up with an answer without objectively analyzing your past predictions against empirical outcomes, please read Kruger and Dunning (1999), Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments, in the Journal of Personality and Social Psychology, 77, p1121-1134.
Usability has always been patterned after the scientific method, espousing essentially data-driven design. That is because humans are a variable and complex bunch that thwarts full prediction at either an intuitive or analytic level. We’ve had over 60 years of human factors engineering, but I’ve yet to see the equivalent of a finite-element analysis package for human responses. I don’t think humans as designers have progressed much either. We can, however, leverage usability’s roots in the scientific method. Vision has it’s uses, and vision as theory combines well with the tradition of usability engineering, perhaps allowing us to take its successes further. It comes down to this: a successful vision starts and ends with data.
Summary Checklist
Problem: How to use vision and research jointly to make more usable designs.
Potential Solution: Treat the vision as scientific theory to be verified and modified through user research.
- Select a scope of vision that is compatible with your resources.
- Conduct user research up front to get the background necessary for a vision.
- Strive for an elegant vision.
- Get the design team committed to test the vision
- Find solutions that fit the vision for the problems revealed by research.
- Derive usability tests from the vision. Ask and measure:
- What should I see in a product with the vision that I won’t see in a product without the vision?
- What has to be true about my users or their task and environment for my vision to be valid?
- Modify the vision as results come in, adjusting the vision prior to committing the basic design.