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.

Design thinking is a non-linear, iterative process that teams use to understand users, challenge assumptions, redefine problems, and create innovative solutions to prototype and test. It is most useful to tackle problems that are ill defined or unknown. In a rapidly changing world, organizations must be able to adapt and innovate quickly to survive. Design thinking is a powerful tool that can help organizations to do just that. By focusing on the user and their needs, he can help teams to develop creative solutions

that meet the real needs of the people they serve. The end goal of a design thinking process is to create a solution that is desirable, feasible and viable. This means that your product should satisfy the needs of a user, be feasible to implement and have a financial model as well. During the bulk of your design thinking process, you'll focus on desirability as you are concerned with testing your ideas and validating your hypothesis about your users.

Towards the end of your project, however, you should bring the focus to feasibility and viability so that your solution can be sustainable.

What I want to do now is talk about a  few other kinds of divergent techniques. Creativity has two sides to it. There's being *novel* and being *useful*. There's a *divergent* side that's having lots and lots of bright ideas and a *convergent* side that tries to turn those ideas into something that's more useful and buildable.

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.

Let's start with a definition about what ethical AI is. What ethical AI does is it seeks to promote fairness, minimize harm and align AI with human values and well-being. And if I'm a designer and I'm working in ethical AI, one of the questions that I really want to ask is how do I design artificially intelligent systems that follow ethical principles and society. When we think about the practice of building AI systems,

ethical AI is that practice that follows ethical and moral standards in society. But it is dynamic, right? As AI changes, ethical AI must change to keep momentum and to keep pace with the advent of AI technology. So one of the big questions that ethical AI asks as a bird's eye perspective of what AI is is what are the legitimate and illegitimate uses of A.I.?

One of the things that we talk about a lot in ethical AI is transparency which basically sounds is exactly what it sounds like. You're allowing users to understand how decisions are made in the AI systems that they're using. So, this and this really what it does is it builds trust with the user and it builds that relationship where it enables the user to really assess how the system behavior (It has a behavior for bias and fairness).

And it really allows them to see, you know, like what's going on in the background when they're using these AI systems. There’s accountability, which is basically that the designers, the developers, the organizations, basically every stakeholder that has some sort of stake in the matter, whether and even users, they should be held accountable for the impact and consequences of AI systems. So this means things like ease of troubleshooting,

ease of understanding, maybe for errors are there how to address those errors. Like those mechanisms should all be included within the system, within the AI system that they're using. And then there's fairness. So, outcomes should be fair and equitable for users. And by mitigating bias and addressing disparities in AI outcomes, this can be achieved. Definitely, easier said than done, as we'll see in a bit.

But this is the whole concept of just making sure that things are equitable and that outcomes aren't biased or favored towards one demographic or one region or one area or person or industry based off of another. or one region or one area or person or industry based off of another. And privacy. So, individuals have rights on their privacy and data, right? Especially we've been through a lot of like consumer data laws. So, the whole concept is built upon like these systems have to be built

to handle user privacy and data in a secure and ethical manner. And information should definitely be obtained consensually, which not only means that, like me, as a user, I'm giving my data and consenting to my data being given. But I also understand what it means to permission a system to to have my data. Like are they going to sell it? What are they going to do with it? I should, as a user, should have a very thorough understanding of that. And so that understanding should be accessible amongst everyone.

That's basically the idea of privacy and ethical AI.

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.

What is AR? Well, the old definition is that, you know, you see a visualization with an iPad or a phone and it kind of something just pops up, a static visualization. The new definition of AR utilizes technologies that embody spatial mapping that actually map out the room and uses headsets more like this headset where you're looking around and you're have more contact than just through your phone.

So you have holograms and stories or narratives that actually merge with the actual environment, and that's the exciting potential of AR designing for augmented reality. It's about deepening the meaning of real and augmented objects and contexts that is playful and helps guide your discovery that you can visualize and have intuitive discovery and manipulation of objects or content,

and but that it allows you to extend your cognitive abilities to think, to decide, to imagine. It couples with reality to create more meaning. And finally, that is collaborative. And the question is, what's the difference between VR? VR you wear a headset and you're fully underneath that head mounted display, whereas AR your have something that keeps you in contact with the real world.

Well, I'm a fan of both – basically VR and AR are the two major categories, and the rest are specializations. I'm a fan of both. I think living in an artificial world is really engaging. I've been doing it for 20 years. Let me explain that. I have been seeing this in research laboratories for about 20 years and experiencing it in wonderful, wonderful experiences. And it isn't yet up for real time; it's just getting there, just beginning;

it's got a few more years to go, but I believe that's going to be very important. It's already important for *training* people. It's already used in medicine, for example. And it's already used in repair – learning how to repair things. *Augmented* is also very very valuable because with virtual reality, it's your *own new world* with augmented, I'm *the real world* but I have things, so augmented is really great for people trying to repair something

because I go to the thing that is broken and there on top of it I can see instructions or arrows pointing to what I should look at next and so on. But again it's just – at Apple, when I was at Apple 20 years ago, we were doing this; we were already trying to do this, but the technology wasn't good enough. And I think that it's going to be very powerful.

What is creativity? Is it something that you just sort of *wait for* to fall on you from above? Or is it something you *work at*? Do you all have those moments when you  you know you need a spark of creativity? You're in the midst of designing something; you're trying to make a new website; you're trying to make a new application; you're trying to work out how to evaluate something

that's hard to evaluate – perhaps  the way people feel or something like this. And you want that *moment of inspiration*, and does it come when you need it? Of course it doesn't! The model we have of creativity tends to be about these moments of genius. And you already heard about, I think, the 3M story, the Post-it Notes. You know – imagine if you'd had that idea to use this sort of magic glue on the back to create Post-it Notes; how much money there has been on Post-it Notes. Or Philippe Starck and the – well, we all know the lemon juicer is not perhaps all it's cooked up to be,

that it dribbles all over your fingers and stuff, but boy is it iconic! And everybody who's anybody in design would like one of those lemon squeezers sitting on their kitchen worktop! We have this idea of creativity as a genius activity. It might be Steve Jobs in Apple or some of these designers we're looking at here, perhaps Einstein. But is that the full story? Certainly that's the sort of way it seems if you look at sort of

Western traditions of thinking about these things. Going way back to the Greeks, you've got the Muses, the different arts, and the idea that somehow or other this inspiration comes from the Muses up in Olympus and gives you these bright ideas, whether it's poetry or whether it's music ... or web design! So, is that the real story? Let's look a little bit back at these two we've been looking at. First of all, let's look back at the Post-it Notes.

The story is a little bit more complicated; it's not just – you probably know a little bit about this; it wasn't just a moment of inspiration. The guy who was trying to design these things – well, he *wasn't* trying to design these things; the guy was called Spencer Silver; 1968, and he's trying to design a really good glue. And he makes his glue, and he puts it on the back of some paper, and he sticks it to something, and it just... pulls straight off again. Whatever he sticks it to, it's rubbish.

Now, I don't know if you've done  this. You've been scribbling away at something; you've got lots  of ideas, perhaps on your napkin... and you're about to throw it away. When you're about to do that, when you're about to throw it in the bin, pull it out again, have another peek because you never know when you might have a *moment of genius*. Spencer Silver was like this, but he knew  there was something about this.

There was something about this he felt could be useful. He spent five years going around 3M talking to people, giving seminars and talks and  talking about this solution in need of a problem. And then, in 1974, a guy called Arthur Fry was in one of these talks and came back to Spencer and said, 'I have an idea.'

Five years, two people, and an idea that could have been.... And that would throw the whole lot away  in the bin before it ever started. Okay, let's look at the lemon squeezer  now. So, Philippe Starck – I think it was in Italy, but he's in a restaurant somewhere. And the story is he's thinking about lemon squeezers; he has this sort of inspiration of a squid,

and hence we get the iconic lemon squeezer. But of course, first of all that's not built just  on that meal time. He knows about lemon squeezers; he's seen lots of lemon squeezers, lemon squeezers which have some of the suggestions – especially if you look at those kind that you do this to – of the one  on the bottom, or be it the other way around; maybe it would work better if you have the sharp end up. But even that – it's not as simple as that. He wrote down on, perhaps it was a  tablecloth – certainly in some of these Italian restaurants you get paper tablecloths

that get taken away, thrown away at the end. But this tablecloth has been preserved, or this napkin has been preserved. And when you look at that, you see things, images, some of them which look pretty much like standard lemon squeezers, and gradually shifting. The order is not so clear. But it looks pretty much like actually the squid came quite late in the day. So, when he tells the story, of course the squid is hot in his imagination, but when you  actually look at the trace of the design,

there were a lot of stages, goodness knows how many sketches, on this very small piece of paper that eventually came up with this idea. So, even something that took quite a short amount of time, unlike the 3M Post-it Notes, which took five years to gestate, this happened quite quickly. But even, so there was quite an *evolutionary  process* in actually coming up with the idea. So, the question is – can we have *techniques* to help us do this kind of thing?

Not necessarily to turn us into immediate magic geniuses, but to actually get reasonable creative ideas when we need them.

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!

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.

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, 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*.

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.

Ah, well – it's a lovely day here in Tiree. I'm looking out the window again. But how do we know it's a lovely day? Well, I could – I won't turn the camera around to show you, because I'll probably never get it pointing back again. But I can tell you the Sun's shining. It's a blue sky. I could go and measure the temperature. It's probably not that warm, because it's not early in the year. But there's a number of metrics or measures I could use. Or perhaps I should go out and talk to people and see if there's people sitting out and saying how lovely it is

or if they're all huddled inside. Now, for me, this sunny day seems like a good day. But last week, it was the Tiree Wave Classic. And there were people windsurfing. The best day for them was not a sunny day. It was actually quite a dull day, quite a cold day. But it was the day with the best wind. They didn't care about the Sun; they cared about the wind. So, if I'd asked them, I might have gotten a very different answer than if I'd asked a different visitor to the island

or if you'd asked me about it. And it can be almost a conflict between people within HCI. It's between those who are more *quantitative*. So, when I was talking about the sunny day, I could go and measure the temperature. I could measure the wind speed if I was a surfer – a whole lot of *numbers* about it – as opposed to those who want to take a more *qualitative* approach. So, instead of measuring the temperature, those are the people who'd want to talk to people to find out more about what *it means* to be a good day.

And we could do the same for an interface. I can look at a phone and say, "Okay, how long did it take me to make a phone call?" Or I could ask somebody whether they're happy with it: What does the phone make them feel about? – different kinds of questions to ask. Also, you might ask those questions – and you can ask this in both a qualitative and quantitative way – in a sealed setting. You might take somebody into a room, give them perhaps a new interface to play with. You might – so, take the computer, give them a set of tasks to do and see how long they take to do it. Or what you might do is go out and watch

people in their real lives using some piece of – it might be existing software; it might be new software, or just actually observing how they do things. There's a bit of overlap here – I should have mentioned at the beginning – between *evaluation techniques* and *empirical studies*. And you might do empirical studies very, very early on. And they share a lot of features with evaluation. They're much more likely to be wild studies. And there are advantages to each. In a laboratory situation, when you've brought people in,

you can control what they're doing, you can guide them in particular ways. However, that tends to make it both more – shall we say – *robust* that you know what's going on but less about the real situation. In the real world, it's what people often call "ecologically valid" – it's about what they *really* are up to. But it is much less controlled, harder to measure – all sorts of things. Very often – I mean, it's rare or it's rarer to find more quantitative in-the-wild studies, but you can find both.

You can both go out and perhaps do a measure of people outside. You might – you know – well, go out on a sunny day and see how many people are smiling. Count the number of smiling people each day and use that as your measure – a very quantitative measure that's in the wild. More often, you might in the wild just go and ask people. It's a more qualitative thing. Similarly, in the lab, you might do a quantitative thing – some sort of measurement – or you might ask something more qualitative – more open-ended. Particularly quantitative and qualitative methods,

which are often seen as very, very different, and people will tend to focus on one *or* the other. *Personally*, I find that they fit together. *Quantitative* methods tend to tell me whether something happens and how common it is to happen, whether it's something I actually expect to see in practice commonly. *Qualitative* methods – the ones which are more about asking people open-ended questions – either to both tell me *new* things that I didn't think about before,

but also give me the *why* answers if I'm trying to understand *why* it is I'm seeing a phenomenon. So, the quantitative things – the measurements – say, "Yeah, there's something happening. People are finding this feature difficult." The qualitative thing helps me understand what it is about it that's difficult and helps me to solve it. So, I find they give you *complementary things* – they work together. The other thing you have to think about when choosing methods is about *what's appropriate for the particular situation*. And these things don't always work.

Sometimes, you can't do an in-the-wild experiment. If it's about, for instance, systems for people in outer space, you're going to have to do it in a laboratory. You're not going to go up there and experiment while people are flying around the planet. So, sometimes you can't do one thing or the other. It doesn't make sense. Similarly, with users – if you're designing something for chief executives of Fortune 100 companies, you're not going to get 20 of them in a room and do a user study with them.

That's not practical. So, you have to understand what's practical, what's reasonable and choose your methods accordingly.

A/B testing is all about changes in behavior. We present people with alternative designs and we look to see how much that alters their subsequent response. So in the simple A/B case, we show them design A, we show them design B, and we measure typically a completion goal, which a lot of subject areas in user experience we refer to as conversions.

So signing up to a newsletter, adding an item to a shopping basket, making a donation to a charity. These are all things that are important to their respective organizations. And typically for the interactive technology that we're working on. So websites and and apps, for example. So these are the things often that we're measuring, but they're not the only things that we can measure. We can measure really straightforward stuff like time spent on page, time spent in the site and also bounce rates.

For example, we'll be looking at some of those a bit later on. Just a reminder that because A/B testing is done very late in the day with live sites and large numbers of users, you really want to make sure that your solution is sound before you get this far. You're not going to be able to test everything that is possibly worrying you or possibly causing problems to users. It's just too long involved and potentially expensive in terms

of user loyalty and also the amount of effort you'd have to put into it. So we are looking at using A/B testing to basically polish the solution rather than to rework it. Bear that in mind and make sure that you've done adequate testing up to this point. Also, bear in mind that A/B testing tends to be focused on individual pages, so it is possible to have multi-page tests, but

it's a more complex area than we're going to be looking at in this lesson. So experiments have research questions that basically the things that you're trying to answer and because A/B testing focuses on changes in behavior, the research questions are going to be centered on defined goals. And as I've mentioned already, typically conversions. So will as an example, moving the add button above the fold improve sales conversions? I would imagine it would actually do something. I always find people

are making the mistake of getting too talkative on the first screen of the page and the actual “buy this” or “add to basket” button gets pushed further and further down until users actually don't even see it. Will a more clearly worded charitable purpose increase donations? If people have a better understanding of what your charity's about or where this money is going, would that improve conversions for those users? So both of these can be A/B tested by using goals that you almost

certainly have already defined in your analytic solution. So these are very good candidates for A/B and multivariate testing. But I'll give you some examples of bad questions too. So obviously I will repeat the words “don't ask this” when I've mentioned them because they're not meant as examples that you should be taking away. Conversely, research questions that are not directly related to improved goal completions tend not to be suitable for AB testing.

And a kind of vague question like “will better product photos reduce questions to customer service?”, don't ask this, is the sort of thing that you simply cannot effectively test in A/B testing. And the reason is that there are all kinds of channels to customer service and only some of them are through the website and only some of them can be effectively measured as goals. So it's just not a suitable scenario for A/B testing. There is a related question you could ask though,

which might be just as good, although not exactly equivalent, and that would be: “Will better product photos improve sales conversions?” Because if it reduces queries to customer service, it's almost certain that people are going to be much more confident about placing orders, adding those things to their basket. So that is a very easily measured outcome in terms of A/B testing, and that is the kind of question that A/B testing is very good at.

So simply rewording or rethinking the question in terms of defined user and business goals is one way of getting to a satisfactory conclusion, even if you have a slightly squiffy question to start with.

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

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

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

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

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

so it feels good and makes sense to your users.

Looking at when to use surveys relative to  the product or service lifecycle? Well, you might have an existing solution and for that you  may well want to consider a survey after every *major release*; or perhaps on a *calendar basis*, every quarter you might run a customer satisfaction or a user satisfaction survey. And that allows you to keep a pulse on things to know how your offerings are faring

in your users' or customers' eyes. If you have specific ideas for improvements, you can also ask users about that, ask customers to tell you the sorts of things your competitors are doing that they like or perhaps ask them about *sticking points* in your current solutions: what is it that they find problematic, where would they like to see improvements? And, of course, in those kinds of areas, you are talking more about open-ended. But certainly, if you've got a list of things that your  competitors are doing, it's very easy to ask people

whether they would be interested or would find  those particular features useful. For new solutions, you often end up using quantitative research, which is what a survey is, to what we call "triangulate" – get extra data about – back up – qualitative research that you've done. So, you might have gone out and done some contextual inquiry and you might have some really exciting ideas about new product directions, and you want to make sure that that makes sense for the majority of your customer base.

You wouldn't just go out on the strength of a dozen interviews and launch a new product or major revisions to a product  or service. So, the use of a survey is really almost essential in those kinds of cases. *Alternatives* – I mentioned contextual inquiry. The great thing about contextual inquiry is that it's grounded. We go out and speak to real people about real situations in a fairly – what's called – *ethnographic way*.

So, we're trying to do it in their own settings, where they  would be using this product or service. And a contextual inquiry is *extremely exploratory*. So, if you start hearing about certain ideas on a regular basis, you can start asking *more* about that and try to expand the scope of your inquiries to cover these new concepts and find out a lot more about the product or service that you should be providing, as opposed to the one that you perhaps currently are or were planning to.

*Semi-structured interviews* – well, these are a really  important part of most qualitative research and,  in fact, is used in contextual inquiry as well, but  they aren't necessarily as well grounded. We don't necessarily go out into the user's environment  to do those, but one of the attractions there is that we can start off in both of these examples – contextual inquiry and semi-structured interviews – start off with a collection of initial questions and then explore from those.

So, we might have only a short list of topics that we definitely wanted to cover and we'll let the conversation ramble into interesting connected areas – not just ramble in general, by the way; "interesting connected areas" is an important part of that. You want to make sure that you're still within the focus of your inquiry, of your research. *Card sorting* – it's really good for early research for finding the relationships between concepts. We've got concepts on cards, and we ask people to sort those cards

into groups, either of their own creation, so they're allowed to make the groups up themselves – that's called an *open sort* – or a *closed sort*, where we provide the groups and we want to see if people agree with where they're putting things; and in between, of course, those two is something that I call a *hybrid sort*. It has different names. And there are other early-testing tools, which we do talk about elsewhere. Those are, I should say, *tree sorting* or *tree testing* and *first-click testing*, where we're trying out very specific things; we  give users a goal, and we try to see how they

address that goal with the solutions that we're thinking of providing. So, in the case of tree sorting, it's actually *menu testing*. So, the tree is the menu, and we say, "Where would you find this?" / "How would you do this on this site?" and you show them  the menus a step at a time. And there is no site yet. There's just a listing of the menu items  in a step-by-step progression. So, they're shown the top-level menus, they're shown the second-level menus, etc., as they navigate through.

So, it's really easy to do and you get some really good hard data  out of that. And, similarly, with first-click testing, you might have just wireframes or really early prototypes; it can even be sketchings and you ask people to try to achieve a goal with these designs. You record where they click and how they try to achieve that. So, it's actually first-click testing is the most interesting part of that: Where do they focus their attention initially when trying to achieve those goals? So, these are all alternatives to asking people about things.

And, of course, in these latter cases we're talking about seeing people do things  rather than asking them their opinions, which is a much more reliable way of getting data – not that surveys are entirely unreliable; that's not the case – but first-hand information about what people  do rather than what they talk about doing is much safer. And this is a pretty typical field-working experience. The guy on the right has a PDA or phone.

Hopefully, it's a multiple-choice questionnaire  he's asking because it's really very hard to make notes on a device like that, but this is the kind of situation where you can direct the questioning according to how the participant is answering. So, this is an alternative to surveys.

Personas capture what your users are like. They're a way of representing to you and to those you work with, who your users are. Scenarios do the same job but are about *how* people do things. Scenarios are *stories* for design. They're ways you can use your understanding you've gained

from talking or observing users, to others. To capture it for yourself, to retain it yourself, but also to communicate with others. They can also be used to validate other kinds of models. So, if you're doing a detailed task analysis or perhaps doing a walk-through, a cognitive walk-through for evaluation later, they're a way of validating that. You can say "Does this actually agree with  these scenarios, these scenarios that have come from my experience of users? Do the way in which we play these out in more detailed forms actually accord to it?"

They also help you to understand the dynamics of design. So, it's very easy to think about static images or static states of a system. Scenarios are about helping you understand the dynamics, the way something moves from point to point. They have limitations; they are linear. They capture just one view through. But they are very, very rich. So, what will your users want to do? These are questions that scenarios are going to help you do.

How do you do this? You create a step-by-step walk-through. What can I see? If I'm a user using a new piece of technology, what am I seeing? What am I hearing at  this point? What's the immediate perception? What can I do with what I've got with me? So, again, what are the steps? Is somebody going to pick something up? Are they going to press something? Are they going to say something? What's their potential actions? What are they thinking? What's going on in their head?

So, can you capture these, within a story? If you do a sketch on a system, that captures one point of time, but this is about looking... and that perhaps might help you answer the "what can they see?" question, but of course not "what can they do, what are they thinking?". The scenario's about capturing this rich view of what  users are doing or could do or might want to do.

Do you know this feeling? You have a plane to catch. You arrive at the airport. Well in advance. But you still get stressed. Why is that? Designed with empathy. Bad design versus good design. Let's look into an example of bad design. We can learn from one small screen.

Yes, it's easy to get an overview of one screen, but look close. The screen only shows one out of three schools. That means that the passengers have to wait for up to 4 minutes to find out where to check in. The airport has many small screenings, but they all show the same small bits of information. This is all because of a lack of empathy. Now, let's empathize with all users airport passengers,

their overall need to reach their destination. Their goal? Catch their plane in time. Do they have lots of time when they have a plane to catch? Can they get a quick overview of their flights? Do they feel calm and relaxed while waiting for the information which is relevant to them? And by the way, do they all speak Italian? You guessed it, No. Okay. This may sound hilarious to you, but some designers

actually designed it. Galileo Galilei, because it is the main airport in Tuscany, Italy. They designed an airport where it's difficult to achieve the goal to catch your planes. And it's a stressful experience, isn't it? By default. Stressful to board a plane? No. As a designer, you can empathize with your users needs and the context they're in.

Empathize to understand which goals they want to achieve. Help them achieve them in the best way by using the insights you've gained through empathy. That means that you can help your users airport passengers fulfill their need to travel to their desired destination, obtain their goal to catch their plane on time. They have a lot of steps to go through in order to catch that plane. Design the experience so each step is as quick and smooth as possible

so the passengers stay all become calm and relaxed. The well, the designers did their job in Dubai International Airport, despite being the world's busiest airport. The passenger experience here is miles better than in Galileo Galilei. One big screen gives the passengers instant access to the information they need. Passengers can continue to check in right away. This process is fast and creates a calm experience,

well-organized queues help passengers stay calm and once. Let's see how poorly they designed queues. It's. Dubai airport is efficient and stress free. But can you, as a designer, make it fun and relaxing as well? Yes.

In cheerful airport in Amsterdam, the designers turned parts of the airport into a relaxing living room with sofas and big piano chairs. The designers help passengers attain a calm and happy feeling by adding elements from nature. They give kids the opportunity to play. Adults can get some revitalizing massage. You can go outside to enjoy a bit of real nature.

You can help create green energy while you walk out the door. Charge your mobile, buy your own human power while getting some exercise. Use empathy in your design process to see the world through other people's eyes. To see what they see, feel what they feel and experience things as they do. This is not only about airport design. You can use these insights when you design

apps, websites, services, household machines, or whatever you're designing. Interaction Design Foundation.

One of the key ways of designing for  experimentation is to build an MVP, or Minimum Viable Product. This is a concept that was first introduced by Frank Robinson back in 2001 and was popularized by Eric Ries and Steve Blank. It's now heavily associated with The Lean Startup methodology, and it's obviously probably one of the most misunderstood concepts that is also wildly popular, which is impressive because there's actually a lot of competition in that category. People seem to have misunderstood what a minimum  viable product is

in about as many ways as you can do it, but the most common misunderstanding  is that you can just cut as much stuff out of a feature or product and then ship it and then – I don't know – learn something, I guess. But the thing is, you *can't learn something from  a really bad product*. You just learn that nobody likes really bad things, which is something that we already know. Instead, what we should be doing is designing and building something that *we can actually learn something from*. Specifically, what we normally want to learn from  building an MVP is whether the proposed feature or product *solves a real problem* for a specific type of user.

The idea is, if the users we've identified really have a problem that they want solved and they try out our *small* version of the product, that they'll overlook some simple missing features or some small problems because getting that problem solved in this way is so important. The great thing is, if we combine this technique with the one where we share our work with a small group of early users, we can end up getting really good data on the exact things that we're missing. This can sometimes mean that we end up building something far smaller than we thought we'd need in the first place.

Everyone makes mistakes. We are humans, after all. But as a mentor and hiring manager, I see recurring patterns of things people tend to do with their portfolios that are not efficient or sometimes counterproductive. So I made a list here. Not managing time strategically. I know it's very tempting to procrastinate two weeks on designing your perfect personal logo, but logos are not compulsory for portfolios. I'd rather have my students spend time on writing good case

studies, refine them, test them because that's the reason I hire people, not for their logos. So make sure that you invest your time strategically. Going for quantity over quality. I get it, you want to show that you've done a ton, that you spent a lot of time on all these projects, but let me tell you that I don't know anyone, any hiring managers, who read every single case study on people's

portfolios. We simply don't have time for that. So don't let us pick something that you're not proud of. Lacking curation. Curate your work. Don't just list every task that you've done on a project if there's no clear contribution towards the final outcome. Your projects also have to align with what you look for. For example, if you want a job in UX or product design, you may not want to show all the magazine covers that you designed in the last decade.

Lack of care. This one is hard because sometimes we spend so much time on a portfolio that we stop seeing the details: the typos, the grammar errors, the misalignments, etc. Or maybe you don't care at all. But either way, if you can't prove that you can design your portfolio right, why would a hiring manager trust that you can do it for their products? Lack of personalization. It's tempting to reuse a popular template, but if it's popular, that means a lot of other people are using it too. And

trust me, the initial wow effect fades away very quickly when you're the fiftieth person who has an identical portfolio style or uses the same intro. Lack of self-reflection. In the design field, self-reflection is an important part of the process. Writing about it, writing about what you learned, that you have those skills to be able to problem solve a situation,

is very important. By evaluating your own work, you show that you are capable of critical thinking. That is not just about using a tool or methodology. Not following the standards of the tool. Portfolios can be done using many tools, but no matter which one you use, you need to show that you understand the standards of this tool. For example, if you make a web portfolio, then it must be responsive and pass accessibility criteria. If you make a Figma portfolio,

then it must be correctly organized in frames and other layouts. If you make a PDF portfolio, then it must have a standard ratio, a table of contents, and pagination. Try to keep all this in mind, but don't be too harsh on yourself. Making a portfolio requires a lot of work and iteration.