Ideation

So, what I'm going to do is talk about deconstruction and reconstruction and the variation of this that was designed by Clare Hooper. Clare Hooper was working with design software engineers at IBM. Teasing Apart Piecing Together, or TAPT, is a series of worksheets and more detailed instructions.

I'm only going to give an overview of it here and show you some of the main worksheets. But in the notes for this course, we'll give some links to the TAPT detailed instructions so that you can use those perhaps as an exercise yourself. So, you might prefer to just use a plainer thing to say, "How do we deconstruct this?" but this gives you a way of just being a bit more systematic. The *teasing apart stage*, which is that deconstruction.

There's a process of trying to then just use that to give an understanding of the experience. And then *piecing it together* probably for some sort of new medium, new situation, some sort of re-envisionment of it. And the whole point is to *move from the original context*, and that might be a physical context into a digital version; it might be from one digital version to another, or maybe from a digital version into a more physical version. And the crucial bit is to *maintain again those key experiential elements*.

Not – so, it doesn't matter; you might change things at the edge; you're bound to as you move between contexts, but to try and say, "What's the *core experience*?" and try and retain that. So, what I'm going to do is talk too about these two main phases, or we're going to use the *worksheet* as the core element to talk about them. But I said there'll be links in the notes to the sort of detailed instructions to go through. So, the first bit is the teasing apart – the deconstruction.

Here, you've got the worksheet and you can use these to step through this. So, first of all, *what is the experience?* There's a little box at the top for listing that. And then a *short description of the experience* on the left-hand side – number 2 here. Then, *what are the surface elements?* And this is, again, we've already seen surface elements. In fact, 'surface' here means very much 'what are the things?'. Then *experienced elements* – and these have been split into two parts:

the *external* ones are the ones that somebody looking at you from the outside would see. But others might be inside, more sort of a sense of excitement or suspense would be internal ones. Crucially, one of the things TAPT methods ask you to do is, having listed all of the external effects, the internal effects, say which of those experiential effects are the most crucial ones? So, underline the key ones; some of them are there, but perhaps not so important;

some of them really are essential to this experience, and those are the ones you're going to try to maintain, try to re-envisage in a new context. And then, finally, a *short, succinct statement of what's a distilled crucial experience*. So, as an example of that, again, these all come from Clare's descriptions of the TAPT method; so, this is about Facebook and how you share photos on Facebook. So, there's a little statement at the top that says about *Experience*: "Facebook allows users

to upload and caption photos, which can be commented upon by the photo's owner or other users. Viewers can 'tag' friends in photos, adding metadata which links images with people's profiles." So, you've got a short description of it, then a number of surface elements; there's the photo, the upload process, the annotation of images. *External experienced effects* – *broadcasting of visual information*; This is for software engineers; it's (inaud.) slightly techy way of putting it,

but their *sharing of past experiences*. And then *internal ones* – the idea of presence in the community, and that's been underlined as a core one, as was the broadcasting of visual information in the external ones. The *openness about past experiences* – core. They've got *anticipation*; *reminiscence* has again been underlined as core. Now, there's some photo sharing that perhaps doesn't fall into this category. So, I was realizing there's stuff like all those cats that you see everywhere,

unless it's your cat, (inaud.) it's not about reminiscing. But it is perhaps more about the photo that you share about something you've done together, perhaps a holiday or something like that. And then, you see that some are underlined. And there's *distillation* – "A way to share and annotate reminiscent imagery from the user's past, within an online community. The audience can view and annotate the imagery." Now, you notice there's a difference between the first statement, which is what says Facebook does this, and the last one, which is trying to talk about the essence of the experience and trying to separate itself a little from the actual way that's instantiated in Facebook.

And the idea of that is to allow you to then re-imagine the experience in a different setting. Having done that and got this sort of idea of what the core experience is, you then go and try and piece it together in a new context. Now, it's interesting here that this form is a simpler one. It's saying, "What is the experience of?" That's really what you've just written down. It's the *distilled experience*, which is copying it forward.

The *new context* – that's what you're given and what you're going to try and change to; *some sketches* and *a description*. So, this is really a *what you've thought of*. However, there's a series of process steps that goes towards this... which includes potentially brainstorming, creating scenarios and then saying, "Okay, I've got this idea for this scenario; does it actually match the experience?" You might have thought of a way of doing it, gone through it and then said, "Step by step, does this actually match the core experience?"

So, here on the Facebook one, you've got the distilled experience, which was copied from the previous form, a way to share and annotate imagery; the new context is in *the home*; so, rather than it being something that's virtual and sent, it's still going to be a digital experience but in the home. So, the potential way to do this has been a novel tabletop that displays sequences of photographs uploaded by the owner, and then there's a touchscreen interface, ways to annotate, and that somebody coming

into the house can annotate as well as the person who's in the house. Now, again, you can imagine this reinvented in different ways. But what this is doing is giving just a way of structuring that process of looking at something and looking at experience, trying to get to the *heart* of experience, and then opening it out. Now, you notice this was effectively a *digital-to-digital transformation*. Here's another example from the TAPT tutorial. I'm going to give you links to the TAPT tutorials if you want to read through this in a bit more detail.

And it's about a picnic – in particular, crucially, think of a picnic with a tartan rug because they often are... those blankets, those open blankets. So, again, I won't go through these in detail. This is all in the TAPT tutorial. But the *experience* – "A group of friends go outside with a basket full of cold finger-food, to a park or a woodland. They share a meal and chat while outdoors." *Surface elements* like the rug, the picnic basket, the food – we mustn't forget the food!

*External experienced effects* – that somebody could notice, like the conversation, perhaps the wasps buzzing around, the weather, the fact that it's outdoors – a number of things. And team games – I think it varies on people whether they do games or not, but anyway, for the example here team games have been underlined as being a core experience. *Internal sense* – sense of the *sharing and enjoying the food* has been underlined. *Co-experience* – this has been underlined as a key element for the picnic.

And so, the *distilled experience* – "A shared social and food-based experience set in a restful, natural environment. People talk and play games as they enjoy a meal together." So, this is the thing we're going to try and preserve. The key effects have been underlined. The second form, the piecing together form, copying over the distilled experience. But the new context is going to be the *web* – from a physical experience to a web experience.

And again, not going through the steps it's gone through, but the TAPT method offers us a series of suggestions for ways to do this piecing together. So, you can imagine trying out various scenarios, finding that some fit better and worse and tweaking them. But this is more this final solution here. (It) was the 'picnic' now happens in your own home, or you could go out actually but probably in your home because you're going to need the web for this. Friends choose an order item from a website – a good commercial opportunity here –

have the picnic website; the food gets delivered. You get not just the items you chose but the items everybody chose delivered to your home. And they do as well, but in quantities that are suitable for one or for however many people are in your home. And then you log on to the site; there's a simple web page, a picture of a tartan rug, and gives you webcams and things so that you can talk to each other whilst enjoying your finger food together and maybe do

sort of games and stuff, like you might – you know – throwing a frisbee and use web versions of frisbee and things. So, you can see how this works together. And again, as you described, the whole idea is can you *take that experience*, *tease it apart into its individual elements*, *find out what's the core, the heart of the experience* and then *re-express it in a new way*?

We'd like to make tacit things, things  we know, *explicit*. One of the ways to do that is through making comparisons, to look at the distinctions between things. So, let's look at simple comparisons. The simplest one is just to look at two things. It might be two documents; it might be two systems; it might be two solutions to the same problem – perhaps two different kinds of menu in the system we're looking at.

So, you look at them and then you just ask simple questions: What's the same? What's different between them? And it's the difference which is often the interesting things. It's easy to – when you say they're the same – you know – these are both fruit; that doesn't tell you that much. But what's so different between an apple and an orange? What's so different between the kind of menu you get on a phone as opposed to the kind of menu you get on a web page? And by talking about those distinctions and those differences, you start to *make sense and understand things  about them*. So, sometimes that can happen on simple two-way comparisons.

Sometimes, a *three-way comparison* can be a bit more helpful. So, when you have two things to compare, sometimes it's easy to fall back into standard differences. So, again, with my apple and orange, I might just say, 'Well, this is a citrus fruit and this isn't.' or something like that. So, I have a set of standard categories. This is sort of top-down reasoning, going from book knowledge, rather than from sort of bottom-up reasoning. Three-way comparisons can help here sometimes to actually say, 'In what way is this like this but different from something else?'

And sometimes you can deliberately play with  this, try different orders so the obvious answer is taken away from you. The origins of this are in repertory grid techniques which are used for personality tests. And they're used to ask  people three-way comparisons as a way of sort of finding out about the way their personality is. However, you can use it for all sorts of kinds of technique. You can use it yourself to look  at techniques and ask yourself this question,

or you can use it with your users. So, here's an example we'll go back to the apples and orange. So, I've brought my fruit bowl, if it can't  fall out. And in my fruit bowl I've got some grapes, I've got an orange, I've got  an apple. What you might do is say, 'Okay, I've got an apple and orange. How are an  apple and orange similar to one another but different from grapes?' And you could probably already start to think of answers yourselves. We have different answers because this is about  exposing our tacit distinctions.

So, you might apply this – if you're working with fruit manufacturers, you might ask this question, but obviously for user experience, this might be two different, three different menu systems. And so, for these apples and oranges  I might think about something like *size*. So, these are bigger than – well, certainly than an individual grape, not necessarily than the whole bunch, but an apple and orange are bigger than single grapes. You might use size as a distinction. But you notice it's interesting even  there, I've started to have to talk about some

subtlety in here, which is often the case. Do you eat one or many? So, typically when you have an apple or orange, you just have one apple or one orange, but when you have grapes, you usually don't have just one grape – you usually have several, partly because they're smaller. But actually, because they're smaller, we're already seeing interesting relationships. Obviously, if you have something small, you eat more of them. I've said they're not in wine – okay, you know, you make wine out of grapes. That's an odd one because I could say that – you know – apples you can make cider with, all sorts of things.

But obviously, I think grapes are so closely associated with wine in my head, that seems sensible for me given my  distinction. So, this is obviously exposing not just what these differences are, but actually about the *way that I see the world* – the categories I impose on the world. So, we expose the categories that we  have there by making these distinctions. And so, one of the interesting things is when you have – if you just do it one way round, obviously you can again sometimes drop into standard links,

and perhaps in my head I put apples and oranges closer to themselves than I do to grapes. But I can break that by deliberately mixing things up. So, now I can say, 'Okay, given an orange and a grape or oranges and grapes, how are they more similar to one another than they are to apples? How is an apple different from them?' So, now I can't use the set of distinctions I had before, so I'm forced to think of new ways. So, again, if I was doing my menus and buttons and web links,

I'm going to start thinking, 'How is' – I can't remember, I have to put labels on these, but – you know – 'How is my web link different from my buttons and menus?' But then having done that, I shuffle them around and I can't use the same distinctions. I've got to think of new differences. Being in Britain, I think about things that I associate more with being things that are grown in Britain. I still think of apples as a typical British fruit. Now, it's interesting – so, before I was thinking about the eating qualities of these,

when I was doing another comparison. Now, I've been forced to think about where they're grown, and also that this was not a hard distinction; notice – you know – this was more easily grown. And probably it's more like I've created a dimension where apples are at one end and oranges another and grapes sitting in the middle. I've sort of – so, having said that I eat one of  the other fruits, I've sort of put these into another similar category, saying, 'Well, actually, when I open the orange, there's multiple

segments, just like there's multiple fruits here; whereas the apple is an apple.' – you know. If you cut it up, the core inside is segmented but the actual flesh is continuous. So, that's another distinction. And then, of course, you force yourself again. You say, 'Okay. Okay, I've done the other comparisons. What about putting apples with grapes and oranges on their own?' And, again, I found a different set  of distinctions there. For some reason, when you go to visit somebody in hospital, you tend to think of bringing apples or grapes, but not so much oranges – even though an orange has got lots of vitamin C in it.

I think part of the reason is about *messiness*. You know – these are good lunchbox foods. You know – you can eat your apple; you can pull off your peel. It's harder, unless you get those easy-peel oranges, to have an orange in your lunchbox because when you cut it, it spurts everywhere. And – oh yeah – that was another thought, what I thought was these two I eat the skin of. You can eat the skin of an orange, but most people don't. So, you notice what we've done here is we've *pulled out a whole different set of distinctions*.

We've got things about the nature of the flesh in  the fruits; we've got the nature of the skins; we've got the size of them; we've got where  they're grown. It's a whole lot of different things we're understanding about fruit by doing these sets of comparisons with these three fruit. Typically, the closer the things are you're  trying to do these comparisons – that's whether you're doing a two-way comparison or a three-way comparison like this –

the *closer* things are to one another, the *more interesting you get the results* because you're forced to make finer and finer distinctions and that exposes more interesting things about the domain. So, comparing buttons and menus, if you're  not careful, you'll fall again into standard categories. Comparing two relatively similar  menu systems with each other, you probably start to get some more interesting distinctions  out that help you learn about your domain. So, yes, I was giving an example here – oranges and apples;

maybe you learn more about fruit than if you compare an orange with a car, because an orange is a fruit, a car isn't. So, the closer they are, the harder it is to  fall into standard distinctions. Having said that, maybe you'll find some interesting things if you look at an apple and say, 'Is an apple more like a tractor or a train?' And this is, I guess, close to sort of bad ideas thinking. Or – you know – sometimes you're asked perhaps, 'What fruit are you like?' 

You know – if you go around the people you know in the office, if you were going to give each person a fruit that represented them, which would it be? And then ask yourself *why*. So, if I'm going to say an apple is more like a tractor, is that because tractors are more agricultural? Or maybe I think it's more like a train because perhaps as a child if I went on train trips, I always had an apple to eat while we were on the train. So, by making these, again, closer is often better, but sometimes you make those wild comparisons – you also end up with some interesting things.

I'd like to tell you now about a technique that  I use often – a very simple technique to enhance structures. I've already got some sort of dimensional, categorical way of describing a problem and to make it richer or to explore whether you can make it richer. We often have things which *appear* to be opposites.

So, in political life you might have left wing versus right wing. In personalities, you might have an introvert versus extrovert. And whenever I'm faced with a dichotomy that says 'this or this', I ask myself, 'Can it be both?' So, we might have – in a classic user interface kit, we've been using menus as examples – you might have menus versus radio  buttons.

And they're completely different things – something is either a menu or it's a radio button. Neither both. But what about, could you have something that's *both* a menu and a radio button? So, could you have something that looks like a menu, perhaps pulls down but has radio buttons inside it? Would that work? Or neither, of course, but neither is (inaud.) – you can think of things like text. But can it be both? So, rather than saying A or B – one or the other – can you actually have something that has elements of both going on?

And sometimes the answer is no and your categories are disjoint. But often if you ask about something being both, you learn something or at the very least you learn that these really are distinct. You can do the same for  things that are – so that's true of things which are like menu versus radio button, which are categories, but also things like the left (inaudible) right button ring, which is more of a dimension. Sometimes you (inaud.) to ask if a thing is a bit of each. Can you have something that's *almost*

menu-like but also has a little bit of radio button? I'm not quite sure what that would be, but that  might be true of, say, the fiction versus versus non-fiction. So, you might say, 'These are my fiction books. These are my non-fiction books.' You know – what would it mean for something to be mostly fiction with a little bit of non-fiction? So, again, a historical novel  might fit into that category. And what you're doing then, actually,  is you're taking what appears to be  

*categorical distinction* – it's either this or this –  and actually turning it into a *dimension*. It could be totally the one thing; it could be totally  other – totally fiction, totally non-fiction, but possibly somewhere in between. So, you can both look at more rich categories, things that are both, but also *turn* what appears to be a categorical distinction into a dimensional one. And dimensions tend to be richer, partial things. They can be more problematic, but they're often richer. However, if you've got dimensions, you can do similar tricks to dimensions.

So, let's think of the classic personality trait – introvert, extrovert. And whenever I see a scale that's got something on one end, something on the other, I always want to twist it and say, 'Well, what about if it was bent in half? Can we imagine somebody who is both very introvert *and* very extrovert? Or can we imagine somebody who's very non-extrovert *and* very non-introvert? Do we have to see these as opposites? Can we actually think about combinations?

Maybe it's at different times; maybe it's at the same time. What would that mean? And we start to learn about the nature of  personality, perhaps a richer way than if you see things always in terms of polarities. So, again, it's a powerful way. Again, sometimes the answer is you do something like this and you think, 'Actually, this is meaningless. There really, really is a distinction.' But so many times, I've found that what appears to be

the sort of middle neutral point in fact can consist of both – shall we say – a more neutral something that has neither characteristics, but also something that embodies both characteristics can be placed in that middle, and they're actually more that they sit out at the top right-hand corner. In one way, so what these opposites  do is they again help you, as with many of the other techniques we've looked at, to feed your gut feelings.

So, some of the things we start off – when we start off with concrete examples, we've been taking something that's very solid. You know – I know this is a mug; I know this is a remote control, and dealing with those concrete things, and then using that to abstract, to start to have a vocabulary to talk about our problem domain. What we're doing here is taking that  vocabulary and creating more of these gut feelings that enable us to actually look at it  and think, 'Yes, I can imagine something there.'

What we're going to do now is talk about the  advantage of having multiple classifications. That is, being able to *describe something  by multiple attributes*. You might talk about how the speed of something, whether it's fast or  slow, versus perhaps the size of it, whether it's large or small but being able to talk about multiple kinds of things that are true of the same objects. I'll explain first of all why that's important.

First of all, think about a non-multiple  classification, a single classification but a complex one. Now, taxonomies are usually the most  complex type of classification we find day to day. They're the sort of things you find in the library for  the Dewey Decimal System; museums will use it to organize all the animals, and biologists obviously to do that before, and that's then being used by the museums. So, these are really powerful things to help us to categorize things, to help us to put things onto shelves,

put them into rooms, put them into filing cabinets – incredibly powerful. However, they force you to put things usually into one place. And that can be useful because you want to know exactly where that book belongs on the shelves, but also it can be problematic from an intellectual point of view. So, let's look at this sort of simple taxonomy here. What I've got is a set of all things and I've classed them into circles and shapes – there are no triangles or oblongs in my world; it's just circles

and shapes. And the circles – there are red circles and yellow circles; and for squares there are some red squares and some yellow squares. Maybe there's other kinds of circles as well and other kinds of  squares. Now, a taxonomy like that can be helpful. So, I don't know if you've ever done this – gone to a library, looked on the shelves and you're looking for a particular book and then you spot something  nearby and you think, 'Oh, that looks interesting!' One of the powers of taxonomy is it helps  you to find those things that are close, but it only emphasizes certain sorts of  relationships. So, if we look at these shapes,

it's very clear that the red and yellow circles  are similar to one another. If you go onto your library shells looking for a book about red circles, you're likely to find the one about yellow circles closeby. If you think about red and yellow circles, it's clear the taxonomy says, these are things that are similar to one another. Maybe things are useful if you're trying to build a red circle, you might look at the yellow ones as a pattern, as a way of doing it. So, they're quite useful for showing certain similarities

so long as things are sitting in the same part of the hierarchy. But as soon as things are in different parts of the hierarchy, even though they've got similarities – so, for instance, the yellow circles and the yellow squares are the same color, but because they're in separate bits of the taxonomy, it might be very hard to notice the relationship. So, if you think about conventional biology, it's easier to think about the relationship probably between different kinds of birds than it is between the similarity

between, say, a bird and a mammal. And yet if you have a bird that lives on muddy ground, it's likely to have webbed feet. If you have a mammal that lives on muddy ground, it may also have webbed feet, as might a reptile because they're in a similar kind of environment, and yet from the point of view of the biological taxonomy they're very, very separated and it might be hard to notice those relationships. You usually need a separate way of classifying things in order to see different kinds of relationships.

So, let's look at our circles and  squares and now imagine instead of being put into a taxonomy, we're regarding the shape and the color as two separate kinds of ways to categorize things. So, what we'll do is think about things and we'll classify them as either circles or squares and either red or yellow. So, if you think about this perhaps in terms of like tagging documents, you might have documents tagged by the kind of shape they refer to but also the kind of color of shape they refer to. So, some documents might be tagged  'red and circle'; some might be tagged

'yellow and square'; others might be tagged 'yellow and circle'. So, these are so we can look at something and give two, or more if we had more categories, different categorizations to the same object. When we do that, often we lay these out in little  rectangular sort of tableaus or matrices like this. Here I've shown a two-by-two matrix, and in fact you have probably very frequently seen this kind of two-by-two matrix. It's used often in academic literature; it's used in management literature.

They needn't be two-by-two – you might have three or four things in each category, in which case you get a more complicated shape, and of course you might have more than two categories, in which case instead of being a nice matrix that you can draw on the flat, you have something that's all multi-dimensional. Even when people do deal with  large numbers of categories, what you often see is people dealing with two categories at once because they enable you to create one of these matrices, and it's obviously a lot easier, given we've got two-dimensional eyes to see a two-dimensional matrix.

So, what I've done is I've put now my shapes into the matrix; we've put the yellow shapes, the yellow circles at the top right, the red circles at the top left, and the circles basically are the top row; squares are the bottom row, red on the left, yellow on the right. And now we can see different kinds of relationships. So, we can see relationships that are things that are close in terms of being the same color by just looking down the same column, or we can look at things that are similar in terms of the same

shape by looking across the rows. So, for instance, you can see the red squares and yellow squares are similar because they're in the same row, but also crucially *we know why they differ*. They differ because they're in different columns and therefore have different colors. So, we both understand how things are similar and how they're different. How are we going to *use* these multiple classifications? We've got them; how are we going to use them?

The first use I'm going to give you is to  *spread your search*. And by your 'search' here, I mean the things that might be relevant to what you're doing. So, you're looking for something, and we'll come back to a solid example, but on the bottom right – you know – that was where we had I think the yellow squares before, but you're interested in things down at that bottom right. But maybe you've got something there that doesn't work very well. You've got a piece of software that is there and you want to fix it.

Or maybe you'll be asked to develop something new there and there isn't anything to go by. Very often, and particularly novices when they're faced with a problem like that will say, 'What's similar to this? Yikes! There's nothing in my space. I've got no things to use to help me to inspire me.' Imagine... we've spotted that autonomous cars are a big thing, and now people, instead of

driving in their car are going to actually be sitting around not doing anything. So, obviously they'll want to be productive, especially if they're businesspeople. So... we're thinking, 'What we should do is create some productivity application, some real office-y application to use whilst in a car.' Okay, this sounds good. But there aren't any. There aren't any, because if you sat with your laptop doing word processing in your car, you'd crash. So, nobody does this currently, except when there are accidents and – you know – things that are usually illegal to do.

So, the place we're looking for, which is – I'll label them – so you can have things that are either in the car or not in the car; so, laptops, smartphone applications. And there can be – and we're going to go as our productivity app, let's go for a spreadsheet that you can use in your autonomous car; so, spreadsheets, and there's every other kind of application. So, we're interested in in-car applications, in-car spreadsheets. That's the bottom right. Now, the top left: things that are not in the car and are not spreadsheets,

they may have some inspiration for us, but clearly,  actually, they're least likely to be useful. The things you want to probably look for are other  kinds of spreadsheet that aren't being used in the car, and that might be involved ones that are  used perhaps on mobile phones as well as ones that are used on laptops and PCs. And then also, other things, applications that are currently used in a car but aren't spreadsheets; so, we might look at media for instance because

people are constantly choosing between those,  or trip computers in cars. Those are relatively complex pieces of software, currently used actually while people are paying attention, and in the first generations of autonomous cars the idea is that they're *likely to be semi-autonomous*. So, you are probably having to switch between  maybe taking your eyes off the road if the car is the kind that allows you to do that, but then having to take control again relatively rapidly. So, we don't want to just say, 'Let's give them a laptop; they can sit and do something,'

because we may not have fully autonomous cars. So, these are obvious places to look for inspiration, to look for other systems that have – that are either in-car  systems but aren't productivity applications, or spreadsheets that have been used on other devices, and that'll give us some inspiration. Okay, so that's our first use of multiple  classifications in order to spread our search. Our second use is going to be *to identify gaps*. So, imagine you've been looking at all the systems

in the area and you've got one of your matrix,  the different classifications in; and you find lots of systems that address one thing or lots of literature, perhaps lots of books that address multiple classifications; they do – each of the category pairs except one; there's a *gap*. There's something that the existing systems don't include. So, in our car one, it might have been – you know – we found lots of car applications

that weren't spreadsheets; we found lots of PC applications that were spreadsheets; lots of  PC applications that are not spreadsheets. So, everything fails. We didn't find any productivity apps and any spreadsheets in particular for use in car. So, we might have done that because we were looking for it, but also, if you're just looking at a domain in general and you spot a gap like that, it either means there's something interesting about the gap: perhaps it's impossible to do – you know. So, currently the reason for that is because

if you try to focus on the spreadsheet in the car, you'd crash it. So, there are good reasons why there aren't existing applications in that area. However, when you have a gap like that, it also might signify a *market opportunity*, a thing to look for, a new place  to look that might give you a novel application that will enable – you know – that might be commercially important; it might just be good in a sense of allowing you to solve something in a way that you hadn't thought of before.

Okay, so let's move on again, and we're going to look now at another use of multiple classifications, which is to *discover trends*. So, in the previous one we just had one gap. Sometimes what you have is effectively nearly everything's a gap and each thing that comes in one column only appears in one row or a small number of rows and vice versa. So, here's a two-by-two, so there are only sort of two ways things can

line up in a way and the gaps line up. But if you have multiple – a big matrix, you might have a diagonal or you might have things where they dot around but when you look at them, the rows and the columns are sparse; there are actually lots of gaps. And when you've got lots of gaps there, it's *suggesting there might be a rule*. And I said a 'trend', as in one thing tends to – you'd have it more like one thing and less like another, so you can sort of see those trends.

But in general, there's a relationship or  rule – you're saying that if something's got one characteristic, then it seems more likely to have  another. Now, if you do that by looking at existing systems, that might be because people have been limited in the way they've thought about things. Again, you might have market gaps in the other places. Or you might have uncovered something that was a rule of thumb that people have been applying without realizing they've been applying and helps you to know where are sensible places to search,

where there may be that these things are impossible in some way and you've learned something about  the nature of the domain you're dealing with. So, again, let's look at an example of that, and what I'm going to do is look at shopping websites. And, to be fair, I did do a little quick  zip about some spreadsheets in order to choose characteristics that work here. So, I didn't quite do this and discover what this – I did a little bit of a pre-look as well. But anyway.

So, what I've done is *categorized* my shopping websites into high-volume products or brands and  very exclusive brands. When I looked at the website, I then asked, or actually I noticed that price is obviously a significant thing; you didn't have to look too far to guess this was going to be a major thing. Prices are major things on websites. Now, the question is, 'Is it easy – is it obvious to see the price or not?' So, some websites make it very easy to see the price – it's right in your face.

Others not. So, that's how we categorize things. Do they show the price or not? Or is the price obvious or not? Is the brand a high-volume brand or is it a very exclusive brand. So, the first one I'm looking at is B&Q, which is a big do-it-yourself store. And here you notice 'WE'RE DROPPING PRICES' it says at the bottom of the page there. I mean, there's more beyond this going down. 'PRICE DROPS' it has on certain products. The price is a very significant issue that is being pushed here; so, this is a volume brand and price is really in your face.

Here's Hermes – they make you know high-end handbags. And actually, I mean, perhaps if I dug a bit further, I'd find it, but I didn't find any prices. I have absolutely no idea quite how expensive they are, but I do know they're expensive. Exclusive brand – no prices evident in the site. Here's a brand called Mouawad. I'm not quite sure – I found it because I was actually looking for handbags, but it's a jewelry brand.

So, it must have been associated because presumably if you're looking for expensive  handbags, then you probably want to buy expensive jewelry as well. So, Mouawad clearly is an exclusive brand, and lots of very fancy jewelry – no prices. And then I looked at New Look. Because I'd looked at handbags, I thought something else a bit clothes-ish I'd look at as well. New Look is a high-street shop in the UK, predominantly young audience,

but volume, so a high-street shop, large-volume seller. Not as big as some, but certainly a high volume. And this one definitely is not quite as in-your-face; there's not quite as much of this super-sell-type thing as we saw on the B&Q site. But still the prices are very evident and clearly people are using that as a choice category. So, let's look at these. We have B&Q and New Look, which were both volume products or volume brands, and they showed prices.

And then we had Hermes and Mouawad, who were both exclusive brands, and they didn't show prices. And we didn't spot – certainly in my first searching through I didn't spot any volume brands that didn't show prices. So, I didn't find any sort of big shops that – you know – sell gazillions of things without prices being very immediately obvious, and I didn't find any exclusive brands that did show prices. And I think this is to do with who is going  to these sites. You know – if you're going to a Hermes site, you're going to probably buy a Hermes bag if you can.

And if you need to ask the price, they probably don't want you on their site. Also, probably that exclusive brands – you know you want the brand. They're not – you're not thinking, 'Which is the cheapest handbag?' It's, 'I want a Hermes handbag.' Whereas B&Q or New Look are competing on many categories, but particularly price is one of them. So, if you're going to B&Q to buy a can of paint,

you want to know, is it going to be cheaper to buy it there or to buy it at another do-it-yourself shop? And you can probably buy the same can of paint,  identical brand, as in the underlying brand, but at a different shop. So, they obviously compete on price and you're perhaps going to choose between the brands and choose between the websites depending on the price. And so, what we didn't see there was these gaps. So, what you're seeing me doing here is I am trying to understand, trying to build

– I've noticed a trend, and I'm trying to  build a model of *why* that trend might be there. And that's building my understanding of the nature of consumer websites. And that will then, hopefully, if I am going to be designing a website for a new kind of product, I can look at it and ask myself, 'Well, what about those demographics? Are people likely to be competing on price or on other aspects?' So, so far so good.

I then actually did a little bit of peeking further and found the Dior website, and actually it broke my model because it is an exclusive brand and it does show the prices. Now, possibly those handbags are  a little bit more blingy than the Hermes ones, so maybe the Hermes ones are just in a different  territory again and this sits somewhere between. I don't know. But you notice, even as I spot the  breaking in this, that there are – although it's not that there's no examples in these; I've found an example now,

again, I'm starting to interrogate it. I've got language to start to think about what the kind of people who are buying it. Why is it that they've made this choice? And I'm in a position to have created a sort of language framework vocabulary, a way of thinking of  the world that helps me to have these discussions. Okay, so I was already in one sense building quite complex knowledge about websites by looking at those examples.

So, now we're going to come to another use of multiple classifications, which is about *uncovering abstractions in things*. So, imagine I've got my 2x2 matrix of things and I've been looking at lots of things and I've been putting them in; so, yeah, I mean, I've gone back to my red and yellow circles and squares. And I've found lots of examples of systems, perhaps of literature, of books that talk about different issues. So, I've put them into my classifications. And then I notice that all the things in my left-hand column share a certain property,

and all the things in my right-hand column share a different property. And then I think, 'I wonder if that's a general rule.' So, just like when I noticed my exclusive websites tended not to have prices and the others did, I started saying, 'Is that a general rule?' So, what you could do is actually start to see general rules arising. So, as an example of this, let's look at fitness apps. So, you might have a fitness app for running or you might have a fitness app for cycling. Some fitness apps are based on mobile phones;

some are based on special— it's not really a wristwatch; it's supposed to represent like a special device like a Fitbit or an Apple Watch or something like that. Maybe – so, I look at these; I looked at lots of examples of the applications that go with these, and I'm not quite sure this is 100% true, but let's say, I think this is fairly largely true; if you looked at the applications for these special devices, you might often see heart rate and perhaps breathing and things like that as part of the application;

whereas, let's imagine I've looked at all my mobile phone-based ones and none of those include heart rate; so, I've started to learn something. Then I can ask questions – 'Is that – why is that true?' Well, I think the likelihood is – this is my surrogate mobile phone here – is that a mobile phone doesn't have the sensors. So, if you're having a specialist device, it might well have one of those little infraredy lighty things that measures your blood going through and gets your heart rate from that.

Or perhaps you've got something that – one  of those bands that goes around your chest and is picking up the actual vibration; whereas  this just doesn't have that as a sensor. It can have your GPS; it can know where you are. It can use perhaps its accelerometers to work out your walking or cycling rate from movement, but it doesn't have a heart-rate sensor. So, I've got some knowledge here. However, again, having seen that, that might suggest ideas for me; so, I might think to myself, 'Well – you know – perhaps if I – if the phone is strapped

onto your – because people often do strap them on – what about strapping one on the chest? Or strapping your phone on your chest? You know – I wonder if the microphone on the phone is good enough to pick up your heartbeat.' – you know. Or even that might be true if you put it on your wrist or – so, I'm starting to think about potential ways of designing things. I've spotted a relationship. I've developed an understanding of why I think that relationship should be there, which is the *abstracted knowledge*.

And now reapplying it and saying, 'Well, actually, maybe I can start designing things on the left-hand side that also include heart rate.' Whether that's possible or not, you can – perhaps one of you is an entrepreneur and can try and make one. The final part of this is about that *making stuff*.  So, we've decided there's a place we'd like to make things, a gap in the market... or we've just been given our brief to make something,

and we haven't got an existing thing to work with.  How are we going to do it? Well, we've already talked about the way you can spread your search. So, rather than just saying, 'Well, there's nothing at the bottom right,' you say, 'Ahaha! But there's things that are close by it that share one attribute and not another.' Having looked at those, we can then say and we also know which attributes they share, which they don't. By understanding those  relationships, you can start to synthesize solutions

that are likely to retain the good and the  useful aspects for your particular application. So, let's look at an example of that, and we'll go  back to our autonomous car. So, remember we were looking for productivity applications, in particular spreadsheets to use in our autonomous car. We've already worked out that the places to look for inspiration are other car-based systems, perhaps media centers, perhaps trip controllers, and other spreadsheets in other devices.

Actually, I probably look not just to  laptops but probably to spreadsheets on mobile devices with restricted screens because that's  more likely to represent, I think, what an in-car application is. So, I might already have – rather than just thought 'laptop, car', I might well have thought 'laptop, smartphone, car' and actually restricted myself down a bit, depending on what's available. So, I'm going to look at these non-car spreadsheets. I'm going to look at the car applications and then start asking questions about what I can learn.

You know – there's the thing that controls the volume or, should we say, the radio  channel for the car media center. I don't have a radio channel on a spreadsheet, so I don't want to retain the 'radio channelness' when I borrow it, but the use of – perhaps on the steering wheel they sometimes have little plus and minus buttons on them – maybe that's what would be useful. Perhaps we can use those buttons in order to control a cursor or something in a spreadsheet.

Maybe we look at phone dialing and the use of voice systems for phone dialing and ask, 'Can we use similar techniques that they're using for navigating their way perhaps around an address book, to navigate a way around a spreadsheet?' So, what we've got is the relevant examples and then able to bring them together and hopefully through that create a *novel* but also a *useful*, that is a  *creative, innovative solution*.

We have moved back and forth between concrete  examples and abstractions. And I'm going to talk a little bit more about that, particularly about the idea of being concrete, being very solid here. Often when we think of abstractions, that gives  you a sense of being theoretical or academic, which, depending on where you come from, might  be either a good or a bad thing; whereas when you think of design, we often think  of more concrete fixed things,

artifact-driven processes where you build something, have a look at it. And these sometimes seem quite separate approaches; however, as with a lot of these things we've been discussing in creativity, the actual real fun and the real joy is when they come together. And we often get a greater power through actually doing a combination of the two. Pólya has a wonderful book *How To Solve It* – it was written quite a lot of years ago now – which is largely about mathematics problems, but is actually a really good book about problem solving

in general, although the examples are more about mathematics, and this is sort of high-school mathematics, the heuristics that are generated are very, very useful; so, it's very worth reading. In particular, some of the heuristics are very much about this area of how you move to be more abstract and more concrete. So, one of the heuristics is if you've got something you're trying to show or trying to solve, *think of something more specific*.

So, perhaps you're trying to design a generic web design tool that will work for any kind of shop. And you're struggling with that. So, then what you think is, 'Well, instead of designing it for any kind of shop, let's just imagine I'm designing it for pet shops or designing it for tool shops or food shops.' And then you go for some much more specific example; you sketch out what kind of site you'd want for a food shop,

the kinds of information you want about each product; work out how you might try and produce that,  and then do it for some other examples, and then step back and look at the more general ones. You go more specific and then re-generalize. You might go the other direction. So, you might be trying to – perhaps you're actually working on a very specific shop design for a food shop and you're trying to think about how to lay out the different sections of the site and

– you know – perhaps you're going to have the fresh food section and you're going to have the tinned section and you're going to have the section where you put things like toilet rolls, whatever you call that section. And you're struggling with how to design this. Sometimes it might better stepping back and thinking, 'Well, actually this is about laying out lists or categories in general, and it's a bit like perhaps a library system.' And you think about more general examples, other examples of it. And by thinking more generally, sometimes it again gives you a kick

into the direction that  might help you solve the more specific problem. A specific example of this is *adding constraints*.  And we've talked about the way constraints, adding a constraint, which sounds like it makes life  more difficult, sometimes frees your mind. This is true of process. So, for instance when you have a very time-constrained process, often you end up doing quite creative solutions because  you 'can't do it properly'

because you haven't got the time, and so sometimes that works in the process, but also in the objects you're trying to construct. So, if you're trying to design something that's going to work on mobile devices in general, well, add a constraint to say, 'I'm actually only going to look at Android devices. I'm only going to look at  phones of a very particular dimension. And then I will worry with that constraint.' Or I'm going to – perhaps it might be a constraint on the kinds of people involved: 'I'm going to assume that my users have

absolutely terrible memory. Can I create a website or a system or a form of interaction that works assuming my users have awful memory?' Hopefully, it'll work better when they do. You might design a different one. You might add a different constraint saying, 'Now I'm going to assume my users have perfect memory,' and you'll design something based on that. And then you'll look at those designs and see what you've learned from them; and then hopefully then, having added those constraints, remove them again and look at the general thing and say,

'Okay, given people a bit between these, what might I do in there?' Again, another example of this is where you've  got numbers, is to try and make them either a lot bigger or a lot smaller. So, one of the examples  I think I've used already is where you've got a website that you've  been using a particular sort of format for and you suddenly discover that one of the menus gets so long it doesn't fit on the screen anymore.

And you think, 'Oh! What am I going to do?' and you might decide to perhaps make the font a little smaller, which of course works when you've got 12 items,  but then of course the next time it gets bigger, there's a limit to how small you can make the font.  So, one of the things you might do there is say, 'Okay, my struggle is that I've got 12 items and that's too many to fit on a standard screen.' What's a standard screen, of course? But let's go for that for a moment. What would happen if I had a *thousand* items in my menu? Well, now, clearly I can't just make the font smaller – it's not going to work.

I have to have a very different solution; so, I might go for a solution where the top level had perhaps – you know – things starting 'a' to 'b', things starting 'c' to 'd', that sort of alphabetic thing, a bit like going to library shelves. I might decide to classify things; so, instead of having 'a' to 'b's, it might be like the shop where you've got grocery items, paper items, whatever. But you're forced to think of very  different solutions, and you might do one of

those solutions where it scrolls incredibly  rapidly as you go off the bottom. But because you're thinking of a thousand items rather than 12, you're forced to expand your design space. Then you can go back to say, 'Well, actually it's never going to be anywhere near a thousand; it's probably going to always be... 10, 12, perhaps 20, but never huge.' However, your design space, the things you thought of, the solutions you've thought of are much wider,

and then you can look at those and say, 'Which ones actually now make sense when I've gone back to the sort of size that I was at?' In general, when we talk about being specific you might have already been thinking about prototyping. And so, we've talked about fairly concrete examples, how you might imagine these menus. Of course, you imagine something like  that; there's a big difference between imagining it and actually seeing it in action. And that's why we  like to build, as well as low-fidelity prototypes,

high-fidelity prototypes. That's partly so that you can show them to your users, you can show them to your clients, but it's also because when you look at that high-fidelity prototype, you react differently, you see things in it that you wouldn't see when things are a little bit more vague. Focusing on the physical side of that, there's  wonderful stuff you get from actually being very physical. Now, some of that's about the fact  that when you look at a physical design you learn

more about the nature of it: Does it fit into the hand well? How is the weight going to work? All sorts of things like that, but also actually the very nature of physicality – we are such visceral beings that actually we can use that as part of our  design processes and our creativity processes. The very act of playing and doing exercise, just  going out for a walk on its own, even if you're not even thinking about your design task, is itself

powerful in terms of the way it changes the chemical nature of a brain. So, actually just doing physical things can often be useful, even when it's sort of separate from what you're actually doing. However, also using it in your design process can be really powerful – creating mockups, and again remembering context, you might want to mock up the space around an interaction as well as the devices. So, again, if we're going to model this controller, you might want to model the controller. But you also might want to put it in the (inaudible) – if you haven't got the actual table

you can put it on, you might make a cardboard version of it and things like that. And I've actually seen in design studios people making whole living rooms out of corrugated cardboard in order to be able to have a sense of something working in its context. When you've got that mockup, of course you can act out what's going on. So, obviously if it's a very – if it's computationally high or intellectually high fidelity,

then you might actually be able  to do the things and they have an effect. Otherwise, you might be just more a matter  of acting through as if it was working, maybe using improvisational  techniques – you might do that on your own, just going, almost like working to a script,  or either as an individual or as a group of people together, to act through what might happen – you know. Somebody sitting down, using something; somebody walks into the room; maybe you're using a device as you're talking to somebody else,

and actually just doing a sort of  improvisational session through that. So, this is from a lot of years ago. I was with a group of masters students, and we were talking about innovative interfaces. And I was asking them as a design exercise to think of a slightly future interaction. So, not something they could necessarily do now but that was about the way ubiquitous computing

– well, Internet of Things, actually the phrase didn't exist at that point, but that kind of computation was going. And, as an example, I just want to say – you know – the kind of thing that they might want to think of. I wanted to think of an example, so I scanned around my pockets and found my Swiss Army Knife. So, we started to talk about what an internet-enabled Swiss Army Knife might be like, and how you might have like a little screen on it. And I actually made my low-fi prototype here,

because I actually stuck a bit of cardboard on. But when we first did it, we just talked about it. And then I started to act it out, and I said, 'Ah. We're going use our toothpick as a  stylus on our little tiny screen, so we can get suggestions up and it's going to say something like "Ah" – you know – "in order to fix your electric socket, what you do is you open this" – you know – maybe people have their own names, but I'm going to open a random one, a blade on it. Yeah, so you open your blade of a particular kind,

and they've probably got names for these blades, and then you read your instructions, and then you put it into the socket. And as I did this, I acted it out – I didn't actually put it in the socket; otherwise, I would have electrocuted myself, but I was acting it out. And as I went to move the knife to where I would perhaps undo the screw or something like that, I suddenly realized my thumb was over the virtual screen, the little – where we imagined the screen would be.

So, I was imagining this screen and when we talked abstractly, didn't notice. But as soon as acted out, it became absolutely obvious that your thumb blocked it. We could then think of alternatives; perhaps an audio interface with perhaps little Bluetooth earphones would probably make a lot more sense that talked you through it, rather than the little screen on it. But actually physically acting  it out was what made the difference. Let's just summarize – being concrete, it has lots of things it does for you.

First of all, it *recruits your physical intelligence*, and in two senses. There's both your – where we think about physical things, we use a lot of knowledge and a lot of background knowledge we've been building up since we were, well, basically about that big. You know – so, even as a tiny baby you're reaching out to stuff, and we've built this huge physical understanding of the world, and when we make things concrete we use that. Now, even if it's not physical, even it's like a screen design that's very fixed, you've got a lot more ability

to look at something and think, 'Ah, that doesn't look like it works.' in a way that sometimes it can be hard to with something abstract. It *exposes details*; it pushes you to detail.  Sometimes having too much detail gets in the way. But also that for other purposes, seeing those details actually kicks you to realize that's just never going to work. Now, then you can back off and go back into a more abstract discussion, so you move back and forth between the sort of very detailed and concrete and perhaps something that's more abstract;

that might be more abstract in a more discursive sense; it might be more abstract in a more sketch-like sense. I also find that *being concrete helps cut out waffle*. It's very easy to say something like, 'And we'll have a mobile version.' But then if you think, not 'What would it actually have in it?' but 'What might a mobile version look like?' So, this is not about saying 'let's design the mobile version' but to say,

'Can you at least have one example of how this kind of application would work?' And then you might discover very rapidly problems that arise, that if you just say, 'And we'll have the mobile version,' you just never notice. And the other thing is it's just *fun* – being more concrete, whether, again, it's really physically concrete, which is always a lot  of fun, but actually this is true about things which look more real in general. I often find it's just fun!

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 – have lots of ideas!'... 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. 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 an engagement? 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.

So, and it could be a Heath Robinson sort of bad idea – something 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 – maybe a chocolate teapot or maybe the car with no engine

or something like that. And 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, right? 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, the  car without an engine can't go anywhere. Are there things that can't go anywhere  that are 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, there are things you might not – 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 to yourself, '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... with the bad idea, you want to change that bad thing into a good thing, and 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, 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 on 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 could 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 – 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 and can drag the cars along so they don't have an  engine and they're being powered elsewhere. You may, as I said, change the context entirely. So,

instead of it being a car for driving around in, instead just – I've already mentioned this one – stick your chickens in it and suddenly it becomes a hen coop. And I think if you go around the world, you'll find a lot of old cars, usually actually with their engine 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... 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 'Ah!' and do something just with that. And I'll leave you with a glass hammer.

To create great user experiences. UX design teams use a five phase process: Empathize, define, ideate, prototype and test. In the empathize phase, teams explore the problem they're trying to solve with the product. User researchers conduct interviews with people affected by the problem and review existing knowledge of the issue. The stage is about knowing what needs to be solved and why.

At the defined stage, user researchers turn their knowledge into a research plan and conduct more targeted tests. They'll learn more about their users and what they're currently doing to solve the problem. Then they'll put their findings into deliverables. Tools for the UX designers to reference when they start designing solutions. These include: user Journey Maps, to show how users try and solve the problem and present. Personas, which are details of typical users.

Affinity Diagrams of what those users think, feel, see and do. And "How might we" statements that list the problem teams are trying to solve with the product. In the ideate phase, teams ensure everyone has a shared understanding of the problem. Someone will then lead a brainstorming session where the team will consider solutions for the first time. The team will come up with as many ideas as possible, even if they're silly sounding or impractical. Afterwards, they will evaluate the options and choose the most viable

and effective solutions from those ideas. In the prototyping phase, the UX designers turn those design ideas into testable prototypes. These prototypes could be low fidelity, digital prototypes or even paper prototypes. The UX designers will do their best to make sure the product is intuitive to use and make multiple versions of those design ideas. In the test phase, researchers get participants to test the prototype and get feedback.

From that they deliver usability test reports to the designers. Who then make new prototypes based on that feedback. products will get increasingly polished and refined with cycles of testing until a final design is settled on. Then the design will be developed and shipped. You think it's all over here, but not quite. Product development is cyclical and non-linear. The product can still be revamped based on real user feedback, and in that revamp you may repeat some or all of the design phases.

New information could even set development right back to the planning stage once again.

So, semi-structured interviews – well, any  interview, semi-structured or not, gets at people's perceptions, their values, their experiences as they see it, their explanations about why they do the things that they do, why they hold the attitudes that they do. And so, they're really good at getting at  the *why* of what people do,

but not the *what* of what people do. That's much better addressed with *observations* or *combined methods* such as contextual inquiry  where you both observe people working and also interview them, perhaps in an interleaved way about why they're doing the things that they're doing or getting them to explain more about how things work and what they're trying to achieve.

So, what are they *not* good for? Well, they're not good for the kinds of questions where people have difficulty recalling or where people might have  some strong motivation for saying something that perhaps isn't accurate. I think of those two concerns, the first is probably the bigger in HCI

– that... where things are unremarkable, people are often *not aware* of what they do; they have a lot of *tacit knowledge*. If you ask somebody how long something took, what you'll get is their *subjective impression* of that, which probably bears very little relation to the actual time something took, for example. I certainly remember doing a set of interviews some years ago

where we were asking people about how they performed a task. And they told us that it was  like a three- or four-step task. And then, when we got them to show us how they did it, it actually had about 20, 25 steps to it. And the rest of the steps they just completely took for granted; you know – they were: 'Of course we do that! Of course we—' – you know – 'Of course that's the way it works! Of course we have to turn it on!' And they just took that so much for granted that *it would never have come out in an interview*.

I mean, I literally can't imagine the interview that would really have got that full task sequence. And there are lots of things that people do or things that they assume that the interviewer knows about, that they just won't say and won't  express at all. So, interviews are not good for those things; you really need to *observe* people to get that kind of data. So, it's good to be aware of what interviews are good for and also what they're less well-suited for. That's another good example of a kind of  question that people are really bad at answering,

not because they're intentionally deceiving usually, but because we're *not* very good at *anticipating what we might do in the future*, or indeed our *attitudes to future products*, unless you can give somebody a very faithful kind of mock-up

and help them to really  imagine the scenario in which they might use it. And then you might get slightly more reliable  information. But that's not information I would ever really rely on, which is why *anticipating future product design is such a challenge* and interviewing isn't the best way  of getting that information.

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.