User Behavior

User research is a crucial part of the design process. It helps to bridge the gap between what we think users need and what users actually need. User research is a systematic process of gathering and analyzing information about the target audience or users of a product, service or system. Researchers use a variety of methods to understand users, including surveys, interviews, observational studies, usability testing, contextual inquiry, card sorting and tree testing, eye tracking

studies, A-B testing, ethnographic research and diary studies. By doing user research from the start, we get a much better product, a product that is useful and sells better. In the product development cycle, at each stage, you’ll different answers from user research. Let's go through the main points. What should we build? Before you even begin to design you need to validate your product idea. Will my users need this? Will they want to use it? If not this, what else should we build?

To answer these basic questions, you need to understand your users everyday lives, their motivations, habits, and environment. That way your design a product relevant to them. The best methods for this stage are qualitative interviews and observations. Your visit users at their homes at work, wherever you plan for them to use your product. Sometimes this stage reveals opportunities no one in the design team would ever have imagined. How should we build this further in the design process?

You will test the usability of your design. Is it easy to use and what can you do to improve it? Is it intuitive or do people struggle to achieve basic tasks? At this stage you'll get to observe people using your product, even if it is still a crude prototype. Start doing this early so your users don't get distracted by the esthetics. Focus on functionality and usability. Did we succeed? Finally, after the product is released, you can evaluate the impact of the design.

How much does it improve the efficiency of your users work? How well does the product sell? Do people like to use it? As you can see, user research is something that design teams must do all the time to create useful, usable and delightful products.

We have tendencies to see things in one way or another. And that's about all sorts of things. That can be about serious personal issues; it can be about trivial things. Often the way in which *something is framed to us can actually create a bias* as well. A classic example, and there are various ways you can do this, is what's called *anchoring*. So, if we're asked something and given something that *suggests a value*,

even if it's told that it's just there for guesswork purposes or something, it tends to hold us and move where we see our estimate. So, you ask somebody, "How high is the Eiffel Tower?" You might have a vague idea that it's big, but you probably don't know exactly how high. You might ask one set of people and give them a scale and say, "Put it on this scale; just draw a cross where you think on this scale from 250 meters high to 2,500 meters high.

How high on that scale?" And people put crosses on the scale – you can see where they were, or put a number. But alternatively, you might give people – instead of having a scale of 250 meters to 2,500 meters, you might give them a scale between 50 meters and 500 meters. Now, actually, the Eiffel Tower falls on *both* of those scales; the actual height is around 300 meters. But what you find is people don't know the answer; given the larger, higher scale, they will tend to put something that is larger and higher,

even though they're told it's just a scale. And actually, on the larger scale, it should be right at the bottom. Here, it should be about two-thirds of the way up the scale. But what happens is you, by framing it with big numbers, people tend to guess a bigger number. If you frame it with smaller numbers,  people guess a smaller number. They're anchored by the nature of the way the question is posed. So, how might you get away from some of this fixation? We'll talk about some other things later,

other ways later. But one of the ways to actually *break* some of this bias and this fixation is to *deliberately mix things up*. So, what you might do is, say, you're given the problem of *building* the Eiffel Tower. And the Eiffel Tower I said is about 300 meters tall, so about 1,000 feet tall. So, you might think, "Oh crumbs, how are we going to build this?" So, one thing you might do is say, "Imagine instead of being

300 meters tall, it was just 3 meters tall. How would I go about building it, then?" And you might think, "Well, I'd build a big, perhaps a scaffolding, or 30 meters tall – I might build a scaffolding and just hoist things up to the top." So, then you say, "Well, OK, can I build a scaffolding at 300 meters; does that make sense?" Alternatively, you might say, "Perhaps it's 300,000 *miles* tall, basically reaching as high as the Moon. How might I build it, then?" Well, there's no way you're going to hoist things up a scaffold.

All the workers at the top would have no oxygen because they'd be up above the atmosphere. So, you might then think about hoisting it up from the bottom, building the top first, hoisting the whole thing up; building the  next layer; hoisting the whole thing up; building the next layer – you know – like jacking a car and then sticking bits underneath. So, by just thinking of a *completely different* scale, you start to think of different kinds of solutions. It forces you out of that fixation. You might just swap things around. I mean, this works quite well if you're worried

that you're using some sort of racial or gender bias; you just swap the genders of the people involved in the story or swap their ethnic background, and often the way you look at the story differently might tell you something about some of the biases you bring to it. In politics, if you hear a statement from a  politician and you either react positively or negatively to it, it might be worth just thinking what you'd imagine if that statement

came from the mouth of another politician, that was of a different persuasion; how would you read it then? And it's not that you change your views  drastically by doing this, but it helps you to perhaps expose why you view these things differently. And some of that might be valid reasons; sometimes, you might think, "Actually, I need to rethink some of the ways I'm working."

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.

For you, one of your biggest biases and issues as a designer if you're a visual designer or if you're working on a website or app that – you know – you're a stakeholder on the team, it's going to be the fact that you can actually  see what's on a screen, assuming that you're not blind, that you're actually reviewing visual designs.

And the things that I found that are the biggest challenges for visual design are the *semantics*. So, words make sense when you look at them or descriptions are aided with a visual cue; you know – confirmation messages visually colored or it flashes up and there's something that gives you a visual cue there, error messages the same thing. So, these kind of semantics of – you know –

that you understood an error message or you understood something are one of the things we just get used to. And then we forget what it might be like if you don't have the visual crutch. So, this example here is a quiz, and this is where we saw this, when we were optimizing this quiz, that  when we were looking at the accessibility of it, the problem with it – so we went through and we made it accessible, so you could

keyboard and tab through the the different choices – and then we tested it with a user. And we were like, oh – we totally didn't realize this. What was happening is that the correct answer was appearing to the left of the answer choice. And the problem was that when it announced the correct choice, even though it was accessible, it didn't say which one it was.

So, say Choice B was circled and then the correct answer was displayed over there, but it just didn't have this semantic of saying, "The correct answer is Choice B (blah blah blah blah blah)." So, very simple, but a good reminder of like, oh yeah – you know – reinforcing the fact that your visual bias adds context; that might not be there when it's read aloud or when it's navigated through an audible experience like a screen reader.

The second bucket for visual bias is the interaction; it's the little animations or little micro-interactions that are occurring on a screen are another source of – you know – it's like, "Well, I saw that, but a screen reader didn't." You know. So, being aware of that, as well as the third one, which is *place*. So, like the location on a screen or movement that occurs – some meaning from a state change.

Like a hover is a classic one – you hover on and off and it kind of tells you that it's a clickable element or it tells you that nothing's happening. Sometimes you click on stuff, play buttons or you click on elements on a screen that are loading like a button or something like that – nothing happens. And then you can kind of tell nothing's happening because if you have a little technical proficiency as a user, you can look down and see if the page is loading on your browser in the lower-left corner

or you can see that nothing happened – you push the button and nothing happens. Well, if you don't have that visual cue or if something is placed in an area of a screen that you have to kind of navigate back up to the top if you're using assistive technology, that's going to be a blocker. Right? So, visual bias I think is our worst enemy because  we're so familiar with it, we're so used to it   that we've forgotten that we are, so we have that crutch.

There's more than one bias, though. There's *mouse-heavy bias*. So, we've gotten used to the fact that we use mice all the time and as designers we require point and click a lot. So, it took me a while to realize how important this was. Many years ago when I was doing lots of usability – you know – kind of user studies and going out and talking to users, then when you're doing B2B studies (business-to-business studies), you usually run across

that one user who is the keyboard user,  and it's like "I don't use the mouse." Like, this woman is using this very important software for the company and sometimes she's the only user. And she's going through and just because of the speed that she needs to input, it's keyboard-driven. Now, we found this with many types of applications like that, so designing for keyboard accessibility for the heavy input user is just something  that you end up supporting.

It's one of these universal type of design approaches. And so, with accessibility, we're blocking users if we make things too mouse-dominant because then they're not able to use the keyboard. And without the keyboard, there's  usually not a focus state related to that. So, we'll talk more about focus states just like we've been talking about since they're so important.   Now, the other bias is the *color bias* – so we've talked about color blindness.

And for example, putting error messages only in red text. And if you recall the guideline there is to add a supporting element like another visual element to reinforce the color. Don't just use color alone basically. So, watch out for those three biases:  *visual bias, color bias and mouse bias*   because as a sighted designer or business person  or developer you're probably

going to be biased by those things. Now, in the design phase, some of the very basic accessibility things you should be nipping in the bud, in other words, stopping them before the train goes down the track are things like *typography*, so the size of your font; designing and defining that up front or making sure that that's documented in a style guide is really important. If it's not, then that's where a developer needs to be familiar with accessibility so they can stop it

at their stage of coding or a front-end web developer who's putting together a style sheet that will call those styles. So, *color contrast* is the other big classic, and I think if there's one skill that any good designer – and I'm talking visual designer – needs to learn, it's *high contrast* because that seems to be the big one from the dozens of designers that I've worked with over the years. It seems like they give me designs all the time that are low contrast. It's the gray on gray, as I like to joke.

Then *link visibility and target size* is the other one. This is all up front. So, before you even get to thinking about accessibility, you should be thinking about that. And then *labeling or label proximity* – so how close the label is to the element that you're trying to get the call to action on. Once you have those basics, then you can add *predictability and consistent navigation*;

things like the focus, focusability, and then the blocks of content being separated and distinct from each other.

So, task analysis is an  extremely important technique. And, to be clear, you can do your task analysis when you do your regular user research and interview observation; that's the observation side. That's where you ask a user, "Hey can you show me how you do it today?" Now, don't worry about the technology;  don't worry about any tools they may be using

– you know – existing applications or whatever. Just have them go through what they normally do. It's even great in task analysis to see things in the absence of some technology like your design or whatever. So, if they want to show you how they  normally do it, then you'll get to see their kind of workarounds, their patterns, their shadow spreadsheets – you know – ways of coping, their hacks and their adjustments, things they've done to make it work.

And that stuff is just beautiful. But having them step through their problem solving step by step, kind of 'teach me how you do it' – that's the basis of task analysis. If you're doing *ethnography*, which is similar to interview observation – you're essentially looking  for a few more cultural cues with ethnography; you're looking for things of cultural significance, and it might just be user culture. It might be in that region of the country you're learning about the users.

Or it might be at a national level or international level if you're doing localization or cross-cultural research. It might even be the culture of an underrepresented group if you're doing inclusive research and inclusive design, trying to understand the experience of that community, their history, their lived experience as it relates to the problem they're trying to solve or how they approach it. So, task analysis is definitely one of these things  that you want to build into your tool set.

And essentially what you're going to do is take those observations from your research and you're going to map them out and kind of flow chart them, flow diagram them and see how you can take that structure and map it to your design kind of like as the user goes from here to here to here, how can my screen support this thing that they do  here with this tool or this feature? Kind of see how you can make it flow much more intuitively

so it feels good and makes sense to your users.

*When and Why to use Analytics* Primarily, we're going to need to be using  analytics on existing solutions. So, if you're talking about *green field* – which is a brand-new solution, hasn't been built and delivered yet –  versus *brown field* – which is something that's  already running but perhaps we want to improve it – then we're decidedly on the brown field side.

So, we're looking at existing solutions because it's only existing solutions that can provide us with the analytics. If you haven't got an existing solution, you're going to have to use another technique. And there are obviously many other techniques, but they're not going to provide you with much in the way of *quantitative data*. We do have early-research methods, which we'll  be talking about very briefly as an alternative, but predominantly analytics for existing deployed  solutions.

Having said that, then if you're looking at a rework of an existing site or app, then looking at current analytics can tell you a lot about what you might like to address; what questions you might like to raise with your team members, stakeholders, users. So, those are important considerations. A good starting point in organizations or teams with low UX maturity is analytics because analytics are easier to sell – to be honest – than qualitative methods.

If you're new to an organization, if they're only just getting into user experience, then trying to persuade colleagues that they should be making important decisions on the basis of six to eight qualitative sessions, which is typically what we do in the usability lab, then you should find by comparison web analytics a much easier thing to persuade people with. And the other issue particularly relevant to qualitative methods

is that quantitative methods tend to be very,  very much cheaper – certainly on the scale of data, you are often having to talk in terms of  hundreds of dollars or pounds per participant in a *qualitative* study, for various expenses; whereas a hundred dollars or pounds will get you potentially hundreds or thousands of users. And, in fact, if you're talking about platforms like Google Analytics which are free, there is no cost other than the cost of understanding and using

the statistics that you get out; so, obviously  it is very attractive from a cost perspective. Some of the things that we'll be needing to  talk about as alternatives to analytics or indeed *in addition* to analytics: Analytics can often *highlight* areas that we might need to investigate, and we would then have to go and consider what alternatives we might use to get to the bottom of that particular problem.

Obviously, *usability testing* because you'll need to establish *why* users are doing what they're doing. You can't know from analytics what users' motivations are. All you can know is that they went to *this* page and  then they went to *that* page. So, the way to find out if it isn't obvious when you look at the pages – like there's something wrong or broken or the text makes no sense – is to bring users in and watch them actually doing it, or even use remote sessions – watching users doing the thing that has

come up as a big surprise in your analytics data. A/B testing is another relatively low-cost approach. It's – again – a *quantitative* one, so we're talking about numbers here. And A/B testing, sometimes called *multivariate testing*, is also performed using Google Tools often, but many, many other tools are available as well; and you show users different designs;

and you get statistics on how people behaved and how many converted, for example. And you can then decide "Well, yes, putting that text there with this picture over here is better than the other way around." People do get carried away with this, though; you  can do this ad nauseam, to the point where you're starting to change the background color by minute shades to work out which gets you the best result. These kinds of results tend to be fairly temporary. You get a glitch and then things just settle down afterwards.

So, mostly in user experience we're  interested in things which actually really change the user experience rather than getting  you temporary blips in the analytics results. And then, finally, *contextual inquiry* and *early-design  testing*: Contextual inquiry is going out and doing research in the field – so, with real users doing real things to try to find out how they operate in this particular problem domain; what's important to  them; what frustrations they have;

how they expect a solution to be able to help them. And early-design testing – mostly in the web field these days but can also be done with software and mobile apps; approaches like *tree testing* which simulate a menu hierarchy. And you don't actually have to do anything other than put your menu hierarchy into a spreadsheet and upload it – it's as simple as that; and then give users tasks and see how they get on.

And you can get some very interesting and  useful results from tree testing. And another early-design testing approach is *first-click testing*. So, you ask users to do something and you show them a screenshot – it doesn't have to be of an existing site; it can be just a design that you're considering – and find out where they click, and is where they click helpful to them? Or to you? So, these are examples of early-design testing – things that you can do *before* you start building

a product to work out what the product should look  like or what the general shape or terminology or concepts in the product should be. And both of these can be used to find out whether you're on the right track. I have actually tested solutions for customers where users had no idea what the proposition was: "What does this site do?"; "What are they actually trying to sell me?" or "What is the purpose of it?" – and it's a bit late to be finding  that out in usability testing towards the end of a project, I have to say. And that was indeed  exactly what happened in this particular example

I'm thinking of. So, doing some of these things  really early on is very important and, of course, is totally the opposite of trying to use web analytics, which can only be done when you finish. So, do bear in mind that you do need  some of these approaches to be sure that you're heading in the right direction *long before* you  start building web pages or mobile app screens. Understand your organization's *goals* for the interactive solution that you're building.

Make sure that you know what they're trying to get out of it. Speak to stakeholders – stakeholders are people typically within your organization who have a vested interest in your projects. So, find out what it's supposed to be  doing; find out why they're rebuilding this site or why this mobile app is being substantially  rewritten. You need to know that; so, don't just jump in and start looking for interesting numbers.

It's not necessarily going to be that useful. Do know the solutions; become familiar with them. Find out how easy it is to use them for the kinds of things which your stakeholders or others have told you are important. Understand how important journeys through the app or website work. And get familiar with the URLs – that's, I'm afraid, something that you're going to be seeing a lot of in analytics reports – the references for the individual pages or screens,

and so that you'll understand, when you actually start looking at reports of user journeys, what that actually means – "What do all these URLs mean in my actual product?" So, you're going to have to do some homework on that front. You're also going to have to know the users – you need to speak to the users; find out what they think is good and bad about your solutions; find out how they think about  this problem domain and how it differs from others and what kind of solutions they know work and what  kind of problems they have with typical solutions.

Also ask stakeholders and colleagues about known  issues and aspirations for current solutions. So, you know, if you're in the process of rebuilding  a site or an app, *why* – is it just slow-ish? Is it just the wrong technology? Maybe. Or are there things which were causing real problems in the previous or current version and that you're hoping to address those in the rebuild.

Accessibility ensures that digital products, websites, applications, services and other interactive interfaces are designed and developed to be easy to use and understand by people with disabilities. 1.85 billion folks around the world who live with a disability or might live with more than one and are navigating the world through assistive technology or other augmentations to kind of assist with that with your interactions with the world around you. Meaning folks who live with disability, but also their caretakers,

their loved ones, their friends. All of this relates to the purchasing power of this community. Disability isn't a stagnant thing. We all have our life cycle. As you age, things change, your eyesight adjusts. All of these relate to disability. Designing accessibility is also designing for your future self. People with disabilities want beautiful designs as well. They want a slick interface. They want it to be smooth and an enjoyable experience. And so if you feel like

your design has gotten worse after you've included accessibility, it's time to start actually iterating and think, How do I actually make this an enjoyable interface to interact with while also making sure it's sets expectations and it actually gives people the amount of information they need. And in a way that they can digest it just as everyone else wants to digest that information for screen reader users a lot of it boils down to making sure you're always labeling

your interactive elements, whether it be buttons, links, slider components. Just making sure that you're giving enough information that people know how to interact with your website, with your design, with whatever that interaction looks like. Also, dark mode is something that came out of this community. So if you're someone who leverages that quite frequently. Font is a huge kind of aspect to think about in your design. A thin font that meets color contrast

can still be a really poor readability experience because of that pixelation aspect or because of how your eye actually perceives the text. What are some tangible things you can start doing to help this user group? Create inclusive and user-friendly experiences for all individuals.