Gamification User Research

We have a lot of different types of motivation. And we do not have one theory of motivation  that can explain all of human behaviors. So, let's just focus on two of the main  types of motivation that we care about. That is really useful especially in the  game industry but also elsewhere. It's *extrinsic motivation* and  *intrinsic motivation*. Extrinsic motivation is when you do  something, an activity or task, in order to gain something  external to that task.

So, let's say that you're doing a summer  job, not because you care about the job but because you need the money so that you can do whatever you want to do with the money. That's an example of extrinsic motivation. And in games we do have a lot of  that; we do have moments where you're going to do a mission, for example a  quest, not necessarily because you really  care about the quest; you don't necessarily  care about killing 10 wolves.

But you do need the pelts or the fur  or whatever, the fangs to craft  something that you need, and in the  game industry we do that a lot. We have a lot of *clear goals* that are  attached to *meaningful rewards*. Emphasis on *meaningful* – it's not  enough to just have goals and rewards and "if you do that, you're  going to gain this". What's interesting in a good game is  that you try to think really forward and say you – there's a very bad enemy

and you would like to defeat that enemy,  but you do not have the proper weapon that can help you defeat that  enemy because it's super strong. To gain that weapon you need to be able to craft  it because there's no other way to have it. And to craft it you need some ingredients,  and you're missing some of these ingredients, say, copper ore, and you cannot  it find anywhere in the game. And you will find a quest that is offering  you copper ore if you complete it.

That makes that reward meaningful because you  already know what you're going to do with it.  And that's really, really important because I see  like when we gamify things we have a tendency to add objectives and rewards with the  objectives and sometimes the rewards are just like badges and stuff like that. And  if you don't know what you're going to do with those badges, this is not a  meaningful reward. In games;  in a good game we always try to make sure  

that there is a problem, a challenge and something that needs to be solved.  We're blocked, and the reward is  a way to unlock the player. So, that makes it meaningful and that  makes it that you want to think forward and you know how you can accomplish your  goals and go through the different hoops. We also think about short term,  medium term and long term. You know, not just like the long-term goal  to save the world or finish the game, but you know there are like big bosses or  things that you want to accomplish, and

this is what makes the short-term goals –  you know – do one quest so that you can gain the ore so that you can craft the  things so then you can defeat the boss. That's what makes it really interesting. But extrinsic motivation is a good  drive, but it's not enough. We also need *intrinsic motivation*. Intrinsic  motivation is when we do something for the pleasure of doing it. We have a very good theory

to explain that. It's called  *self-determination theory*,   or *SDT* for short. It's very   reliable and has been studied for the past decades. This theory explains that we are more  intrinsically motivated to accomplish certain activities when these activities  satisfy our needs for competence,  autonomy and relatedness. *Competence* is having a sense of progression. So, whether it is at work, in a game, in your life  – like if you, let's say, learn a new skill,

like let's say you want to learn a new  language or a new music instrument, if every day that you practice you  feel that you're progressing, like now you can converse more easily or  you're able to play a song more easily, then you feel competent – your  efforts are paying off. It's really important to feel  that sense of competence because   if you put some efforts into something, a new activity, a new job, whatever it is   and you don't feel that you're progressing, then this is when you are really demotivated.

And the problem is again emphasis  on *feel of progressing*. Sometimes we do something like exercising  every day, and that's really helpful for our health, but we don't  necessarily feel it. And that's a problem in  health in general, is that people don't necessarily feel the benefit  of taking the medications every day or doing some exercise every day. And this is when having a device that is   helping you feel, making you feel this sense of progression, that can really help.

So, for example, if it's really  hard to exercise like 30 minutes every day to think about it, now  if you have a device that helps you say,   like your goal today is to do 10 000 steps and  show you your progression towards that goal, it's really more powerful because then you can  see yourself progressing towards that goal.   So... that's why progression bars are so  powerful, and it's not just because of the  

extrinsic motivation that comes with it  because you know once the bar is full, then you have a reward; it's also because  it's a great feedback on your progression, and especially on progression that you cannot  necessarily really feel for yourself, like anything health-related is a  good example, but then many times it's really hard to tell if  you're progressing or not. So, having a sense of progression is critical in  games; there's a lot of things that are around competence, and it's important to understand that  

the sense of progression, that feeling of competence,   it does not necessarily mean that you don't, you never die and you never fail; in games, we see that all the time, that  people actually persevere and if   they fail and they die and they start again – if   they are getting better next time, then you have a sense of progression. So, the idea is not to never have people fail,  and actually failing is very important for learning. But it's also very important to  feel competent; if you fail the first or the

second time but then you succeed, just like you  try to complete a level or to defeat a boss, it's really hard, but at some point you  overcome it and you manage to kill it, then you feel great, you feel a great sense  of accomplishment, that sense of competence because it was difficult and you  persevered and then you succeeded. And so, in games what's important is when  people fail and when they die in the game, it's really important that we convey *why* they  did and *how* they can get better next time.

So, failure is not necessarily a problem as  long as when people try again, they progress. So, that sense of progression is really  important; it's very important in your job, when you get a promotion, yes, you have  the external, the extrinsic reward of having more money that comes with it but it's  also a great feedback on your competence. And so, that's why it feels so good. Autonomy is a lot around self-expression, so it  can go from just choosing your environment,

so customizing your environment, all the way  to being creative and creating stuff yourself. There's a lot of nuances there, but  it's, again, at work if you have a boss that micromanages you, it doesn't feel  good, because you don't have autonomy; whereas if you have a boss that tells you,  "Okay, this is our objective for the month," then "Do what you have to do to get  there. I trust your judgments," then it feels much better because then you  feel you have autonomy to get there.

So, in games, of course there's a lot  of games that offer customizations, so you then smooth in Fortnite or you  choose your hats or your clothing or just customize your environment, but it's much more powerful when you can   choose your objectives, how to solve problems. So, in games that we call Sandbox,   like Grand Theft Auto, this is very powerful. It doesn't have to be violent to be powerful,  

but it's really like a Sandbox and you can try a lot of things,   that's really strong in autonomy. Or in a game like Minecraft, you also   can try a lot of things and you can also be creative and like just design what you want to   design; that's really strong autonomy. And last but not least, *relatedness*; we're a very social species; we would not have survived without each other, and so anytime we can have a  meaningful relationship and an activity,

that's going to make it more  intrinsically valuable. And so, there's a lot of focus on  competition, with, yes, it is a thing. But it's not as powerful as cooperation  actually, also especially for learning. And most games are cooperative; even  competitive games are oftentimes team-based, so you're cooperating within a team  and then competing against another team. So, a lot of games also are more popular  if they're multiplayer because of that

relatedness aspect, and now you can  see games like Roblox or Fortnite where it's just like hanging out  with friends, just dancing together,   watching a movie together. That's also relatedness. So, it's really, really important to think about  competence, autonomy, relatedness as they relate   to your product and how you can really put that emphasis for that to users. And some games have a good balance of  everything, like RPGs (Role-Playing Games).

You choose your role, so that's autonomy;  you're within a team, so that's relatedness, and hopefully you can accomplish  your role in the team. Like if you're the Healer, you have specific  tools to help so that you can heal your teammates on time and that's competence. But you have games like really super focused on one or two elements, like Minecraft is really, really the emphasis, like the power is really on autonomy. So, depending on what you're trying to  accomplish, try to think how you can

put forward competence, how people  are progressing, their autonomy; let them choose their path, their objectives,  or just let them customize their environments and relatedness, how can they play with friends or challenge others, their friends or cooperate  with them and help them out? So, and think about the extrinsic motivation  like the objectives and rewards and how they can support intrinsic  motivation. Like if they have a reward,

how does that reward make them more  competent or how does it make them having more autonomy? Maybe it's a reward that  helps them customize their environment. Or maybe it's a reward they can gift to  someone else, and that's relatedness.

We're going to be talking  about writing good questions. The quality of the questions, along with the quality of the respondents, is really key. So, you have to have questions which people understand, that they really can address *unambiguously*; they don't have to sit wondering what it is you meant by that, and to do it pretty quickly, too – they need to be *short*.

So, we have a long list of various  points you should take into account. And it starts with the the issue of *shortness and ambiguity*. So, we want things to be as *short as possible*. We want to use short questions, short words. We want to be *very specific*, and we want to be *very unambiguous*. So, you don't ask vague questions. If you want to know about whether somebody has done something, you need to specify over what period. A lot of questionnaires these days I noticed ask,

'What did you do yesterday?' or 'Did you watch this yesterday? Did you do that yesterday?' And you could of course change that period as required, but it's very unrealistic to expect people to either mind-read if you're not being at all clear about when you mean, or to remember very far back. And that changes with the topic, of course. Somebody might remember when they were married from a long time ago, but the last time they visited a coffee shop – you might not get away with more than a couple to four weeks, for example.

Do use *common terms* and  provide *explanations* where you're using anything that's a little bit unusual. And common terms in  English are generally fairly short. So, use short words. Short words appear more frequently, are used more frequently. The number of syllables is actually a good indicator; the more syllables, the less frequent the word is used in English. And with a lot of interactive survey tools, you are able to provide explanations.

If nothing else works, then just put something parenthetically after the question to explain what it is you mean by that particular term. Start the questionnaire or the survey with *easy, uncontroversial questions*. If you're going to go on to be asking  sensitive questions or things that people might get slightly aggravated or upset about,  then try to leave that as late as possible. You want people to get engaged; you want them to feel comfortable, and to an extent trust you.

And starting with controversial questions or in some way irritating questions is not a good way to do that. Do *use words to label all points on a scale*. I've got a terrible question that I've made up about Brexit. But I've labeled every single point. Now, this used to be for me a debatable issue, that I suggested that perhaps we should just label  the two ends and number the points in between, but I've seen good evidence and firm advice that you should label all of the points in between the two.

Certainly on seven – this is a seven-point response – five or seven is fairly typical. And in those cases, you would expect to see words being used there. Address only *one aspect of a question at a time*. *Avoid compounds* like: 'I found the website quick and easy to use,' because there is the possibility that somebody found it easy to use but not quick, or quick but not easy. So, stop that from being a problem by asking those questions separately. Just like in navigation design, *do not use overlapping categories or ranges*.

People need to be very clear about where they should be clicking; so, you want '20-49', '50-64,' '65 and over', rather than '20-50', '50-65', '65 and over' because you can see in that latter example that there are two places  where people, if they were exactly 50 or exactly 65 would not be clear about where you actually want them to answer. And *do not ask leading questions* if you want honest responses,

or any responses at all, for that matter. Certainly, it's during various elections that have taken place over the last couple of years, I have seen numerous alleged surveys come round where clearly it is not a questionnaire or a survey at all; it is a party political statement, and I just stop  as soon as I realize that that is the case. And I believe a lot of other people do as well.  So, this example on 'How bad an idea is Brexit?' is an example of a leading or loaded question because of course some people think that Brexit is a perfectly good idea

and we should not be talking about it as a bad idea in their eyes. So, this is something that you would not do.  In fact, there are quite a few things in that particular example you should not do, so just  treat that as a bad example... *Avoid question grids*; I know that they  are extremely popular, but if you can avoid them, they are worth avoiding because  they are intimidating, certainly with the large question grids, people turn over to them online typically, and they immediately get put off. It looks very complicated. It is quite complicated.

If they were on the brink of not completing your questionnaire, that probably has pushed them over the edge. And if you're unlucky and are working with a service provider for your questionnaire, your survey tool, that doesn't support converting these into individual questions, then you'll find that they don't actually work on mobile phones. And that certainly does happen from time to time,  and of course we can expect more people to be

using mobile phones as their primary internet  tool; so, that would be a bad plan. Really the best way of approaching these is to ask the questions separately. And this is actually quite a bit more likely in the problem domain that we're talking about, which is user experience, rather than, say for example, market research where you might have a list of 10 or 20 coffee shops down the left-hand  side and the frequency of use across the top. That's still not easy for respondents, but it's  perhaps a little bit easier than asking them

deep, meaningful questions like this  particular one about Barack Obama. *Ranking questions* are those where you're asked  to re-order the responses. And the *problem* with them is twofold. One is that it's actually not very easy as a participant to do this, that you have to think about, 'Well, which of these is my preference? Which is my second preferred, third preferred?' etc. And it's off-putting to them; it's time-consuming; it's hard to do in some cases,

particularly on a mobile platform, but it might be  quite technically challenging, just the dexterity required, and it's also off-putting; you're making people think really hard about something where the detailed answers are not all that important.  What does it matter to you in a list of five whether somebody lists something  fourth or fifth? It's not first; it's not second; so, do you really care that  much about it?

It turns out to be very easy and almost equivalent. I have not seen a paper saying  that they're equivalent, by the way, but certainly when I've done it, I've not been disappointed. Just ask people to choose their *favorite*. Or, if you've got a long list, maybe their favorite  top 'n', where 'n' might be 2, 3, 4 ... And you're not talking about order, then; you're just talking about which is the most favorite or which are the two most favorite. And when you come to  analyze those, the analysis is very much simpler because it is just the items with the biggest  numbers are the most popular.

And that was the second point with the whole ranking thing – is that you have to do a *weighted analysis* in order to get sensible results from the ranking, which means  taking into account where in the list these things appeared; whereas if you're just asking people  to choose their favorite, it is very much easier and it's just slightly more complicated for their favorite two or their favorite three. And most survey tools will let you set a *maximum and minimum number of responses* for this kind of question.

So, if you really insist on having two choices from a  long list, then it could complain to participants that they've not selected two or preferably  a maximum is the better way of doing that so people cannot choose the full number if they  really don't care that much. So, that is something I would just strongly recommend you avoid altogether. It's really of no particular benefit. It looks fun when you're looking at it in the tool and  maybe on the screen yourself.

But when you're talking about lots of respondents getting to  it and dealing with it, it's not fun for them. Open-ended questions do allow some flexibility,  and of course they're not in any way going to replace an interviewer who can dig a lot more  deeply and try to interpret or understand what participants are saying. They have got their use, though, open-ended questions; the set of possible answers is unknown

or very large, is the main reason for doing that. So, if you've got a list of items and there are other possibilities, you will have an 'other' response, and under the 'other' response you will have a text box for people to fill in. Perhaps you want to know the underlying cause of a response – 'Why did you rate us like that?'; 'What was the main thing?' And that's certainly very commonly done and a perfectly good use of open-ended responses. Or you need to allow participants to express *unanticipated concerns*.

So, 'Is there anything that we could have done to have prevented this or to make you happier?' – that kind of question. And these two examples from SurveyMonkey: the top one is the final question in most SurveyMonkey templates. It's open-ended. And that's recommended for almost all surveys, that you give people a chance to comment about either your organization or the questionnaire or just general comments that they might have. 'Is there anything else you'd like to add?' is the kind of question you would ask there.

The bottom one is actually from their market research  template, and it has a lot of open-ended questions in it, but it's one of the very few SurveyMonkey templates that actually has more than one or two open-ended questions; so, you really can  largely – and perhaps should try largely – to stick to multiple choice questions. An alternative – and you may see this yourself as a respondent to various questionnaires – an alternative to extensive open-ended questions is to invite survey participants to take part

in an *online or telephone interview*. So, you might ask them a few questions, and they might express some reservations  about certain aspects of your product or service. And if they did that, you might offer them the  chance to be interviewed at depth, either by telephone or through some online collaboration tool. And of course that becomes, then, a primarily qualitative approach, and you would only do this with a relatively small number of participants,

mostly because it will be moderately time-consuming; you could expect it to take at least half an hour, and you will need a qualified  interviewer to do that. Do make sure that if you're using this approach that the interviewer does have access to the respondent's initial  questionnaire so they're not repeating themselves  or are not at all aware of the participant's background or complaint. *Semi-structured interviewing* is the most appropriate technique in most cases. So, this would be a follow-up set of questions and then just the interviewer exploring

some of the responses that the participant has given already.

Ah, well – it's a lovely day here in Tiree. I'm looking out the window again. But how do we know it's a lovely day? Well, I could – I won't turn the camera around to show you, because I'll probably never get it pointing back again. But I can tell you the Sun's shining. It's a blue sky. I could go and measure the temperature. It's probably not that warm, because it's not early in the year. But there's a number of metrics or measures I could use. Or perhaps I should go out and talk to people and see if there's people sitting out and saying how lovely it is

or if they're all huddled inside. Now, for me, this sunny day seems like a good day. But last week, it was the Tiree Wave Classic. And there were people windsurfing. The best day for them was not a sunny day. It was actually quite a dull day, quite a cold day. But it was the day with the best wind. They didn't care about the Sun; they cared about the wind. So, if I'd asked them, I might have gotten a very different answer than if I'd asked a different visitor to the island

or if you'd asked me about it. And it can be almost a conflict between people within HCI. It's between those who are more *quantitative*. So, when I was talking about the sunny day, I could go and measure the temperature. I could measure the wind speed if I was a surfer – a whole lot of *numbers* about it – as opposed to those who want to take a more *qualitative* approach. So, instead of measuring the temperature, those are the people who'd want to talk to people to find out more about what *it means* to be a good day.

And we could do the same for an interface. I can look at a phone and say, "Okay, how long did it take me to make a phone call?" Or I could ask somebody whether they're happy with it: What does the phone make them feel about? – different kinds of questions to ask. Also, you might ask those questions – and you can ask this in both a qualitative and quantitative way – in a sealed setting. You might take somebody into a room, give them perhaps a new interface to play with. You might – so, take the computer, give them a set of tasks to do and see how long they take to do it. Or what you might do is go out and watch

people in their real lives using some piece of – it might be existing software; it might be new software, or just actually observing how they do things. There's a bit of overlap here – I should have mentioned at the beginning – between *evaluation techniques* and *empirical studies*. And you might do empirical studies very, very early on. And they share a lot of features with evaluation. They're much more likely to be wild studies. And there are advantages to each. In a laboratory situation, when you've brought people in,

you can control what they're doing, you can guide them in particular ways. However, that tends to make it both more – shall we say – *robust* that you know what's going on but less about the real situation. In the real world, it's what people often call "ecologically valid" – it's about what they *really* are up to. But it is much less controlled, harder to measure – all sorts of things. Very often – I mean, it's rare or it's rarer to find more quantitative in-the-wild studies, but you can find both.

You can both go out and perhaps do a measure of people outside. You might – you know – well, go out on a sunny day and see how many people are smiling. Count the number of smiling people each day and use that as your measure – a very quantitative measure that's in the wild. More often, you might in the wild just go and ask people. It's a more qualitative thing. Similarly, in the lab, you might do a quantitative thing – some sort of measurement – or you might ask something more qualitative – more open-ended. Particularly quantitative and qualitative methods,

which are often seen as very, very different, and people will tend to focus on one *or* the other. *Personally*, I find that they fit together. *Quantitative* methods tend to tell me whether something happens and how common it is to happen, whether it's something I actually expect to see in practice commonly. *Qualitative* methods – the ones which are more about asking people open-ended questions – either to both tell me *new* things that I didn't think about before,

but also give me the *why* answers if I'm trying to understand *why* it is I'm seeing a phenomenon. So, the quantitative things – the measurements – say, "Yeah, there's something happening. People are finding this feature difficult." The qualitative thing helps me understand what it is about it that's difficult and helps me to solve it. So, I find they give you *complementary things* – they work together. The other thing you have to think about when choosing methods is about *what's appropriate for the particular situation*. And these things don't always work.

Sometimes, you can't do an in-the-wild experiment. If it's about, for instance, systems for people in outer space, you're going to have to do it in a laboratory. You're not going to go up there and experiment while people are flying around the planet. So, sometimes you can't do one thing or the other. It doesn't make sense. Similarly, with users – if you're designing something for chief executives of Fortune 100 companies, you're not going to get 20 of them in a room and do a user study with them.

That's not practical. So, you have to understand what's practical, what's reasonable and choose your methods accordingly.

This is a very typical project lifecycle in high-level terms. Generally start off with *requirements* – finding out what's needed, and we go off and talk to stakeholders. And one of the problems we have with *user requirements*, in particular, is that often analysts and requirements researchers in the IT world tend to go off and want to ask *users* what they want.

They don't really understand that users don't quite know what they want, that you actually need to do user research, and that is one of the biggest issues that we face in user experience: is the lack of understanding of user research and the whole field of user experience. From requirements, we might expect to be doing surveys to find out – particularly if we have an existing offering of some kind – we might find out what's good about it, what's not so good about it,

what people would like to do with it. And surveys might be helpful in those particular areas. Now, bear in mind that generally when we're talking about surveys, we already need to have some idea of the questions and the kinds of answers people are going to give us. It is really a very bad plan to launch a large survey without doing some early research on that, doing some qualitative research on how people think about these questions and these topics

and trying to understand it a little bit better before we launch a major  initiative in terms of survey research. We can also use surveys in *analysis and design* perhaps to ask people which kinds of things might work better for their particular needs and behaviors. We also can start to employ *early-design testing*, even in the analysis and design phase so that we've got perhaps some wireframes that we're thinking about on the *design* side,

and we can start to *test* them – start to try to find out: "Will people understand this? Will they be able to perform the most important tasks from perspective?" I have been involved in user testing of new product ideas where users had *no idea* what the service being offered was about because it was just presented *so confusingly*; there was no clear message; there was no clear understanding of the concepts behind the message because it wasn't very clear to start with, and so on.

So, early-design testing really has an important role to play there. *Implementation* and *testing* – that's when we can start doing a lot more in terms of evaluating what's going on with our products. There we would employ *usability evaluations*. And the things that I've called "early-design testing", by the way, can be done later on too. It's just they don't really involve the finished product. So, they're perhaps not quite as relevant. But if we've got questions about how the navigation might be changed,

then we might fall back to the tree testing where we're just showing people the navigation hierarchy rather than the whole site and asking them to perform tasks and just tweak the navigation as required to improve that. And one of my big complaints with our whole industry – still, after all these decades! – is that we do tend only to be allowed to do usability evaluations, and we do tend to wait until implementation has taken place

and the product is being tested before we start to try to involve real users, which really is far too late in the whole process. If you want to be able to be confident in the concepts and the terminology that your interactive solution is providing to your users and customers, then that needs to start way back at the beginning of the project cycle. And then, finally, once we've got live solutions available,

we can use *analytics* for websites and apps and we can also use A/B and multivariate testing to make sure that our designs are optimal. If we find problems, we might set up an A/B experiment to see whether this particular alternative would be a better solution or we could go down the multivariate route where we provide permutations of a *number* of different design elements on a particular page and see which  of those elements proved to be the most effective.

The fact that if you're doing project development,  software development in an iterative environment – like agile, for example – then you might be doing  a little bit of this in every single iteration; so, there might be a little bit of work on the  requirements at the front and there might be a little bit of design and analysis. Having said that, there is usually some upfront requirements and analysis and design that has to go on so that you know what *shape* your project is

– what *shape and size* I think is perhaps a better or more complete description – because in order for you to be able to even guess at how long this is going to take you, you need to have *scoped* it. And to scope it means to set the boundaries,  and to set the boundaries means to understand the requirements and to understand what kind of solutions would be acceptable; so, there will be some of this done always up front. Anybody who sets on a major project *without* doing upfront requirements analysis and design of some sort

is – I'm afraid – probably asking for trouble.

So, you've gone out, you've talked to your users. You've done a field study, basically interviews, user interviews and observations of their tasks, of their environment. And what do you do with that? Personas and journey maps. So, I just wanted to talk a little bit about personas in particular. Journey maps are also important, but I'm just going to cover personas. Where you get your data from is hugely important. Most people just use surveys.

Some people use focus groups. Those are both market research techniques. They're not appropriate for UX. Why? Because in UX we're looking at *behavior*, not at opinion. And focus groups and surveys do a lot of opinion elicitation. They're fine for marketing, but they really have no place in UX. So, if you do market research and just use  like a segmentation approach or market research approach, you're going to end up with a different type of persona.

So, if you do field studies, you'll end up observing their behavior and then creating behavioral profiles or role-based personas, and you'll understand better the context and the conditions under which your mobile app or device mobile content  is being consumed. And that's super important. This is an example of a persona, and you can adjust a persona. But basically you have a scenario. I've started writing my personas in first person.

So, literally the notes I take, I'll build the persona based on actually what the user said. And it's about 98% verbatim, like what they said with a few corrections of – you know – grammar and stuff like that. I won't change the meaning. I won't remove the words from their mouth and rephrase them in my head. I won't alter or fabricate them. And it's a technique that I learned from  Whitney Quesenbery, a UX consultant

who's written a book about storytelling and personas in particular, because personas are really about *stories*; they're really about telling stories about that context. Try it right now. So, think about the personas that might, the roles that people, the problems they might solve with your app. And in a narrative kind of style, write one or two sentences on their background to kind of set the context; write two or three more sentences on the problems that they're trying to solve, like the tasks, and two or three sentences on the call to action,

like what they need, what their desires are or how the design can basically help them get to their task, how can it empower them? How you can meet their needs, their goals, their tasks, their sub-tasks? If you have a lot of questions, it's probably because you need to spend more time with your users. Once you start hanging out with users doing field studies, you get to know what they need and the context of use becomes very apparent.

It's one of the most enlightening things I think about personas. But also you understand their *distractions*, their deeper kind of emotional and social context. You understand what multi-tasking they might be doing and what problem solving or the different states, the varied states that they might use, kind of usage scenarios, if you will,  but in different states. So, to create a role-based persona, identify the personas based on your data, so the themes that come out, the different hats that users are trying to wear.

And then give them a name, like not just like Sally or Susan or Jim or John or something. But give them an associating  adjective such as Support-Seeker Sally or Finance Fiona, I think was that other one there. Okay, so continuing with persona development, think about these things: *environmental impact*, so the context of use; *cognitive impact*, the time, for example, the time pressure or stress that they might be under.

Think of the *social impact* – the triggers that might lead to that such as another user or somebody else online or started a chat or tripped off – I don't know – a support call or whatever. And finally the *behavioral impact* – so, for example, the roles that not just the user has but the roles that the user must assume to complete the task. There's also *mental models*. So, mental models being these past expectations

that users bring to their designs; they basically influence how a user problem solves. And think about like the mental model for the restaurant experience – you know – what does that look like? For example, you enter the restaurant; there might be waiting, you might have to check in, you may have to order ahead, you might have a pickup situation. Some restaurants have made a separate place for the food delivery people to go

so that they're not standing there waiting with the the diners that are coming to the restaurant for the "live food". You can conduct *task analysis*, which is asking the user to do the task. You know – you can accompany them, a doctor's visit, restaurant visit, whatever it might be. You can accompany the user and look for the language they use, the way they talk about it, look at the physical, social environment, look at their functional needs and priorities and maybe  even the cognitive demands that they have.

So, for example, they have to figure something out; they have to fill in a form. They have to submit this. There's a pressure to answer these questions or to know something. Look at the task space, how they're making sense of things, how they're deciding or solving problems for themselves. Remember, we don't just have goals and tasks, but we have *sub-tasks* as well. So, we need all three of those things, not just goals. It's so important that we make sure that we drill deeper down

into our users' behavior so we fully understand what it is and bring that out. So, doing that, though, is so well worth it and makes you a much smarter designer and a much smarter design team.