User Centered Design (UCD)

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.

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.

I want to talk about 21st Century Design. So, what do I mean by that? I mean it's a different kind of design. It's not the traditional design where we make beautiful, wonderful objects and wonderful experiences. It's about thinking about design as *a way of thinking*, *a way of addressing the major problems of the world* because designers have a special way of addressing issues. We call it *Design Thinking* – it comes under many other different names.

But it's what designers have been doing for, well, since the beginning of designers. What is design as a way of thinking? Well, here's how I like to talk about it. First of all, well, it's *human-centered*. So, we always *focus upon the people*, and that's very important because it's the *only* discipline where the *major focus is about making things that are appropriate for people*. Second, we *solve the right problem*.

Third, we *recognize that everything is a system*. You can't solve one little piece, because everything is interconnected. So, you have to really look at the nature of the system. And, finally – and this is extremely important – we *don't rush* to a solution. We know that when we're dealing with human beings and societies and different cultures and political forces and economic factors that whatever we do is *probably not* going to be right.

So, what we do is we *try a simple, small intervention*. We see what the results are; then we modify it, and we continually experiment, do an intervention, learn from it, change what we're doing, and slowly we'll get bigger and bigger because each one allows us to do even more the next time, and we'll get better and better. Design is an interesting discipline.

They learn the techniques; they learn the problem-solving and problem-defining methods; they have a whole bunch of powerful tools. And then, because we don't know the  details of healthcare or even housing, we have to bring in the experts; so, we have  to have a multidisciplinary team where we work together with people from all types of skills. And the most important thing – this has to *come from the people*.

We can mentor.  We can facilitate. We can bring in other resources. You have difficulty – individuals have  *difficulty tackling the whole system* or tackling the *political issues*, but  that's where *we* can come in and help. So, we call that *community-driven design*, which is a subset of *human-centered design*, which, as far as I am concerned, is really about *designing for humanity*. So, human-centered design is a subset of *humanity-driven design*, *humanity-centered design*, because we're trying to save

– well – the planet.

Design thinking improves the world around us every day because of its ability to generate groundbreaking solutions. You can contribute  to the future developments in a similar way if you adopt the design thinking mindset into  your own work procedures. But first, you need to know what the five phases of design thinking are. And that's what this video will teach you. Design thinking is a *non-linear, iterative  process* that can have anywhere from three to seven phases, depending on who you talk to.

The model we chose to focus on here at IxDF has five. As we mentioned, the design thinking process  is *non-linear* and *iterative*. This means you don't have to follow the five phases in any particular order. You can carry out the stages in parallel or repeat them and circle back to a previous stage  at any point in the process. Basically, don't ever think these pieces are set in stone. The whole point of design thinking is that it allows you to work in a *dynamic way* to *develop and launch innovative ideas*.

There's no need to use design thinking as a step-by-step process, unless the situation calls for it. Now, you may wonder why we chose to focus on *this* particular variation of the design thinking process. We picked the *5-phase model* because it's the one proposed by the Hasso Plattner Institute of Design at Stanford. Actually, you may have heard it called its more  common name: the d-school. They are world-renowned for the way they teach and apply design thinking. So, who better to take inspiration and learn from? And there's no need to worry; you won't miss out!

Regardless of which design thinking model you personally choose to focus on, all variants embody the same principles which were first described in 1969 by Nobel Prize laureate Herbert Simon  when he wrote *The Sciences of the Artificial*. We hope this short video has given you a good  introduction to the five phases of design thinking. We can't wait for you to learn more  about this revolutionary process!

It's very common for design students to say, "Oh! Let's tackle some of the world's most important problems!" So, off they go to India or  Africa or South America or wherever they think there's some need for clever, sophisticated designers to come in and help the poor people in whatever area of the world they wish to go.

And so, the designers spend a week, two weeks; rarely do they spend even a month. And they go around and they see real issues and they say, "Oh, we know how to work on that!" And they come back and they start to design something for their target country. The problem is that these are very clever people and they did see real problems and they did analyze the problem properly... but they really *do not understand* the people that they're designing for,

because they were there for what – a week? Two weeks? Even, at best, a month? People who live in foreign countries tell me – and I've lived in foreign countries, too, so I agree that, you know, after a year or two years or three years, you're just beginning to understand the country. In fact, in the first year, it's usually wonderful; everybody treats you well and you understand what's going on and you think, "Oh yeah, I understand the country." But, no, people are treating you well and they're being nice to you; they're not telling you the truth;

they're not letting you see what really goes on. And it's only after you've been there awhile, you discover what's really happening in the country. And awhile means *years*. So, you can't just do this, and what happens is the students, they develop these wonderful creative ideas, and quite often they give them to  the design contests in their country and they win prizes: how clever, how innovative, how wonderful. But when they get installed in the country, they *fail*. They fail for several different reasons.

Or sometimes they'll succeed but then they break. Everything breaks – that's not a crime. But when it breaks, the local people can't fix it. When you design, you have to understand what the capabilities are of the people you're designing for. But, more importantly, I believe that it is wrong to have outside experts come in and do something for other people. That's not how we get people to understand, to advance.

You know the old saying "If you're hungry, we could give you fish... but the better way is we'll *teach* you to fish." because if I teach you to fish, then  you can be self-sustaining *by yourself*. So, what I would recommend and what we do recommend here in our group in the University of California, San Diego, is we do community-based design – we go out to the world and we say, "Hey, you know, there are seven billion people in the world.

And a lot of these people are really creative and imaginative, and they understand their own problems. And they understand their capabilities and what they can do. And so, they already are starting to address  their problems, and so if we go in as designers and we learn from them, we watch them, we see what *they* are doing, and then we can help them. We only help when we're *asked* for help, but we can help. We can say, "Oh, yes, let me explain about this."

or "Here's a new technique you could try." or "You know, we discovered this in some other area where they're doing this trick, and maybe this will be useful for you." *or*: "What you're doing is wonderful – can we tell other people about it?" So, if you do a *co-design* where the community drives these things, then you're much more likely to do things that will actually be accepted and be adopted by the local people and will make a difference in the world. But it's a very, very different way of designing than we train in schools.

And so, we have to change the training that we give in schools.

The approach that I apply to design has  evolved over a considerable amount of time. And the name that I use to  describe it has also been evolving. But the reason for that is because I'm also  changing what it is that we approach as designers. So, in the very beginning, when I first started becoming a designer – which is the 1980s – I was concerned about the early adoption of computer systems

which were really almost impossible for anybody to understand; even the experts who designed them were making errors in using them. And there's a famous case where the early Unix  systems had a text editor that was called "Ed" – for "Editor". You could type away and type your  program or your text, whatever you're doing, and spend several hours typing it, and you have this wonderful document. And then you — "Ah, I'm finished!"; then you turn off the machine and go home.

And you come back the next morning to continue and... It wasn't there. Well, why wasn't it there? Because you didn't *save* it. And, well, you mean... The system doesn't bother to tell you  when you try to turn it off that "Hey, do you want to save the information?" It was little things like that that were so frustrating. In the early days, what we did is we tried to study  the people who used these complex systems. And it was not just computer systems. I actually started off studying

nuclear power systems – some of the nuclear power accidents where the control rooms  were so badly designed that if you wanted to cause an error, you could not have done a better job  in designing something to cause errors. And then *aviation safety* where lives were at stake – many lives were at stake. And there were a huge amount of research and work done, and that was a really good  place to work. I worked with the American National Aeronautics and Space Administration – NASA. Most people think of NASA as shooting rockets up into space,

but they forget the first two letters – "NA" – are "aeronautics". And so, NASA is the world's leader often in aviation safety. And that's where I started. So, we were looking, though, at the *users* of these systems, and so we called them "users". And I was at the University of California, San Diego at the time. And my research group, Stephen Draper and I edited a book that we called "User Centered System Design".

And, of course, the initials of "User Centered System Design" is the name of my university: UCSD. But we emphasized, first of all,  focusing on the users – the people –  and, second of all, that it was a system. The system stuff, though, kind of got dropped. And we decided we didn't really like the focus on users. Why are we calling you "a user"? You're a *person*. Why don't we call you "a person"?

And so, we started to call it *human-centered design*. And many people ask me what the difference is between user-centered design and people-centered design. And all I can say is it's the same  thing – it's just a little bit later in time. Well human-centered design – and sometimes I even call it "people-centered design"   – because I don't call you "a human"; I call you "a person" – has evolved to having four major principles – namely, - Focus on the people. - Make sure you solve the right underlying problem.

- Think of everything as a system. And - Do iterative work. Because we're never going to get it right;  people are far more complex, and societies are even more complex than individual people. So, we have to experiment, do a test, modify, and continually improve. So, that's the basis of all of these. Now, I've come to start the term *humanity-centered design*.

And why is that? Well, focusing upon the individuals is often not quite right. You have to focus upon the groups of people, the societal issues. You have to focus upon a larger set of things. When you do a system analysis, that's what happens. And so, that's why I've decided I  will start calling a lot of what I do *humanity-centered design*. But I still consider all of these to be one similar approach.

And, in fact, some people just call it "design thinking". Design thinking has other attributes. For example, when I say we have four major principles, I don't say anything about how we actually get  the clever new idea that's the breakthrough. How do I actually do the thinking and the creative work? And so, a lot of the emphasis in the design thinking world are the techniques and methods that  we use to come up with novel, important

and robust and doable solutions. So, but all of these have to come together. So, in the design world, we must have many, many different methods and many different techniques and many different approaches. But what unites all of us in the field that I am talking about is the focus upon people, society, humanity.

The approach that I apply to design has  evolved over a considerable amount of time. And the name that I use to  describe it has also been evolving. But the reason for that is because I'm also  changing what it is that we approach as designers. So, in the very beginning, when I first started becoming a designer – which is the 1980s – I was concerned about the early adoption of computer systems

which were really almost impossible for anybody to understand; even the experts who designed them were making errors in using them. And there's a famous case where the early Unix  systems had a text editor that was called "Ed" – for "Editor". You could type away and type your  program or your text, whatever you're doing, and spend several hours typing it, and you have this wonderful document. And then you — "Ah, I'm finished!"; then you turn off the machine and go home.

And you come back the next morning to continue and... It wasn't there. Well, why wasn't it there? Because you didn't *save* it. And, well, you mean... The system doesn't bother to tell you  when you try to turn it off that "Hey, do you want to save the information?" It was little things like that that were so frustrating. In the early days, what we did is we tried to study  the people who used these complex systems. And it was not just computer systems. I actually started off studying

nuclear power systems – some of the nuclear power accidents where the control rooms  were so badly designed that if you wanted to cause an error, you could not have done a better job  in designing something to cause errors. And then *aviation safety* where lives were at stake – many lives were at stake. And there were a huge amount of research and work done, and that was a really good  place to work. I worked with the American National Aeronautics and Space Administration – NASA. Most people think of NASA as shooting rockets up into space,

but they forget the first two letters – "NA" – are "aeronautics". And so, NASA is the world's leader often in aviation safety. And that's where I started. So, we were looking, though, at the *users* of these systems, and so we called them "users". And I was at the University of California, San Diego at the time. And my research group, Stephen Draper and I edited a book that we called "User Centered System Design".

And, of course, the initials of "User Centered System Design" is the name of my university: UCSD. But we emphasized, first of all,  focusing on the users – the people –  and, second of all, that it was a system. The system stuff, though, kind of got dropped. And we decided we didn't really like the focus on users. Why are we calling you "a user"? You're a *person*. Why don't we call you "a person"?

And so, we started to call it *human-centered design*. And many people ask me what the difference is between user-centered design and people-centered design. And all I can say is it's the same  thing – it's just a little bit later in time. Well human-centered design – and sometimes I even call it "people-centered design"   – because I don't call you "a human"; I call you "a person" – has evolved to having four major principles – namely, - Focus on the people. - Make sure you solve the right underlying problem.

- Think of everything as a system. And - Do iterative work. Because we're never going to get it right;  people are far more complex, and societies are even more complex than individual people. So, we have to experiment, do a test, modify, and continually improve. So, that's the basis of all of these. Now, I've come to start the term *humanity-centered design*.

And why is that? Well, focusing upon the individuals is often not quite right. You have to focus upon the groups of people, the societal issues. You have to focus upon a larger set of things. When you do a system analysis, that's what happens. And so, that's why I've decided I  will start calling a lot of what I do *humanity-centered design*. But I still consider all of these to be one similar approach.

And, in fact, some people just call it "design thinking". Design thinking has other attributes. For example, when I say we have four major principles, I don't say anything about how we actually get  the clever new idea that's the breakthrough. How do I actually do the thinking and the creative work? And so, a lot of the emphasis in the design thinking world are the techniques and methods that  we use to come up with novel, important

and robust and doable solutions. So, but all of these have to come together. So, in the design world, we must have many, many different methods and many different techniques and many different approaches. But what unites all of us in the field that I am talking about is the focus upon people, society, humanity.