Innovation in UX/UI Design

Let's talk about the difference between big,  innovative changes to our product and small, incremental improvements, and the kinds of research  that you might need in order to make these changes. We'll start with the incremental  improvements because that's really the most frequent kinds of changes  that we make as designers and researchers. While we all like to talk about designing things  from scratch or making huge, sweeping changes,

the vast majority of people spend a lot of their  time working on existing products and making them a little bit better every day. So, imagine you're building your new job marketplace to connect job seekers with potential employers. The product works. It's out in the real world being used by folks to find jobs every day. It's great! You made a thing that people are using, for money. Now, your product manager is looking at the metrics and they notice that a bunch of people are signing up and looking at jobs but they're not applying for anything.

Your job is to figure out why. So, what do you do? You can go ahead and pause the video and think  about it for a minute if you want. There are a lot of different options you could go with here, but at the very least you're going to want to figure out the following things: Where are people stopping  in the process and why are they stopping there? You'll probably want to dig into metrics a bit and  figure out if folks do anything besides just look at jobs. Do they fill out their profile? Do they  look at job details? Do they click the Apply button? And then do they give up at that point? Or do they never actually even get to that point?

Once you know where they're giving up, you'll  probably do some simple observational testing of actual users to see what's happening when  they do drop out. You'll probably also want to talk to them about why they're not applying. Maybe you'll find out that they get frustrated because they can't find jobs in their area. Well, that'd be great because that's really easy to fix; if that's the problem, maybe you can try letting them search  for jobs near them. That's an *incremental change*. Now, what do we mean by that? It doesn't necessarily mean that it doesn't have a big impact on metrics.

Things like this can be hugely important for your metrics. If you manage to get lots more qualified candidates to apply to jobs, that's a huge win for the employers who are looking for great employees and it doesn't matter that it was just a simple button that you added. But it's not a wildly innovative change.  In fact, it's a pretty standard feature on most job boards, and it's a very small improvement in terms of engineering effort, or at least it should be. If it isn't, there may be something wrong with your engineering department... which is a totally different course.

This change is *improving an existing flow*, rather than completely changing how something is done or adding a brand-new feature. OK, now, imagine that you're doing some observational research with your job applicants and you learn that for whatever reason they really don't have very much access to computers or they're not used to typing on a keyboard. This might lead to a very different sort of change than just searching for jobs in their area. Rather than making a small, incremental improvement to a search page, you might have to come up with an entirely  different way for candidates to apply for jobs.

Maybe they need to film themselves using their  phone cameras. This is a much larger change; it's *less incremental* since you're probably going to have to change or at least add a major feature to the entire job application process. You'll probably have to change how job seekers get reviewed by potential employers as well since they'll be reviewing videos rather than text resumes – which they might not be used to. This is a big change, but it's still incremental because it's not really changing what the product does.

It's just finding a new way to do the thing that it already did. OK, now, let's say that you have the option to do some really deep ethnographic research with some of your potential job applicants. You run some contextual inquiry sessions with them or maybe you run a diary study to understand all of the different jobs that they look at and learn why they are or aren't applying. Maybe in these deeper, more open-ended research sessions, you start to learn that the reason that a lot of potential job applicants drop out is because they just don't have the skills for the necessary jobs.

But what could *you* do about that? Well... our only options are either to find different applicants, find more suitable jobs or create some way to train our users in the skills that they need for the kinds of jobs that are available. All of those are really pretty big, risky ventures, but they just might be what we need to do to get more applicants into jobs. These are very big, and a couple of them are fairly innovative changes.

If the company pivots into, say, trainings and certifications or assessments, that definitely qualifies as innovation, at least for your product, but *how* does the research change for *finding* each of these sorts of things? Couldn't you have found out that applicants aren't qualified with the same types of research that you used to learn that they wanted to search by location? Maybe. Sometimes we find all sorts of things in  very lightweight usability-type testing, but  *more often* we find bigger, more disruptive  things in deeper kinds of research – things like contextual inquiry, diary studies or longer-term relationships that we build with our customers.

Also, bigger, more disruptive changes often require  us to do more in-depth research just to make sure that we're going in the right direction  because the bigger it is the more risky it is. Let's say we ran some simple usability testing on  the application process. That would mean we'd give applicants a task to perform, like find a job and apply to it. What might we learn from that? Well, that's the place where we'd learn if there were any bugs or confusing

parts of the system – basically, *can* somebody apply for a job? It takes more of a real conversation with a real user or a potential user to learn why they're not applying for jobs. It's not that one kind of testing is better than the other; it's that you can learn very different things with the different types of testing. Some types of research tend to deliver more in-depth learnings that can lead to big breakthrough changes, while other types of  research tend to lead to smaller, more incremental but still quite useful and impactful changes. Both are extremely useful on agile teams, but you may find that the latter is more common just because many

agile teams don't really know how to schedule those big  longer-term types of research studies, while running quick usability testing on existing  software is quite easy and can even often be automated.

So, this user adoption lifecycle is something that we found to be true based on about a dozen years of analyzing our client app projects at Experience Dynamics, my UX consulting firm. And just so you understand what's happening is that with websites users judge a website; they visually judge it;

it's actually like a very precognitive – they're not even aware; it's a 50-millisecond kind of snap decision, and they look at a site and if it's beautiful they say, 'Oh, that must be easy to use.' But mobile apps don't get that kind of luxury, because it's – you know – you're downloading, installing something; you don't go into the App Store or Google Play Store and look at the look and feel of an app. It's more like what it'll do for you, and you're usually driven to it by a task such as... 'learn yoga' or 'discover somebody near me'

or 'install a VPN' or whatever the thing might be that you're using the App Store for. So, the next one on this kind of curve – so let's assume *visual judgment* is gone in mobile. *Cognitive judgment* is kind of the thinking. It's when I'm thinking like, 'Oh, what do I do? Where do I go?' And web apps are classic for falling into this kind of poor ease of use trap. Web applications you log in and it's like: 'Where's my tasks?

What do I do?' It's just classic with web applications – it seems like, anyway, or at least they started out that way. They've gotten better over the years and gotten more task-oriented. But the context there is that it's not like a consumer, like a website typically. With a web app, it is a B2B user – most likely it's a B2B user – or if it is a consumer, they're logging into their bank account or whatever, they're not there to look at the branding and the visuals. It's very much like 'I need to get my stuff done.'

So, that's what I mean by cognitive judgment. So, with mobile we don't really have that, because there isn't really the time to sort of even stop to think. It's much quicker, and that's why you have such a high uninstall ratio with apps. So, I like to say that this lifecycle sort of starts – I mean, it includes, of course it touches I guess very briefly on these other ones, but really starts with *emotional judgment*. And emotional judgment is – you know – 'Does this have what I need?

Is this going to do what I need it to do, like quickly?' So, you might try it; you might turn on the VPN; you might try chatting with someone, or you might begin searching and then find 'Ah – there's nothing here! Oh it's not connect— it's not fast! I'm not really sure if it's connecting! I'm not sure what's going on!' And that's the emotional judgment of that kind of unfulfilled desire, and of course you want it to look good; so, good visual judgment. Of course you want tasks to be apparent, so good cognitive judgment. But really the party with mobile starts on emotional judgment. So, it's like

make sure that you have a *very strong value proposition*, a *very strongly differentiated experience* where it's like, 'Oh, yeah, it looks great. I know exactly what to do, and it's got what I need.' If you get that established, then you can go to the sweet spot, which is this intention to return or intention to keep the app. And after that, after that trust is built and that reflection, which is,

Don Norman in his Emotional Design model talks about reflection as kind of like a 'Hmm, would I keep that? Would I recommend it to a friend? I like that app. I'm not going to uninstall it.' I almost think of it like the test is like, you could ask a user this as well: If you had to delete 10 apps, which of these 10 apps would you delete and see if yours is in that list? So, if the app is so important it's fulfilling a really important role, the user will keep it and try and keep it no matter what.

So, starting with that kind of sense of mobile is highly emotional, that you want users to stick with your app to keep it there, knowing that that's your design goal and that you want to kind of hit that triangle and make sure you don't lose your users, otherwise they'll leave or defect – that's really what user adoption for mobile is all about.

User Interface Design Patterns are recurring components which designers use to solve common problems in interfaces. like, for example, when we think about those regular things that often are repeating themselves to kind of appear in, you know, in complex environments We need to show things that matter to people when they matter and nothing else. Right. it's just really sad what we see. Like, for example, if you look at Sears, right? Sears is just one of the many e-commerce sites, you know, nothing groundbreaking here. So you click on one of the filters and then the entire interface freezes

and then there is a refresh and you're being scrolled up. And I always ask myself, is this really the best we can do? Is really the best kind of interface for filtering that we can come up with, or can we do it a bit better? Because we can do it a bit better. So this is a great example where you have galaxies and then galaxies, you have all this filters which are in rows. Sometimes they take three rows, sometimes four or sometimes five rows. That's okay. Show people filters, show people buttons if they important show them.

Right. But what's important here, what I really like is we do not automatically refresh. Instead, we go ahead and say, "Hey, choose asmany filters as you like", right? And then whenever you click on show results, it's only then when you actually get an update coming up in the back. Which I think is perfectly fine. You don't need to auto update all the time. And that's especially critical when you're actually talking about the mobile view. The filter. Sure, why not? Slide in, slide out, although I probably prefer accordions instead.

And you just click on show products and it's only then when you return back to the other selection of filters and only when you click okay, show all products, then you actually get to load all the products, right? Designing good UI patterns is important because it leads to a better user experience, reduces usability issues, and ultimately contributes to the success of a product or application. It's a critical aspect of user centered design and product development.

You've probably all heard that phrase  'thinking out of the box'. Everyone tells you, 'Think out of the box.' And it sounds so easy, and yet it's so difficult. If we're talking about theory and creativity, then we've got to think about *de Bono and lateral thinking*. So, if you're thinking out of the box, then lateral thinking is almost, not quite but almost, the same thing in different words.

And this idea of doing things that are breaking the mold, that are not following a line obviously covers a lot of creativity  techniques, but particularly lateral thinking, de Bono's lateral thinking. The idea there is you've got, wherever you are, you've got your problem; you've got your start point. *Linear thinking*, in de Bono's terms, is very much about trying to follow the standard path, going along. So, if you're doing mathematics, you might pull the standard techniques off the shelf.

If you're writing a poem, you might be thinking line by line and thinking how each line fits and rhymes with the one before – if you're doing rhyming poetry, that is. So, it's all about following the same path of reasoning going on and on. *Lateral thinking is about trying to expand.* So, instead of following the same path of  reasoning, are there *different places to start*? You know – are there different ways of thinking  from the way where you are?

So, it's about trying to expand your idea of where you are outwards. So, that might be thinking of different solution strategies, so it might be thinking of different ways to start. Crucially, though, if you want to see out of the box  or get out of the box, you actually often need to *see the box*. If you're literally in a cardboard box, you know you're in it. But mental boxes – you don't actually know you're in them. It's not that there's a cardboard wall and you don't go beyond it.

It's more like a hall of mirrors, so you  never realize there's anything outside at all. Sometimes, *unusual examples* can help you see that. And that's, again, part of the reason for the bad ideas method, like *random metaphors* – things that, as soon as you've got something that *isn't in the box*, even if it's not a very good thing, it  helps you to realize because you say, 'Well, *why* isn't this a good solution? Why doesn't it *work* as a solution?'

And as you answer that question about why, what you're doing is you're *naming that cardboard wall*. And once you've named the cardboard wall and you know it's there, you can start to think of what might be outside of that box but perhaps is a better solution. If you think about some of the analytic method— combining those, those are about building a map of the territory, which is very much about naming the box, naming the walls, naming the boundaries, and by naming them, by seeing from a  distance what is there,

being able to then think of alternative solutions that are completely different. So, both alternative solutions help you to see the territory, help you to see the box. Of course, by seeing the box, that gives you the potential to have alternative solutions and actually you can iterate back and forth between those and hopefully build a better understanding  of what is there and what is constraining you. If you understand what's constraining you, then you can start to break those constraints.

I wanted to just spend a little bit of time on the *user journey*. So, we can see how important user research is to creating really compelling value propositions and creating value for organizations that are trying to use service design to innovate, improve, streamline and smooth out. Well, there's nothing better to tackle that with than the user journey.

I wanted to just spend a little bit of time on this technique in case you didn't have that much experience with it or maybe you were doing journeys in a way that was different to the way I'm going to present to you. At least, I just wanted to share a template with you that can give you better access to what you're looking for. For me, now, a journey is something that you *build on*. So, first off it's your *customer journey*.

And on that is your service blueprint. And remember that the journey is going to reveal those cross-channel like, say, *breakpoints*, *pain points*, *disconnects* that you can map in the different *swim lane diagrams* – is the official term for a journey map. So, it comes from that – these swim lanes. And so, you'll have like maybe your channels here – you know – you'll have your user tasks here, pains and gains, or you can just have positive (+) or negative (-).

And I tend to change my user journeys, try and improve them, try and improve them. One of the problems that I find with journey maps – and they became very popular, I think around 2010, maybe, was the heyday of user journeys – 2010 / 2012, maybe. It was all about this beautiful big visualization. Let's be clear: A customer journey map is *not* about impressing your team

with really cool, big swim diagram visualizations with tons of little icons. It's a document like all deliverables in a human-centered design perspective. It should work for the internal teams that are using it as a decision-making document *as well*. The thing about the journey map that's particularly of value to the service designer is that it's happening across time

or across stages or across goals. So, the stages of, say, the life cycle – you know – you might have Research, Compare, Purchase, then the Return shopping. In other words, it's not just the purchase. A lot of conversion optimization and approaches to selling online just focus on this part here: the compare and purchase, or the funnel – if you will – the purchase funnel. And I think it's important to have the acquisition as much as the retention.

This is the conversion here. So, these two steps are the conversion steps. It's important to have *all* those steps represented. *Happy / sad moments* – you can have a little smiley face; *disconnects and breaks* – you know – so that you're like: "Ah! This is a break right here. They're on their phone, and they're researching, but the site's not responsive or it's *partially* responsive. And then, compare – when they go to compare, it only allows three items. So, it's like "Ohh!" – and then we have a quote from the user going:

"Why does this only allow (imitated mumbling)?!" – you know – something communicating the pain point. The other thing it's going to have is your reflections from your ethnography, from your personas. It's going to have those real-world contexts, basically. Instead of basically making it up and doing it internally, you're going to base it on user data. You'll also want to have *recommendations*. So, down here at the bottom you can have a list of recommendations

as well. This is an example of a journey map we created. And you can see the touch points we've added along the way. So, we have these different stages. We've got this – as the user walks through. So, we have Pre-apply, Apply, Post-apply. This is an online application journey. And we have the various channels that are occurring there. We've got the pain points represented. And the steps are:

Discover, Research, Apply, Manage and Dream. Discover was important because a lot of people didn't know that the offers were there. This is for getting an account. And basically the value proposition is you're going to have these offers – targeted offers – sent to you. So, the key is to find out how people are currently applying and at what stage makes sense to offer them these upsells, basically. And that's the value add that's being offered here.

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.

In this video, I'm going to give you an exercise to do. It's going to be an exercise in *bad ideas*. This is where I tip your brain towards madness. But, hopefully – the boundary between creativity and genius and total madness  is often said to be a thin one; so, by pushing you a little towards madness, I hope to also push you a little towards creativity.

And hopefully, you can control the madness that comes there. But we'll see as it goes along. So, what I want you to do is – you know  how hard it is to think of good ideas; everybody says, "Ah! Let's have a brainstorming session and have lots of ideas!" and (sound effect), right? So, if it's so hard to think of good ideas, why not think of a *bad idea*? So, what I'd like you to do as an exercise is just to think of a bad idea or a silly idea, a completely crazy idea.

Now, it might be about something that you're doing at the moment. Or it might be a particular problem you've got. And so, what would be a really bad idea... for sending notifications to people about something you want to get them engaged in? Perhaps you could send them an email every three seconds or something like that! So, it could be that kind of bad idea, or  it could be just an idea from the world.

And it could be a Heath Robinson sort of bad idea – something that's complex and arcane and that. Or perhaps – and this is probably a good one to start with – just an *oxymoron*. So, something like a chocolate teapot, so something that appears to be really crazy, really silly; a car without an engine – I remember once in a session we had this – that doesn't seem like a good idea. So, you've got your bad idea – it may be a chocolate teapot

or it may be the car with no engine or something like that. What I want you to do now is – I'm going to take you through some prompt questions. First of all, this was a bad idea – the reason you chose it was because it was a bad idea. So, what I want you to do is say to yourself, "What is bad about this idea?" So, think of the car without an engine. What's bad about a car without an engine? Well, it doesn't have an engine; it's obvious, right?

So, you start off with that. Now, you might think a bit more. But then I want you to dig and say, "Well, *why* is that a bad idea?" Well, it's not got an engine – it can't go anywhere. Then dig a bit back further; so, are there things that you can think of that are like that, that have that property? So, for instance, a car without an engine can't go anywhere. Are there things that can't go anywhere that's actually a good idea? Well...

a garden shed: a garden shed doesn't go anywhere, but that's not a bad idea. And, in fact... you might want to have something that can't be stolen; you don't want that to go anywhere. So, that's not a bad idea. So, if you can think of things that appear to share the bad thing but actually aren't bad, what's the difference? Why is not having an engine, why is not being able to go anywhere bad for the car but not bad for the garden shed?

And as you dig into this, hopefully  you start to understand better these things. You can also go the other way around. So, you *know* this is a bad idea, but maybe there's something good about it. It hasn't got an engine; it's not polluting. Wow, we've got a green car! It will be green because all the moss will grow on it because it doesn't drive anywhere, but – you know – "This is good, surely?!"

So, then you can think, "Well, okay, if this is a good thing" – you can do the same sort of thing: "Why is that a good thing?" Well, it doesn't choke you with its pollution. If you're finding this difficult – and  particularly this is true about the bad idea bit – you want to say... with the bad idea, you want to change that bad thing into a good thing; so, this is whether you want to find a good thing in the bad idea or you want to find a good use for the thing you've identified that's bad – you might try a *different context*; so...

if you take the car off the road and put it  perhaps into something where it's moved along by something else – perhaps sitting on the back of a lorry... why, you might want that – well, you might want it so you can easily move your car. You might put it onto something that's dragged along. So, you sometimes change the context and suddenly something that seemed bad suddenly is not so bad. So, the final thing you can do with  your bad idea is *turn it into a good idea*.

Now, you might have  already done this as part of that process. So, what's *good*? When you've identified something that's good about it, like the car, that it wasn't polluting, try to hold on to that – try to keep that and retain that good feature. But where you found the things and you really dug down to *why something's bad*, not just the superficial – you know – it doesn't have an engine; well, that's not bad in itself,

but the fact that means you can't drive anywhere in it; okay, that's bad. So, can you change that badness but still retain the non-pollutingness? So, perhaps we're going to have a truly green car. Perhaps we're going to have roads with sort of little wires you connect into and – you know – a bit like Scalextric cars, so you can drag the cars along so they don't have  an engine and they're being powered elsewhere. You may, I said, *change the context entirely* – so, instead of it being a car for driving around in

– well, I've already mentioned this one – stick your chickens in it and it suddenly becomes a hen coop. And I think if you go around the  the world, you'll find a lot of old cars usually actually with their engines still  sitting in them that are being used as hen coops. If you had a *complex idea* – and this is true, it could be for a simple idea, but in doing your thinking, there might be just something about it, something small;

it wasn't necessarily the whole thing. So, actually – you know – the idea of the gap in the engine; perhaps you decided that would be really good actually having the engine not there because you could put things in the front, and for whatever reason, you think it's easier to put things in the front than the back. So, perhaps that becomes your idea – that  actually, you'd quite like to be able to put your luggage in the front of the car;  you'd like more room in the car for luggage. And then perhaps you'll put an engine back in the car, but thinking about

how you actually improve access for luggage. If you've had one of those Heath Robinson complex ideas, Wallace and Gromit-like ideas, then actually you may not be trying to make the whole thing into a good idea; but within it, some little bit of that complex mechanism might be something that you've thought about; you've realized and suddenly think, "Ahh!" and do something just with that. And I'll leave you with a glass hammer!

Personas are one of these things that gets used  in very, very many ways during design. A persona is a rich description or description of a user. It's similar in some sense, to an example user, somebody that you're going to talk about. But it usually is not a particular person. And that's for sometimes reasons of confidentiality.

Sometimes it's you want to capture about something slightly more generic than the actual user you talked to, that in some ways represents the group, but is still particular enough  that you can think about it. Typically, not one persona, you usually have  several personas. We'll come back to that.   You use this persona description, it's  a description of the example user,   in many ways during design. You can ask  questions like "What would Betty think?"

You've got a persona called / about Betty, "what would  Betty think" or "how would Betty feel about using this aspect of the system? Would Betty understand this? Would Betty be able to do this?"   So we can ask questions by letting those personas  seed our understanding, seed our imagination.   Crucially, the details matter here. You want to make the persona real. So what we want to do is take this  persona, an image of this example user,   and to be able to ask those questions: will  this user..., what will this user feel about  

this feature? How will this user use this system  in order to be able to answer those questions?  It needs to seed your imagination well enough.  It has to feel realistic enough to be able to   do that. Just like when you read that book  and you think, no, that person would never   do that. You've understood them well enough that  certain things they do feel out of character. You need to understand the character of your  persona.

For different purposes actually, different levels of detail are useful. So I'm going to sort of start off with   the least and go to the ones which I think are  actually seeding that rich understanding.  So at one level, you can just look at your  demographics. You're going to design for warehouse   managers, maybe. For a new system that goes into  warehouses. So you look at the demographics, you might have looked at their age. It might be that on the whole that they're   older. Because they're managers, the older end. So  there's only a small number under 35. The majority  

are over 35, about 50:50 between those who are in  the sort of slightly more in the older group.  So that's about 40 percent of them in  the 35 to 50 age group, and about half   of them are older than 50. So on the whole  list, sort of towards the older end group.   About two thirds are male, a third are female.  Education wise, the vast majority have not got   any sort of further education beyond school. About 57 percent we've got here are school.  

We've got a certain number that have done basic  college level education and a small percentage   of warehouse managers have had a university  education. That's some sense of things.   These are invented, by the way, I should say, not  real demographics. Did have children at home. The people, you might have got this from some big  survey or from existing knowledge of the world,   or by asking the employer that you're  dealing with to give you the statistics.   So perhaps about a third of them have got children  at home, but two thirds of them haven't. 

And what about disability? About three  quarters of them have no disability whatsoever.   About one quarter do. Actually, in society  it's surprising. You might... if you think   of disability in terms of major disability,  perhaps having a missing limb or being   completely blind or completely deaf. Then you start relatively small numbers.   But if you include a wider range of disabilities,  typically it gets bigger. And in fact can become  

very, very large. If you include, for  instance, using corrective vision with   glasses, then actually these numbers  will start to look quite small.  Within this, in whatever definition they've  used, they've got up to about 17 percent with   the minor disability and about eight percent  with a major disability. So far, so good. So now, can you design for a  warehouse manager given this? Well,  

you might start to fill in examples for  yourself. So you might sort of almost like   start to create the next stage. But it's hard. So let's look at a particular user profile. Again,   this could be a real user, but let's imagine  this as a typical user in a way. So here's Betty Wilcox. So she's here as a typical user.  And in fact, actually, if you look at her, she's   on the younger end. She's not necessarily the  only one, you usually have several of these.  And she's female as well. Notice only up to  a third of our warehouse ones are female. So  

she's not necessarily the center one. We'll come  back to this in a moment, but she is an example user. One example user. This might have been  based on somebody you've talked to, and then you're sort of abstracting in a way. So, Betty Wilcox. Thirty-seven, female, college education. She's got children at home, one's  seven, one's 15. And she does have a minor disability, which is in her left hand. And  it's there's slight problem in her left hand.  

Can you design, can you ask, what would Betty  think? You're probably doing a bit better at   this now. You start to picture her a bit. And you've probably got almost like an image   in your head as we talk about  Betty. So it's getting better.   So now let's go to a different one. You know, this  is now Betty. Betty is 37 years old. She's been a   warehouse manager for five years and worked for  Simpkins Brothers Engineering for 12 years. She didn't go to university, but has studied  in her evenings for a business diploma.

That was her college education. She has two children  aged 15 and seven and does not like to work late.   Presumably because we put it  here, because of the children.   But she did part of an introductory  in-house computer course some years ago.   But it was interrupted when she was promoted,  and she can no longer afford to take the time.   Her vision is perfect, but a left hand movement,  remember from the description a moment ago,   is slightly restricted because of an  industrial accident three years ago. 

She's enthusiastic about her work and  is happy to delegate responsibility   and to take suggestions from the staff. Actually,  we're seeing somebody who is confident in her   overall abilities, otherwise she wouldn't  be somebody happy to take suggestions.   If you're not competent, you don't. We sort of see that, we start to see a   picture of her. However, she does feel threatened  – simply, she is confident in general – but she   does feel threatened by the introduction of  yet another computer system. The third since she's been working at Simpkins Brothers. So now, when we think about that, do you have a better vision of Betty?

Do you feel you might be in a position to start talking about..."Yeah, if I design this sort of feature, is this something that's going to work with Betty? Or not"? By having a rich  description, she becomes a person. Not just a set of demographics. But then you  can start to think about the person, design for the person and use that rich human understanding you have in order to create a better design.

So it's an example of a user, as I said not  necessarily a real one. You're going to use this as a surrogate and these details really, really matter. You want Betty to be real to   you as a designer, real to your clients as you  talk to them. Real to your fellow designers  as you talk to them. To the developers around  you, to different people. Crucially, though, I've already said this, there's not just one. You usually want several different personas because the users you deal with are all different.

You know, we're all different. And the user group – it's warehouse managers – it's quite a relatively narrow and constrained set of users, will all be different. Now, you can't have one persona for every user,   but you can try and spread. You can look at the range of users.   So now that demographics picture I gave,  we actually said, what's their level of education? That's one way to look at that range. You can think of it as a broad range of users.

The obvious thing to do is to have the absolute  average user. So you almost look for them:   "What's the typical thing? Yes, okay." In my  original demographics the majority have no college   education, they were school educated only. We said that was your education one,   two thirds of them male – I'd have gone for  somebody else who was male. Go down the list, bang   in the centre. Now it's useful to have that center  one, but if that's the only person you deal with,   you're not thinking about the range. But certainly you want people who in some sense  

cover the range, that give you a sense  of the different kinds of people.   And hopefully also by having several, reminds  you constantly that they are a range and have   a different set of characteristics, that there  are different people, not just a generic user.