I heard an argument forwarded by Andrew Hinton way back in Dublin at the Inteaction12 conference. The short form goes like this: “Users don’t have goals.” (UDHG for short.) Being a big believer in Goal-Directed Design, I thought the argument to be self-evidently flawed, but since it came up again as a question from a student at my Cooper U class in Berlin, I feel I ought to address it.
Are there, in fact, goals?
Given just those four words, it seems like it might be about users actually not having goals. But of course, goals do exist. If they didn’t, why would anyone get out of bed in the morning? Or do work? Or make conference presentations? If we didn’t have goals, nothing would be happening in the world around us. But of course we do we do get out of bed. We do work. We write blog posts. All because we have reasons which—for clarity—we call goals. This example illustrates that what UDHG really means that most people don’t have explicit goals.
OK, do users have explicit goals?
In fact that’s the main argument Hinton puts forth (check it out in the slideshare of his presentation to see it in his own words). But of course no one in the real world has a bullet list in their back pocket with concise, well-phrased explanations for their behavior. So it’s a straw-man argument to proclaim that since no user has explicit goals, using them as a design tool is bad. No one believes that users have “explicitly, consciously articulated goals”. Seriously. If anyone at Cooper ever said that, let me know, because that’s absurd and they need a stern talking to.
People’s goals are rarely explicit. But that’s OK. They don’t have to be, because users aren’t the ones who need them to be explicit. Planets don’t have explicit orbital formulas, either, but once astronomers figure them out, they can use those formulas to predict their orbits. So even though planets don’t “have” them, we still need them for their predictive utility. Similarly, users may not have their own goals written on scraps of paper, but those goals are still there, getting them up out of bed, guiding their behavior, driving their choices, and giving designers something to accommodate and consider as we design for them. Users are intentional agents, and we need to keep those intentions in mind. At their most useful, those intentions are framed as (you guessed it) goals.
Stop reading here ————————-
That’s really the heart of UDHG, and the heart of the counterargument. If that’s all you came for, you can stop reading here. You’ve been armed with the pithy rejoinder for the meeting where someone questions your Goal-Directed methods. “Users don’t have goals!” they say. You can reply, confidently, with something like, “Planets don’t have orbits, either, and yet here we are in summer.” While they figure it out, you can continue on doing good, Goal-Directed design.
OK clearly you’re not so easily deterred. If you read further, the rest of this article digs a little deeper into three detailed issues raised in Hinton’s materials.
1. Welp, that’s not a goal
Hinton asserts that goals will change as someone pursues them (and therefore aren’t useful). But that’s another straw-man argument. Goals are defined as being strong, stable targets. If you’re focused on something that’s changing all the time, you’re talking about tactics, or even mode-shifting. But that’s not the sort of goal underneath Goal-Directed design. If you design for tactics, you’re stuck with the way people currently do things, and it’s harder to come up with game-changing interaction design ideas.
2. WYSIATI bias?
As supporting evidence for his larger point, Hinton cites some psychology from Daniel Kahneman in his book Thinking Fast and Slow. We’re big fans of that book. The principle from it that Hinton cites is as follows: humans suffer from a bias called What You See Is All There Is, or WYSIATI for short. In WYSIATI, people tend to overcredit any information they have (including bad and even random information) as the only facts there are. People don’t tend to think about either counter-evidence, what’s missing, or the big picture. The argument is that goals force designers into this WYSIATI thinking, and so shouldn’t be used.
Well, of course, people are messy. Any good design methodology has to accept this fact of the world. But if the use of goals introduces a WYSIATI-related false precision, that’s not an artifact of using goals to guide design, it’s an artifact of goals being poorly used. Every tool introduces some bias. It’s a mark of professionalism that you understand and compensate for any biases that your tools impart. If you’re not understanding personas and goals in light of your research and general understanding of human behavior and psychology, you’re not being a responsible tool user. And thereby not being a responsible designer.
3. The Problem with the Situation
As a cure for the (straw-man) problem of goals, Hinton offers “situations,” or stories where a user is faced with a problem they need to solve or a need that’s going unmet. Well, straw-man on top of straw-man, we do that, too. Instead of “situations,” though, we call them scenarios, and…this is hard to overstate…they’re as important as personas. They are the stories that tell how a persona uses the product or service you’re designing to achieve their goals. They always start with some problem, and that can, of course, include the realization of an unmet need. It’s critical to understand that personas and scenarios are two parts of a single Goal-Directed tool, like the head and handle of a hammer. Using just one won’t do the trick. So if you need to call scenarios something else, fine. But if you’re designing for scenarios without personas who have goals, you’re still doing it wrong.
Without a defined character inhabiting your scenarios, you’ll succumb to one of two problems. The first is designing for yourself. This is the actual problem underneath the cited failure of Google Buzz, Google designed for its employees and then expected success in the outside world. The second, and arguably worse problem, is you end up designing for what you think are people, but you’re really designing for “the elastic user,” in which you change the definition of your user to suit the design problem at hand. Need more text on the screen? They’re young experts with great eyesight. Have a stakeholder worried about learnability? Suddenly they’re feeble-minded and have never seen a computer before. Either problem will drag your designs into the dump. You need personas with goals as stable targets. Situations/scenarios alone won’t cut it.
Of course if there were some other tool that was completely free of bias and yet was at least as effective and generative as goals, we would switch. But in my 25 years of design experience, I’ve not encountered o
ne. In the absence of one: goals, goal-directed design, personas, & scenarios are the most responsible way to do great interaction design for people. All of whom, yes, have goals.