Mind Maps

Brainstorming is a group activity where  people come together to share ideas and   think creatively to solve problems or  generate new concepts. The goal is to encourage free thinking and creativity without judgment or criticism, allowing participants to share any idea that comes to mind no matter how unconventional or seemingly impractical. The aim is to *spark creativity and explore various possibilities* which can later be refined or combined to develop more practical or innovative solutions.

Brainstorming sessions often involve structured or unstructured discussions, note-taking or visual aids to capture and organize the ideas generated by the group. So, how can you structure a brainstorming session? Define the goal. Clearly outline the problem or objective. Create a diverse group. Gather people with varied perspectives. Encourage participation and free thinking. Generate ideas without criticism. Build on ideas. Combine, refine or expand on suggested thoughts. Set a time limit. Keep the session focused and efficient.

And lastly, document and evaluate. Record all ideas and assess their feasibility later. You can spend some time after the session to categorize, reduce and analyze.

Hi. My name is Arielle Eckstut, and I am  the author of What Is Color? 50 Questions and Answers on the Science of Color. Color is an incredibly difficult subject, one that encompasses all kinds of categories of science and history and culture – you name it.

But today in about five minutes I'm going to try to answer this question: What is color? And I'm going to do that by starting with yet another question. In the fall, do the leaves change color if no one is there to see them? Take a moment to think about that: Do the leaves change color if no one is there to see them? Now, the *obvious answer* to this question is "Of course they change color

because the color of the leaves are  inherent to the leaves themselves." But in fact, that is not true at all, and the answer is a resounding *no*. If there is not a living being with a brain  observing those leaves, the leaves do not change color. And the reason for this is that there's no such thing as color without the *eyes* and the *brain*.

So, different brains process visual information differently. And I realized that this idea that color does not exist outside of our perception can be very difficult to swallow. And in fact, our brains go to great lengths to give us all of the colors that we see.

The source of our color vision is in our *retina*, a credit-card-thin sheet of neurons in the back of our eyeballs. And it's actually a part of our brain, our retina. It's the only part of our brain that exists outside of our skulls. And our retina is what we typically associate with sight in general. If I were to ask you, "Why do we have eyes?" most people would say, "So we can see."

But that was actually not the original purpose of  our eyes and our retina. The original purpose was to tell us when to be awake and when to be asleep. So, our eyes sensed when it was light out and when it was dark out, and "when" is the most important word here because our eyes, our retinas have three different systems:

the *when system* being the most primitive and the first use of our eyes. The next system is the *where system*, and that  tells us where we are situated in the world. Are we right at the edge of a cliff? Are we too close to a potential predator? Or are we too far to reach a berry that is  ripe that we would like to eat?

Lastly, we get to our *what system* – the system that designers deal with on a daily basis but the one that is actually *least important* to our visual system. The what system is the system that we use when we are *focusing on something*, whether that be a computer screen or a phone or a face or a road sign. It's also the system that we use to see color.

Color scientist Mark Rea has a great quote that I adore: "Color is a pigment of our imagination." And that really is true. Our imagination plays such a big role when it comes to color. And our brains are constantly taking in information from the outside world to help inform us about what time of day it is, where we are in the world, what we're looking at,

which really gets us to the next question,  which is: Why do we see color to begin with?

So, why do you need prototyping? Well, we never get things right first time. It's about getting things *better* when they're not perfect and also *starting in a good place*. Maybe if I'm going to make a wall for a house, I know exactly how big the wall should be. I can work out how many bricks I need. I can make it exactly the right size.

So, I can get it right first time. It's important to. I don't want to knock the wall down and retry it several times. However, there I have a very clear idea of what I'm actually creating. With people involved, when you're designing something for people, people are not quite as predictable as brick walls. So, we *don't* get things right first time. So, there's a sort of classic cycle – you design something, you prototype it,

and that prototyping might be, you might sort of get a pad of paper out and start to sketch your design of what your interface is going to be like and talk through it with somebody. That might be your prototype. It might be making something out of blue foam or out of cardboard. Or it might be actually creating something on a device that isn't the final system but is a "make-do" version, something that will help people understand.

But, anyway, you make some sort of prototype. You give it to real users. You talk to the real users who are likely to be using that about it. You evaluate that prototype. You find out what's wrong. You redesign it. You fix the bugs. You fix the problems. You mend the prototype, or you make a different prototype. Perhaps you make a better prototype, a higher-fidelity prototype – one that's closer to the real thing. You test it again, evaluate it with people, round and round and round. Eventually, you decide it's good enough. "Good enough" probably doesn't mean "perfect", because we're not going to get things perfect, ever.

But "good enough" – and then you decide you're going to ship it. That's the story. In certain cases in web interfaces, you might actually release what in the past might have been thought of as "a prototype" because you know you can fix it, and there might not be an end point to this. So, you might in delivering something – and this is true of any product, actually – when you've "finished" it, you haven't really finished, because you'll see other problems with it, and you might update it

and create new versions and create updates. So, in some sense, this process never stops. In one way, it's easy to get so caught up with this *iteration* – that is an essential thing – that you can forget about actually designing it well in the first place. Now, that seems like a silly thing to say, but it is easy to do that. You know you're going to iterate anyhow. So, you try something – and there are sometimes good reasons for doing this –

you might have *so little* understanding of a domain that you try something out to start with. However, then what you're doing is creating a *technology probe*. You're doing something in order to find out. Of course, what's easy then to think about is to treat that as if it was your first prototype – to try and make it better and better and better. The trouble is – if it didn't start good, it might not end up very good at the end, despite iteration. And the reason for that is a phenomenon that's called *local maxima*.

So, what I've got here is a picture. You can imagine this is a sort of terrain somewhere. And one way to get to somewhere high if you're dumped in the middle of a mountainous place – if you just keep walking uphill, you'll end up somewhere high. And, actually, you can do the opposite as well. If you're stuck in the mountains and you want to get down, the obvious thing is to walk downhill. And sometimes that works, and sometimes you get stuck in a gully somewhere. So, imagine we're starting at this position over on the left. You start to walk uphill and you walk uphill and you walk uphill.

And, eventually, you get onto the top of that little knoll there. It wasn't very high. Now, of course, if you'd started on the right of this picture, near the *big* mountain, and you go uphill and you go uphill and you go uphill and you get uphill, you eventually end up at the top of the big mountain. Now, that's true of mountains – that's fairly obvious. It's also true of user interfaces. *If you start off* with a really dreadful design and you fix the obvious errors,

*then you end up* with something that's probably still pretty dreadful. If you start off with something that's in the right area to start with, you do better. So, the example I've put on the slide is the Malverns. The Malverns are a set of hills in the middle of the UK – somewhere to the southwest of Birmingham. And the highest point in these hills is about 900 feet. But there's nothing higher than that for miles and miles and miles and miles.

So, it is the highest point, but it's not *the* highest point, certainly in Britain, let alone the world. If you want to go really high, you want to go to Switzerland and climb up the Matterhorn or to Tibet and go up Mount Everest, up in the Himalayas, you'll start somewhere better, right? So, if you start – or on the island I live on, on Tiree, the highest point is 120 meters. So, if you start on Tiree and keep on walking upwards, you don't get very high.

You need to start in the *right* sort of area, and similarly with a user interface, you need to start with the *right* kind of system. So, there are two things you need for an iterative process. You need a *very good starting point*. It doesn't have to be the best interface to start with, but it has to be in the right area. It has to be something that when you improve it, it will get really good. And also – and this is sort of obvious but actually is easy to get wrong – you need to understand *what's wrong*. So, when you evaluate something, you really need to understand the problem.

Otherwise, what you do is you just try something to "fix the obvious problem" and end up maybe not even fixing the problem but certainly potentially breaking other things as well, making it worse. So, just like if you're trying to climb mountains, you need to start off in a good area. Start off in the Himalayas, not on Tiree. You also need to know which direction is up.

If you just walk in random directions, you won't end up in a very high place. If you keep walking uphill, you will. So, you need to *understand where to start* and *understand which way is up*. For prototyping your user interface, you need a *really rich understanding* of *your users*, of the nature of *design*, of the nature of the *technology* you're using, in order to start in a good place. Then, when you evaluate things with people,

you need to try and *really deeply* understand what's going on with them in order to actually *make things better* and possibly even to get to a point where you stand back and think: "Actually, all these little changes I'm making are not making really a sufficient difference at all. I'm going around in circles." Sometimes, you have to stand right back and make a *radical change* to your design. That's a bit like I'm climbing up a mountain

and I've suddenly realized that I've got stuck up a little peak. And I look out over there, and there's a bigger place. And I might have to go downhill and start again somewhere else. So, iteration is absolutely crucial. You won't get things right first time. You *alway*s need to iterate. So, prototyping – all sorts of prototypes, from paper prototypes to really running code – is very, very important. However, *crucial to design is having a deep and thorough understanding of your users*,

*a deep and thorough understanding of your technology and how you put them together*.

Personas are representations of our *users*. They promote empathy by allowing us to focus on individuals rather than groups. It's this whole issue of empathy. We keep talking about "users". And even just talking about the *roles* like "customers" or "clerk" or "salesperson" doesn't make these roles seem real. It doesn't. We're not talking about real people. Real people have limited abilities.

Real people don't necessarily get computers in the same way that the development team does. Real people have needs that have been brought up by their circumstances or by their own personal beliefs. So, we need to know a bit *about* them. And personas are a great way of representing those understandings in the design of a real system. So, there is strong psychological evidence for *personal bias*. Our brains are wired to *empathize with individuals rather than groups*. The general feeling is that when we dehumanize people by referring to them

with these abstract collective nouns – because collective nouns *are* abstract by definition, so we're talking about "users" or we're talking about "customers" – we're taking the "people" away. We need to put the "people" back. Back in 1983, David Sears ran a study with two sets of participants. He gave the participants the same characteristics. And in one set of participants he said that these characteristics were of

*an individual*. And I believe he described the individual. And in the other set participants he said that these characteristics were of *a group of people*. And the participants who were told that they were seeing the characteristics of an individual *always rated the individual more highly* than the participants who rated the characteristics in connection with a group. So, that he called the *person-positivity bias*. And it basically is confirmation that our brains

– us as individuals – *prefer thinking about other individuals*. We're certainly more inclined to think more positively about other individuals than we are about collective nouns like "tourists" or "customers" or "users". The *scope-severity paradox* is a much more recent piece of work – 2010 – and is quite surprising. Two researchers, Nordgren and McDonnell, established that reactions to a fraud were more severe when it was presented with three victims rather than 30. So, it's the same kind of deal: two sets of participants,

both given exactly the same details of a crime, except that in one group they were told it affected three people and the other group were told it affected 30 people. And it was the people who were told that there were only three victims that thought that the crime was more severe. And they, on average, added a year on the prison sentence that the perpetrators of this crime should receive. So, again, that is just confirming this tendency for us to feel more strongly about individuals than we do about groups.

Personas are fabrications *based on research*. We mustn't let go or lose sight of that little parenthetical expression there, because we go out and we find out who these people are – the ones that we're interested in – find out what behaviors they have which drive them to need our solution, what motivations, what their circumstances are, what their contexts of use are,

just so we understand who we're building the solution for and other aspects that we describe in the context of use. These personas are representations of our users, who represent the goals, behaviors and motivations of those real users. They *promote empathy* by allowing us to *focus on individuals rather than groups*. So, instead of talking about "User Community One" or whatever catchy name we'd like to come up with for our user communities, we start talking about "Bob"

or "Jane" or "Elizabeth" – whoever – whatever everybody in the team is happy with. And there have been all kinds of documents and papers and studies written about personas. And you'll find that personas range from quite a limited description of a person. And, in fact, it can be just as little as changing the name "users" to a person's name. So, if you always refer to your customers as "Andrew", then you would actually

be doing yourselves a favor in terms of making that customer seem much more real. But at the other extreme it's not uncommon to hear about user research and persona development taking *weeks* – possibly even months: 2–3 months, which is, in my view and and quite a few others', certainly for an Agile environment well beyond the realms of possibility. So, we're going to be talking about something called a *minimal persona*. So, minimal persona – a name, age and other specific demographic details that a real person

would have. A photo – ideally realistic – showing the person in that setting or doing that thing. And then, basic information about why you're interested in them or why they're interested in us – our solution or product. So, their *primary goals*: *why* those are their primary goals and *what* they're hoping to achieve through our solution or product. And their *behaviors* – what are they doing before and after interaction with our solutions

fit with their daily routine, for example. And some of this comes from the fact that I have for years been astounded by how little the people developing software solutions know about their users. I've been involved in a couple of projects where there was no contact whatever. The development team had never met or seen a user, didn't know what the user was doing immediately prior to entering or receiving data from their system, didn't know what happened to the output data, knew almost nothing.

So, it wasn't surprising that the system when it was first launched was almost impossible to use, because it didn't actually fit. It was like having a random piece of a jigsaw puzzle and a very well-defined hole that it just did not slip into. So, these are the reasons we're trying to actually make sure that we understand at least something about our user communities. And that's what personas are trying to help us with. *Extended personas* – you might add lifestyle interests,

hobbies, as they apply to their motivations. I wouldn't add them just to make the person seem more complete. That isn't absolutely essential. But if some of those issues – lifestyles, interests or hobbies have an impact on your solution, then you should know about them. So, *keep to the details that are relevant* to the problem. Remember that we want to *motivate our team to help* our personas, *not* to drive them crazy with distracting detail, which is one of the complaints you will hear about personas.

Certainly when I've attended conference research papers on the use of personas in teams, often they were not well-received, because there just seemed to be so much of it – the persona specification. *Credibility*: ensure that the personas are *believable* and liked *as much as possible*. Certainly do *not* give personas unpleasant or dubious habits like being a heavy drinker or a heavy smoker or likes to bet on the horses – unless, of course, you're building a gambling app or something! *Change the name, photo and other details* until the whole team is comfortable with them.

It needs to be a collaborative effort between the user experience people and the people who are going to be using them. That would be the development team. So, the names and the photos are almost entirely arbitrary. If you've done research with a handful of participants, then you'd have a handful of photos. If not, then try to find photos from a stock photo site. But try to avoid overtly attractive people because it can be distracting. In user experience, we create often what are referred to as "design research personas",

or "design personas" for short. So, that's what these things are technically called. We go out and we research these user communities. We decide what behaviors and needs are relevant to us: Who are we building the solution for? And those personas are based on this design research. So, that's why we want to call them "design research personas" or "design personas". But there are lots of other things that also get tagged with personas.

And the most common of those I've come across, particularly in large companies, are *market research personas*. And they're not the same thing is the main problem that we have. So, beware that *other kinds of personas exist*, often based on demographics or market segmentation. These can be used for *validating design personas, but should never replace them*. There is little point in trying to reuse personas for different projects, as well, unless the same goals, motivations and behaviors are relevant.

And I've come across this whole approach in one particular vertical market in the U.K. And that is mobile phone service providers – that they have all got marketing personas based on age ranges. And they then attach labels to these age ranges to suggest how these people behave and what they need from our services, which, just to be honest, cannot really be true! You need to actually *forget about the demographics*. There will be some age-related behaviors, no doubt. But they shouldn't be

the motivating factors in the design of an interactive system, which is, after all, what we're trying to achieve. The main thing is that predominantly you have *one* or *two* primary personas. If you've got a project – and I've had people kind of come up to me almost in a boasting tone, saying: "Our project has got 20–30 personas!" And I'd say, "Oh, really? How is that?" They'd say, "Well, it's a hospital system." And the thing is, it's a *very* big system. And what you need to make it agile and to make these things work effectively

is to split the system into parts. So, you may well have some small number of primary personas that apply throughout. But in many cases you're going to have primary personas that are specific to that kind of system or that part of a system. So, let me give you some very simple examples. The one that I like to use is a hotel self-check-in. When I started writing about hotel self-check-ins, there were none in existence. And now I do come across them, funnily enough, in hotels that have got receptionists but all they do then is to

refer you to the self-check-in in front of the reception! I was motivated for this example by checking in at a conference hotel on one occasion. I actually got in pretty easily. I think it was a 20- or 30-minute process. But the next day I was walking through the reception and the queue – the line – of people waiting to check into this hotel went around the block. It was just utterly amazing. There must have been 200 or 300 people waiting to get in.

So, it occurred to me: "Well, why don't we just have some self-check-ins like we do at airports?" And, of course, self-check-in at airports is entirely bog-standard these days – it's what everyone does. So, for example, the primary persona of a hotel self-check-in service must be the customer checking in. It makes no sense for it to be otherwise. A *secondary persona* would be someone who is acting in a *supporting role* inside that system. So, a secondary persona might be a hotel manager or a receptionist or somebody who's

responsible for the upkeep of the hotel, for example. So, these are all *secondary roles*. They're not the people for whom we are building the system. They are people who are *involved in* the system and often in a backroom kind of interaction. These are people that primary personas rarely see or even know about. So, it's a difference between the primary roles in a stage production and just extras or people with non-speaking parts. That is kind of the difference between primary and secondary personas.

A lot of systems may have *only one* persona. This is the person that we're building this particular product for. And you can have all kinds of philosophical arguments about whether you're building a Swiss Army knife solution or whether you're building a carving knife solution. One is very good at one thing. Carving knives are very good at carving. Swiss Army knives are very good, but in a fairly different kind of way, at *all kinds* of things.

But they're not all that easy to use. So, it's up to you. The whole point of personas is to try to *give focus*. So, these are our customers. Other people, who do not fall into the definition or the descriptions of our personas, it's fine if they find our system easy to use. But unless we can actually identify some clear purpose in adapting the system to be more inclusive, then we would deliberately not pay much attention to their particular requirements. Now, things like *accessibility* and the *age ranges* of users – they fall outside the whole persona mechanism.

You must *always make sure that your systems are usable by those with disabilities* whether that's acknowledged specifically in your persona or not. I do have at least one colleague who, if they're dealing with a team who has little experience of accessibility – that is, systems that will be used by disabled people – he deliberately includes a disabled persona. But that really ought not to be necessary. But if that works for you, then that's absolutely fine, too.

Certainly I can see it being important when working with teams that don't have much experience. So, you must make sure that your solutions work for a *broad range of people* in terms of *accessibility* and *age issues*. But otherwise, we want to be very focused on the *specific behaviors* and *needs* of our primary personas. So, we stick to small numbers to maximize empathy. And we consider splitting larger projects, as I was discussing for the hospital example. For example, a hotel check-in system could be split into front desk and housekeeping projects

with separate personas. So, those could be two smaller Agile projects. And there is no magic number. But, like I have been saying, 1 or 2 primary personas is perhaps the most common, with maybe a few secondary personas thrown in, as well. Personas get used in all sorts of places. Obviously, their main focus is in *design*. So, "Who are we building this product for? How should the interactions take place? How much experience can we rely on them having of this kind of solution?" and so forth.

We will have to *recruit* these people. We want to do *research* with them, perhaps continuing research over several life cycles of the system. We want to recruit people for usability testing and user evaluation / usability evaluation in general, not just running them through early beta releases of the software. We might want to be testing with paper prototypes. We might be wanting to show them just wireframes and talking to them about the layout

and their understanding of the different components of the page and those sorts of issues. Sales and marketing will want to know *who* they should be targeting in terms of what the system does and for whom. And remember that you will need to describe the *demographics* and the *filtering questions* for your personas to a recruiter. So, when you're recruiting "Arthurs", what is it about Arthur that makes him your persona? It needs to be something that he wants or needs or you're *hoping* that he wants or needs. He needs a solution to a problem. So, what is that problem?

So, you need to actually talk to your recruiters about filtering questions. You know, what are you going to ask *potential Arthurs* that's going to help you to decide whether this person is really an Arthur? Now, this is quite an interesting area. And it may depend a lot on how enthusiastic your team is about personas. If you've done your job right, if you've *sold* personas, or if your team is already quite familiar and quite enthusiastic about personas,

then you might do some really fun things like getting mugs and coasters printed with maybe the face of the persona on one side and some of their relevant details with respect to your system on the other side. Ditto with mugs, maybe even T-shirts. And one thing that I was quite amused by – and I could actually see this working for some teams – is life-size cardboard cutouts. That's another possibility. So, you could actually have a room with your personas kind of standing around in unused corners.

I do know of organizations – I have heard of organizations – that would actually give the persona a desk, particularly if they were building a system for somebody in-house. And they might actually put all the stuff to do with that persona on the desk, just to make that person seem more real – you know. "Arthur would always be on holiday, but there's his desk" kind of thing. And I should mention – I'll just point out this very last thing – because it's quite important: at the very least, personas should appear in *easy-to-read* form on the project workspace

– whatever – sometimes, you'll hear this phrase – I used to hear it; I don't know that I've heard it very often – called "information radiators". Well, they're what you and I might refer to as "walls" or "partitions". They're the vertical spaces in your workspace. And you would pin important things to that, like all of the backlog for the next cycle and the design maps. So, these are things which everybody who's working on the project would actually be able to refer to quite readily. You might even hand these out in laminated plastic form,

just so everybody has easy access to them, for example.

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.

If you just focus on the evaluation activity typically with usability testing, you're actually doing *nothing* to improve the usability of your process. You are still creating bad designs. And just filtering them out is going to be fantastically wasteful in terms of the amount of effort. So, you know, if you think about it as a production line, we have that manufacturing analogy and talk about screws. If you decide that your products aren't really good enough

for whatever reason – they're not consistent or they break easily or any number of potential problems – and all you do to *improve* the quality of your product is to up the quality checking at the end of the assembly line, then guess what? You just end up with a lot of waste because you're still producing a large number of faulty screws. And if you do nothing to improve the actual process in the manufacturing of the screws, then just tightening the evaluation process

– raising the hurdle, effectively – is really not the way to go. Usability evaluations are a *very* important tool. Usability testing, in particular, is a very important tool in our toolbox. But really it cannot be the only one.