Design for Life: An interview with Karen Holtzblatt

Published: 26 March 2017

Supporting contextual design with models that communicate and enable interaction

Gerry Gaffney

This is Gerry Gaffney with the User Experience podcast. Today's guest is the inventor of contextual enquiry or inquiry, depending on your neck of the woods; a fundamental user research method. She's received a lifetime award for practice from the ACM. She co-founded InContext Design in 1992 with Hugh Beyer. Together they wrote a book called "Contextual Design" which I found enormously useful over the years. Recently, she and Beyer released a second edition entitled Contextual Design: Design for Life . She also launched a "Women in Tech" project to understand the work experience of women in technology companies and to explore why many are leaving their jobs mid-career. And that's a topic that I would love to cover but I think we're going to have to leave it for another episode.

Karen Holtzblatt, welcome to the User Experience podcast.

Karen Holtzblatt

Hi Gerry, it's great to be here.

Gerry

Now I have to admit upfront, I found I approached the book with a certain degree of trepidation. I was concerned it might be the contractual obligation second edition with only a few minor changes made to make it look current. But it really is a massive update, isn't it?

Karen

Yes, in fact I would say that it was five percent the same. I mean literally even though some of the concepts, I mean obviously contextual design the practice, right? So contextual inquiry is one step of contextual design. The practice is the same but now augmented and you'll get the latest and greatest techniques for gathering data, modelling and working with your team for ideation, etcetera because it's been 19 years, I think, since the first edition and you know the funniest part about it is that universities have been using that first edition consistently for the last 19 years. So I'm pleased to come out with something new and that new thing was stimulated by the fact that we needed to actually change the practice. And up until, you know, 2010 or so we could have updated the examples, right? But we actually needed to change the technique for the first time in literally 30 years.

Gerry

Because the original was subtitled "Designing Customer-Centred Systems" and you know I mean that's almost got a 1990s feel to it, doesn't it, that expression "customer-centred systems" and this one is "Design for Life." I guess that's indicative of how the landscape has changed.

Do you want to talk a little bit about that?

Karen

Yeah, I'd love to and I think every word matters. So when we said "customer-centred systems" there was no user-centred design, that phrase didn't exist and so we've given way, we still think the word "customer" is better in the Deming sense that internal customers are your customer, you know, anyone in the whole lifecycle's your customer but since the world wants to call it "user-centred design" that's fine. We don't talk anymore about making systems really. We talk about products, apps, automobiles, refrigerators; I mean technology and software is inside of basically everything in work and life and across multiple, multiple platforms. So we don't really, we change the word from "system" to "product" in the book, even though of course if you're doing a business system, you might refer to it that way, right? And really if you think about the initial difference between a contextual approach and what was existing at the time, and it's all still good, remember as the first things come out, they're good but now we have to take another step and those are good, they stay good, and then you have to take another step.

So when usability was born, it was tail-end testing and we were looking for problems. Now contextual design has never been about looking for problems, even though people can use it to look for problems, right? So, it was always about understanding the activity but the way that products were made or systems were built is it was always like "What are your features? Go away, come back, give me a list of features." So the distinction we were making is please don't brainstorm a list of features for the back of a box, that there's a coherent experience of practice - but at the time we called it "work," right? - there's the experience of work because nobody was, there was no consumer nothing at that time, right? And you'll see that word is now changed to "practice" and so the experience of work is work that you need to look at the context of the task or the activity that we were attacking in a particular product. There was no such thing, you know every application at the time became like these big monolithic things, like SAP or Bloomberg or any of it because the data had to be held by the application and they were also tying the user interface to that so. So the notion of design for task, at that time, was transformative and we said don't just look at the steps people take, surely don't look at the clicks, yeah? But also look at the interactions, the relationships, the collaborations, the process, the cultural values, the physical environment it's taking place in etcetera.

Now, so what happened? So in 2000 and, I don't know what, '07, '09, '08, and keep in mind that we worked with Nokia when the first, anything, mobile phones came out, we worked with Microsoft and everybody else when the laptops came out but really the laptop is not a mobile device. It is a heavy thing you can put on your lap but you do not take it everywhere, no matter where you're going like you take your touch phone which is effectively a small computer in your hand. So when this came out, not so much when Apple did it, I mean bravo, but when Android and the rest made it cheap, right? We now had everybody in the world holding this in their hand and the whole notion of task was utterly transformed and also the idea of how you had to think to design because now you can get your work and life done anywhere, any time on any one of multiple devices. So, you know, in the past we were using a computer and things we did on paper. Now we're increasingly using less paper and we are waking up in the morning, we might think about our calendar, think what we have to do, check in on some things, respond to some things, actually do some work. We make transfer, you know of and course we're interweaving home and work activities at the same time; we may do something larger before we leave the house, we may hang that tablet under our shoulder so we can read those law cases that you have to write a brief on later on while you're on the train and now you're actually going to be in the office and OK now you have to use the big you know search engines as a lawyer or you have to go and look something up because the, we still have a lot of our data you know sort of stuck, if you would, in the large computers or the larger applications that you need. But at the same time, you're stopping, taking a break, checking your phone, playing Angry Birds or Candy Crush or whatever your latest thing is or planning your trip on your tablet.

So what we see now is literally the way technology is integrated into life has changed radically. Now this is the first time in 30 or 25 years at that time. So every other change, even though it's heralded as great change, as long as we were tied to the keyboard and the database and one place, even if the place could move from your office to the couch, yes? You were still, if you would, held hostage to a device that does not allow you to interleave home and work and do things all over the place wherever you happen to be.

Now that we have a mobile computer, we literally can be on the whale boat making an appointment at the doctor's office at the same time. So what we see now is that even if you think you're still going to support a particular activity, you have to be thinking "what will you do in the morning?" right? What are you going to do on the phone? What would you do on a tablet? What are you going to do on the computer? How are you going to use one of those small devices at the same time as something else? Practice is broken up across place, space and device.

Today we have to design for the true recognition that nobody does heads-down work, nobody focuses for a long period of time. We have what things can we do in moments, what things can we do in minutes, what things can we do in 10 minutes? Because even if you look at your own behaviour, you will see that you think you're doing heads-down work except what's really happening is you do a little, you get to the end of something that's coherent, you jump over and check your phone, you might shake your head with a game, you might call someone then you go back and do another ten minutes until that piece is over and that's really what heads-down work looks like. But today that heads-down work means I'm touching some other devices or I'm going to some other applications. So we have to design for life because our activities are interwoven with the other activities of our life, with the other activities of our work and across all of time and space and platform; I don't know if that's too much but that's the deal.

Gerry

No, that's great. In fact one of the phrases in the book that I really like that is a bit of a summation of that I guess is that technology is now an appendage and I guess even beyond an appendage is becoming something that's even more closely embedded within and around us.

You write that contextual design is guided by three overarching principles; you talk about design for life, immersion, and design in teams. Perhaps you could tell us a little bit about that.

Karen

Sure. Now I just talked about design for life. So that what really means is that every point you can no longer be thinking "Oh, I'm going to have..." or let's put it like this, I would highly recommend that you do not have a development team for your Apple products, a different development team for your Android mobile products, another development team for your platform. If you're going to accept that the same activity and the coherent activity is moving across time, space and platform and is done in moments then you must design the activity so it's integrated. That means that you have to have that life view of what is happening in different segments of time on different applications in different places and what makes sense. So design for life means taking that holistic look at what is going on.

Now if I might stop for a moment. I was speaking recently to a colleague when we were writing the book, who, by the way, John Zimmerman, and I asked him to do a box on this for the book, you'll see his box in there and he's like "Well, Karen, you know I don't know, we have to widen things because now we have to think about service design. Contextual design is just for products." I said, "Well, contextual design might be taught just for products. It might be used just for products but it is not just for products because we've been doing, if you would, what you want to call service design today for years." If you're looking at supporting a process, again you're looking at the larger life; do you understand what I'm saying? Now if we're going to look at supporting in the store, in the mobile device, in the stationary kiosk, in the computer at home, again we're taking this broad, broad brush that looks at the different contexts in which a particular activity occurs and tries to bring those together into a coherent customer experience or user experience or whatever word you want to use these days.

So that's design for life. It really changes the data you need, what you need to represent so people will design from it and the perspective you need to take when you're designing. Now, so that's first principle.

Second principle is immersion. So there's an ongoing controversy that no matter what I say we can't get rid of, OK? And it's, like, it's the old thing and it goes you can't ask customers what they want because they don't know and so therefore don't go in the field, don't do anything, make it up, OK? I mean that's basically the conversation. We know better than you. You can't think big, you know whatever way you want to think about it. Now we've never said "Ask the customer." We said "Go out into the field and understand their practice by living with them, immersing yourself in their life," and what will happen is that your gut feel, your sense of what's really going on will shift because when we design we design from an internal sense of, an intuitive sense of rightness. Now, if the only understanding you have of rightness is your own personal understanding then you are designing for yourself. If your own understanding is tuned only by the one person you interviewed or whoever your friends are that you've talked to, then you're only designing for them. But if you're making a product for a population, you better embody the knowledge of the life of the population as it is trying to do whatever you're trying to support.

OK, so how we do that? If the team, because there's always a team, if the team goes out into the field and they do a field interview, they're immersing in the life of that person. If they come back and interpret as a team, even a two- or three-person team, the people who work there are immersing in the story. If you build the Affinity or the rest of the models from those notes that you've captured, whoever is building it is immersing in that data. Again, if you walk the data in order to do ideation and visioning, that's another formal immersion experience. So the way we change the inner experience of the team so that it is reflective of the customer population you're trying to support is by immersion. If you do not do that you're going to be doing what we call "design from the I," designing from yourself, what feels good to you.

Gerry

And that's "I" as in the ego, not "eye" as in the looking thing.

Karen

That is correct. "I" as in the capital I. And so, you know, effectively, and the more and more engineers and designers who love technology are trying to support people who don't love technology - they just want to use it - the more their personal gut feel has nothing whatever to do with the people they're designing for.

So that's why immersion is critical and we do it over and over and over and over again. So that's the principle. Why? So that when you make decisions, it makes sense. OK? We're not asking the customer, we're asking you to transform yourself. Right? Alright, I mean it isn't that we don't listen to the customer, let's be clear. We do but so often the customer will say "fix it like whatever my product is I'm used to using," OK? So we're not going to do that, yeah?

Alright, the third principle is design in teams. Contextual design has always been used for real product teams in real companies. It was invented for them. It is not an academic thing. It did not come out of academia. I'm not saying I didn't read primary literature and know a whole bunch of that stuff that infused the activity but the problem is that whether you like it or not, OK, so today you can still build an Apple alone in your garage but that's not going to touch billions and millions. Effectively, in order to produce a product or an IT thing, you know, business app or anything else, you need to work on another human being and that's the big problem because human beings are just hard and different people have different roles and responsibilities. They have different cognitive styles. They have different personalities. They have different levels of power. They have all kinds of things that make working face to face as a maker community difficult. Why? And I'll just give you a teaser; one of the reasons that I believe that women and the issue of women in our field is more difficult than let's say ibankers or lawyers or doctors, which are also hero industries, meaning you work yourself to death, OK, is that they have teams but that looks like separate assignments. You don't really have to show up every day, you don't have to deal with each other every day; you're not nose to nose dealing with other human beings every day all day of the week.

So contextual design had to invent a whole series of techniques to help teams collaborate, to make sure a shared understanding - the most important thing - is created, right? It's not effective for the user, not perfectly effective, you might have to trade that off and make it okay but basically the best way to get the engineers to understand the users' experience is drag them out with you into the field because now they get immersed. So if they don't have a shared understanding of the life context of the user, if they don't have a shared understanding of the technology, if they don't have a shared understanding of the direction then everyone's going to be pulling at each other and particularly UX people are, you know or whatever we're calling ourselves these days, are going to feel like they have to convince or hammer or sell and none of that is effective. So if you build you techniques for coming to a shared understanding right into the process then you make organisation change without knowing it. So we talk about what to do in teams.

Gerry

OK. My copy of the original which is a paper book, of course, is full of highlighted bits; essentially it describes a framework for designing products including user research and design aspects. You described then a set of models, things like cultural model, sequence model and so on but you've added some new ones and you've demoted some of the existing ones. Can you tell us about the "cool concepts" work and how that informed this process? And let me upfront and admit that the term "cool concepts" really sort of is one of those terms that "Oh, my God" - maybe because at the time I was doing stuff like working in prisons systems and I was thinking "Wow, cool is as far away from where I'm working as I can imagine." Yeah.

Karen

Well, so you have to think more about what that's about. So, as I said, there was a big transformation with the iPhone. It isn't that there wasn't coolness before that but why do we call it the "cool concepts?" Because basically people were so utterly transformed that they could not stop talking about their mobile device and what they would say is, "This is cool. This is so cool. Look at this, look at this, look at this." They would exclaim, they were like effervescing. I mean they were nuts really, if you think about it, particularly in the beginning. And so it was clear to us that something was going on, like had never been going on before and so we basically started the Cool Project and the point of the Cool Project was to go out and find out if we could understand what were the dimensions? Because if we were now in a new world in which the expectations for products and design have changed, what if we could say these are the things you now have to do in order to make your product.

If you don't like "cool" you could say "modern" but modern is not as transformative as what the cool concepts are really doing. So we went out into the field, we asked people to gather the things they thought were cool. So it's cool by definition, not cool by literature review, OK? So people brought their cool stuff together and then we talked about them, we watched them use it; we understood what was going on with them. We even gathered data eventually on business products and tried to understand what was cool or not cool about the business products. And the interesting piece is that sometimes people, if you said well, "Talk to me about something cool in your business product," they would just hang their head but then they would start to talk about why it wasn't cool and the reason it wasn't cool was it didn't have the cool concepts.

Now if you actually, and we did this, I haven't published it but if you actually look backwards in time, you can track the seven cool concepts to almost every invention that happened before. So what we hoped to put together was a framework for understanding what you need to consider the real design principles that were necessary. Now we don't have time here to go through each of the cool concepts but they are broken up into the wheel of joy and life because at the absent centre of coolness is joy and I mean human joy, I don't mean a little smile, I mean like when people talked about their stuff they were like losing it. They were so excited; it was like joy was being ripped out of their soul. But if I say design for joy, that's not any better than saying design for cool or design for anything that has no articulated, you know, what goes along with it. So instead I say design for accomplishment in life or interweaving home and work, as we talked about, design for connections so that when you're in that unstoppable momentum of life, you can still stay in touch with people. Design to support their identify and what makes them feel good about themselves and design for central experience. Now I'm getting there and now we have design principles in the book for these things.

Similarly, the second, last three are the triangle of design in use, of joy in use, rather, and they have three concepts which are like UX on steroids and you know the basic message is "Good enough is not good enough." If it is not direct into action you can think it and it happens, right? Ask a question, get an answer and it's right. You want music, press Pandora and you've got it or Spotify or whatever the latest one is that you want, that we live in a world in which we expect things to happen like that [claps hands] and so the hassle factor which is the evil twin removes the hassle of technology and creates the joy of relief and the delta is our experience of learning which is "Nope, not gonna," and so taken together the three of them are defining what we have to be caring about today.

So what we really have with the cool concepts and you know we could never think of a better thing than that is seven dimensions that we ought to be designing for and doing them on purpose. Alright, but if you're going to design for life, you've got to collect different data. You better know what's happening when they roll out of bed with this particular activity. You have to know what's happening in the commute. You have to know what's happening when they're on a bus. You have to know what's happening at your latest coffee shop. You have to know what's happening at work. You have to know what's happening in the hallway. So the Day in the Life model is there because we're now collecting data on the movement of our target activities throughout the day and throughout platform and time and that's what it's showing us. The Collaboration model is showing us people interacting with each other in a way that's more accessible than the Flow model which was the original looking at people interacting but it was dominated more by processes because we were supporting more processes when we were supporting systems in the past.

The Identity model is terrific for marketing. It's telling us what the core dimensions, the core identity elements, the way we infuse our personal value in, for example, driving, in, for example, buying. And so if we design for those, people are going to be all excited because you've supported who they think they are. What that means, you have to collect identity data. So same thing with sensation, if we work with GM, with cars, the sensual dimension of products, particularly physical devices matter. So what happens is that the cool concepts change what we focus on. Now this now changes the data we collect, the models that we created.

Now why is it important? Because you're not going to design for life or design for cool if you never had that data in front of the team. They'll either fall back to looking for nits and fixes which will never make a transformative product, right, because contextual design has always been about product concept, understanding either a new product or understanding a set of features that we should put in but it's never, it's not a usability task. So if you fall back to that, if you fall back to task analysis then you're not going to end up cool. So in the end the models force, think about the immersion concept, the team to have in their face, these are the things I want you to think about and have design ideas for. So the new models, we actually designed with contextual design and we iterated them until they collected lots of design ideas. In other words, we created them as communication devices and we tested that they actually generated and pushed ideation. So in many ways you don't really, if you collect the right data, use the models and then you use our new ideation practices, you don't really have to tell people, "Do this to be cool," because they'll automatically just do it to be cool and they will have a more cool product and we have found that to be actually the case when we work with teams. So you don't actually have to beat anybody over the head with a rubber hammer if you just have the data and put it in their face. So, again, we go back to the team immersion issue.

So the models represent what we believe you need to do for a new practice, to change the thought processes of the team so they'll design in a different direction, doesn't mean the old models don't matter, everyone's always going to want to do task analysis. The Sequence model is our form of the task analysis. We simplified the Cultural model so that you know and created the Decision Point model so we can see what was driving decisions. But if you're doing a product that's for your internal organisation, the Cultural model is a good thing to have. And if you're doing a process, the Flow model is. So actually the chapters, if you buy the book, the chapters for the, the old chapters are still available. They're up on our website and you can get to them if you have those needs. And of course the Affinity, you never don't do the Affinity. The Affinity is the most fundamental model. It's the same. You can put pictures in it if you want but basically if you're going to do anything, you start with the Affinity. Did I answer that?

Gerry

Definitely. Sometimes it seems that new models in UX appear with tedious frequency and with no justification for them but I really did like them, you've already spoken about the models, "Day in the Life" and "Collaboration" and so on. But one thing I really like about the models that you guys describe is their clarity of purpose and you've already mentioned there, I guess, the way that they're a supporter of communication. But that's so important, isn't it, the model has to communicate? And you talk about three aspects of a model that are what make it useful; you talk about meaningful structure, story language, way in and interaction, which is actually four things, not three. But do you want to tell us a little bit about that perhaps?

Karen

Yes, I think today UX people need to realise, well this was always their job but now it really is their job, that their job is to get the data and communicate the data in such a way that when the team has immersion experience, that they get it, that they internalise it and that they can use it. Now what does that mean? That means that, and this by the way has always been true, writing a big white paper, somebody might require you to do it. If so, that's fine but don't think it communicated anything; it didn't. Writing a PowerPoint slide and giving a presentation where everyone's spacing out halfway through the talk is not communicating. If the deck has 12-point font and it's loaded and it's really a document in PowerPoint, this is also not communicating, right? So the question on the table is how do we get data into the brain of the people that need it? Yes? OK, so remember our goal is to transform the inner understanding and gut feel of everyone who's going to make decisions at two in the morning or in front of their desk when they're doing their individual stuff. Now over the years of course we've been using all the models. Some of the models work better than others. The Affinity diagram always works, period, hands down. And so we learned from the Affinity diagram, abstracted out what was going on with it. Because it is structured, highly structured there's a green, a person, a human being can attack the green because the green basically says I'm now going to ignore the whole rest of the wall. I'm only looking at this piece and this piece is also chunked. Okay. So people can take in things in chunks and so it said to us there better be a meaningful structure that looks like a set of chunks. If you look at the Day in the Life model, for example, you'll see that it has generally it has a chunk, that's the beginning of the day, a chunk that's on your way and a big chunk that's when you're at work. It's not bigger than anything else but I'm just saying. And it is graphically represented with a grey background but inside of each of those the graphics and the drawings are also chunked into larger chunks and chunks within chunks. If you really think about it like that what we're basically saying is stop on each chunk, think about each chunk. If you do that, that's what people do. But in order to do it you have to be sure the graphics work. So we actually played around, even with the colour, and you'll see that we use primary colour because the colour enlivens what's going on. So, you know, too often designers get in love with things like black and silver and white writing and all this stuff. This does not draw people in. This does not use design principles like the primary most important stuff should be bigger than the less important stuff, yeah?

So we're using literally principles of communication design in the models themselves. Okay, the other piece that we realise is that people do not naturally think in abstract reasoning. They naturally think in little story snippets and so if they're going to think in stories then we should give them stories. If they're going to you know tell the story to themselves of their own personal experience that's just their own story then we want to give them stories from real people so that they can respond to the real data.

So inside of all the models, the team has to pick the most important stories to communicate the overarching experience to the team and you'll see inside of it is there's no abstract reasoning. It's all story language because story language, you know mankind has been telling stories since ever, cave men, right? We've been drawing on the walls the story of our life forever. So we are like hardwired for story reasoning so we should use story language but it has to be, it's not a novel, okay? It has to be like Hemmingway language, right? Short, to the point, you know, brisk. So we talk about story language. The other thing we have to be sure is it's very clear where to start and what's going on. So in the Day in the Life model, for example, again, if the morning is here on the left and then there's an arrow leaving the house and then work is at the other end of the arrow, everybody who has a language that reads from left to right understands how to look at that picture. They know I'm starting on the left, I'm going on to the right, I'm following the arrow, yeah?

Now look if we were in Israel or if we were in China we might have to change stuff but if you're in English this is the right way to go. There's a way to get in it. If you look at the Identity model, for example, it's broken into three chunks with three to five bubbles in a chunk; that's very accessible. There's a way in, yes? So every model is thinking explicitly how to get you involved in the model itself. To help we also create design questions, for example, in the Day in the Life model, because if you didn't know how to approach the data, the question bubble heads are there, they're giving you a design challenge which will help you focus on how to think about the data. So we have way more support than we did with the old models that were effectively created for engineers that were used to engineering-type box and line and bubble models in database drawing. So now we have designers, user researchers, the models have to look like things that are appropriate for the whole team and for the customer population.

The last thing I want to say is just like nobody's really reading your White Paper, nobody's reading any long emails, really nobody's reading if you look at the cool concepts. They want you to think for me, is one of the primary principles. You know Google will give you the answer. I mean, my God, now we're referring Wikipedia in our references. I mean nobody's... So we have to make sure they interact, so in contextual design in the Affinity Diagram, the wall walk, which is the beginning of ideation, we say we want you to walk the wall, read the Affinity, talk, we build it bottoms up so it's an inductive reasoning process but we use it tops down, go to a green, read the green, read the pinks, read the blues, read a few yellows and if you have a design idea put it up on the data.

Now that interaction of having to put a design idea right on the data forces you to know that you're going to do design that's emerging from the data, responsive to the issues, not staring off in space thinking what might be a good idea. So that interaction forces you right into the data.

Similarly if you put design ideas or answer the question of the head bubbles on the Day in the Life model, you're putting design ideas right on the model. This is how we evaluated our models; did they have design ideas? But frankly you can do other things, you know young people I know today they might have a hunt, read the Identity model and find yourself in the bubbles; who are you? They might have a game; they might have some other question. I don't care what you do but you've got to have a way that people are actually interacting and not simply staring at the data. So that's our four principles of communication design. And by the way you can download the templates, the illustrated templates for all these new models and just use them, fill them in, move them around.

Gerry

It's apparent that you describe, Karen, the use of the models in a reasonably well resourced organisation and I remember you know being conscious of this when I first used the original, the first edition of the book, but you do also have advice for people who may be working in more constrained circumstances or maybe in a one-person team and so on. Do you think that the book is applicable to those people who are, who find themselves maybe in a little start-up where they're the only person who's got a UX focus or a customer focus?

Karen

Well, absolutely. And this is the reason that we have little boxes throughout the book and they're basically we call them the On Your Own boxes. And these are written by Hugh, my business partner, and he is now working intensely with start-ups, using contextual techniques in a start-up, and when you're in a start-up you don't have anything like the resource, you may absolutely be alone, and just like in the old days if you're the lone user researcher and you just want to start this up you effectively have to do guerrilla contextual design. And so he has many good recommendations in these boxes for what to do but you know, for example, if you want to gather data and they aren't used to the idea of it just you know go along when they're visiting a customer site for marketing purposes and say, "Oh, can I interview a couple of people?" and then go off and do your contextual interview or get the sales force to open a door for you. Effectively what's going on is what we used to do when we were doing guerrilla contextual inquiry back in you know thirty years ago when no-one thought it was a reasonable practice. You do what you can do. You network through your friends. Today you can put it out on the internet and say, "Who knows somebody like this?" and just do it on your own because when you start dripping that data back to the team, they start going, "Ooh, that's really interesting." And similarly, you know if you have to you can interpret alone. I don't recommend it. Hugh doesn't recommend it but go grab somebody who cares about the user experience and who you have to work with like your designer and interpret together with them. If you're, one young person, she was bringing a number of people along with her and they're all impatient in this particular company and so she gave them, whoever was observing, she gave them a pack of post-its and told them "Write what you think is important on the post-its." You know they had interpretation sessions in the car while they're driving from place to place. There's ways of being smart about how to do the most basic pieces. You know, how about building the Affinity diagram, that's essential and it is labour intensive. Well, order pizzas, get everyone to come in, get them to come in in you know shorter periods of time like two, three hours at a time, not two, three days and do it in chunks. Gather your data, six to eight people at a time, build your affinity, six to eight people at a time, shortens the whole thing down. So what the recommendations are that Hugh has built in there are things that can be done at any point in time and the book we wrote in the middle of these two books is called Rapid Contextual Design and that book has schedules, we have a few schedules in here, but effectively, you know if you've got, depending on how much time you have, you can get stuff done, you know? I mean I'm working with my student team right now on intervention games for women using CD for creating games and it's actually very fun and they have effectively one day a week to get the work done and we're doing it, you know? Building prototypes, the whole thing. So it's absolutely doable. But if you've got a bigger company and you need more of the team processes, you need more, you know you just need more, you need thud factor, you need to convince people and you want a larger understanding of things then use regular, contextual design. But if you're in a company that has no patience, then use it in layers, collect six, build it together, collect six, add on, collect six, add on. Now you've got twelve. That's, usually twelve, fifteen, eighteen is enough for any project.

Gerry

I think we could obviously cover a lot of other topics that we have listed down as potentials, Karen, but we've pretty much run out of time. I will remind listeners that Karen's book is called Contextual Design: Design for Life by Karen Holtzblatt and Hugh Beyer. I would highly recommend it. I think the models are entirely rigorous, practical and hands-on. It is a big book so it's a tad under 500 pages but it's a book that is well worth the effort in reading it and I personally have found the first edition enormously useful and practical and I'm really pleased with the update and the new models in the second edition.

Karen Holtzblatt, thanks so much for joining me today on the User Experience podcast.

Karen

Thanks Gerry, it was fun.