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.