SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
USERS DON’T HAVE GOALS INTERACTION 12 | DUBLIN Andrew Hinton | Macquarium andrewhinton.com@inkblurtHi I’m Andrew Hinton, and I’m with Macquarium.Since we only have 10 minutes I’ll be sticking closely with my notes so I don’twander ...Let’s jump in.
@inkblurt http://www.flickr.com/photos/opalmirror/Let’s pretend ...You’re at home and you’ve stayed up too late. So late you ended up with a second wind, and now you’re feeling peckish.But before you even realize you’re feeling hungry -- before you’ve fully said that to yourself in your head -- you ﬁnd yourselfstanding at your open refrigerator.I know I’m not the only one who has ever done this ...You may tell yourself that you meant to walk to the kitchen, open this refrigerator door and grab a very speciﬁc snack ... buteven if that’s what you did, chances are you didn’t have a plan.It was more of a desire ... almost a reﬂex.So ... did you have a goal?What do we mean by Goal?
GOAL!@inkblurthttp://www.flickr.com/photos/epmallory3/6275268676/The idea of a “goal” is a pretty speciﬁc concept -- it’s a deﬁned, named object that we aim for.In a goal-based sport, before everyone even gets on the ﬁeld, they know what the goal is.I contend that invoking the word “goal” comes with a lot of assumptions and baggage that can misdirect our work as designers.
@inkblurtThere’s a deep assumption in our profession’s cultural background that our users have explicitly, consciously articulated goalsthat they’re working toward.There’s been a progression of landmark works in the profession that organize design around user goals.Now, I’m not saying these and other works that talk about goals are bad, they’re really excellent resources.I bring them up to highlight the fact that the “goal” concept is central to a lot of high-proﬁle methods and education in ourcommunity.
http://www.columbia.edu/cu/computinghistory/ Training Procedure Goal (Pre-Defined Result) A.Do this B.Do that C.Do this http://www.flickr.com/photos/pearluvr http://www.flickr.com/photos/foenix@inkblurtIt’s understandable that we would inherit this idea of user goals, given the origins of the computer-human interaction discipline.For a very long time, users worked in closed situations, where the whole system was constructed around pre-deﬁned goals, andusers were trained in procedures -- not unlike following a recipe to bake a cake.
People Process Technology@inkblurtThis venn diagram is in a million IT presentations and conference rooms.It’s like the Holy Trinity of IT.And who could disagree that these three things are both important and interdependent? It’s like saying water is wet.But if you think about it, there’s a lot of stuff buried in those terms, especially that word “Process”
@inkblurtChances are this image is not unlike the way your company or client or project manager views your studio or design department.It’s important to remember that many business and IT organizations still work under the industrial age model of manufacturedproduction.Most organizations are completely unaware just how many decisions they make are guided by the idea that all business is aboutproduction through linear process.
toolbox.com http://www.bai.berkeley.edu/ Technology People@inkblurtThe way most engineering departments will go about mapping human behavior is the same way they go about mapping systembehavior. Namely: a linear, highly rational, super-efficient process.>>In practice, there’s not much room for real people in the People Process Technology schema.People get treated like just another system ... assimilated like the Borg.
BEHAVIOR IS ORGANIC@inkblurtBut people don’t actually work that way -- they don’t behave like machines.And now that we’re making software more often for more complex situations, for more peoplewho aren’t being paid to use it, and who have other options to turn to, we have to come to gripswith the fact that people need software that helps them in the messy complexity, rather thansoftware that assumes your life is very tidy, linear and planned.
“New Brain” “Mid-Brain” “Old Brain” from Neuro Web Design, S. Weinschenk, 2009; p 3 Amygdala@inkblurtIn the last 20-30 years science has almost completely changed its mind about how our brains work and how we make decisions.And we now know that most of our actions are actually driven by the ancient parts of our evolved brain.We live in a frontal-lobe-driven illusion that we actually have deﬁned goals, when we rarely actually do.
Marcia Bates Jonah LehrerPaul Dourish Lucy Suchman Dan Ariely@inkblurtThere’s been a lot of work both academic and in the popular press that has been teaching us these new lessons about humanbehavior. Here are just some of them.Paul Dourish has been re-thinking context for years;Marcia Bates’ work on information seeking, foraging and berrypicking behaviors is seminal;I just learned about the Lucy Suchman book yesterday and now wish I’d read it years ago,and of course there’s Ariely & Lehrer have been writing very accessible books about how we really decide and behave.
Task Task Need Goal Cognitive Task Physical Situation Task Need Emotional Need Task Task Task Task@inkblurtSo if we really want to apply these lessons, we may want to re-think the focus on tasks and goals.In UX design we like to think we’re considering all the dimensions of the person, and often we really do ... but we still tend tofocus on tasks and goals.>> More often than not, the goal is only a fuzzy, distant possibility in the future ... and what we now know is that even if youthink you have a goal, it will likely shift and change as you ﬁnd your way to it.>> ... because right now the user is just trying to muddle their way through a situation that’s emerged in their life. When you getup to check the fridge, you rarely say to yourself “Self, I am hungry and therefore I need to eat” ... Your hunger may not even be afully self-aware state just yet.>> at some point you may ﬁgure out that you have a particular need, and it may actually be one of many needs that spawn fromthe situation you’re in ...So, “I’m hungry” leads to “I NEED to eat something” ... and also, possibly “I NEED to get food because I don’t have any at homeright now” ... or even “I NEED to ask the person next to me if they’re hungry too so I won’t be rude”.>> Only then does someone start to formulate the basic outlines of actual tasks to take care of those needs. And all of thishappens in a sort of blur, before you have fully rationalized what you’re doing.So tell me ... How many requirements documents do you read that see the user this way?Or better yet, how many Agile user stories have you read that acknowledge the situational origin of the user’s activity?In waterfall or agile, or even in user testing, we normally jump straight to the task and small-bore functionality -- we break thetasks up into silos, assuming they’ll magically make sense together when we launch a product.
Google Buzz Situation Need Task Situation Situation Need Situation Need Need Situation MacObserveWant some real-world proof of my point?When Google designed Buzz, they used an “eat your own dogfood” approach -- testing it with wider and wider circles of GoogleEmployees.They designed lots of intricate tasks, but they were addressing the speciﬁc behaviors of people within Google -- not outsidefriends or family.>> When it was unleashed to the world, there was a huge clash ... the context was completely different, and the designed taskshad repercussions Google simply hadn’t foreseen ... because they were invisible to them.>> The result? Buzz was shuttered, and it earned Google 20 years of monitoring from the Federal Trade Commission.(ref: http://news.cnet.com/8301-30684_3-10454683-265.html)
Early Adopters ... ± 75 - 80% Male ± 60% Software Engineers & Developers So much fun to create entity- relationship diagrams of everyone you know!Did Google learn its lesson about user context & behavior?Well Google Plus has some improvements in terms of privacy,but its early adopters leaned heavily toward software engineers who evidently ENJOY organizing everyone they know into anentity-relationship diagram.http://mashable.com/2011/07/14/google-plus-male/
Sure, sometimes users have goals. But let’s not start with that assumption.@inkblurtSo do users really NEVER have goals??In spite of my link-bait talk title, I’ll have to admit that yeah, sometimes users do have fully articulated goals.But my argument is we shouldn’t start with that assumption.Start by saying “these users don’t have goals ... so how do I design for everything else?”I bet if you do that, you’ll end up discovering contextual facets you would otherwise have missed, and you’ll be satisfying moreusers than you would otherwise.
Let’s start design HERE. Where desires and behaviors begin.@inkblurtWe know a lot about designing for tasks.But what about designing for this fuzzy, desire-driven, pre-conscious, situationally complex area of people’s lives?This is where our increasingly pervasive, ubiquitous, embedded products are available to people, and it’s where they are mostrelevant ... where desires and behaviors truly begin.
THANKS! @inkblurt andrewhinton.com@inkblurt>> and with that, I thank you for your time!