Prototypes

If you're looking at novel solutions, then  paper prototyping is a great way of starting. This is a relatively short segment on paper  prototyping, which is something that I don't think people really take very seriously, but they should do. It's a wonderful approach. It's very *cheap and easy to do* – so, low technology, low cost;

can be done at the *very early stages* of design and development; *easy to create modify and animate* because you do all that by hand. It *avoids distractions with superficial detail*; a fixation that that button is too large or it's too small or it's too blue or what have you. It *prevents* the you-must-be-very-nearly-finished impression that sometimes customers get when  you're showing them higher-fidelity mockups, without them realizing there's an awful lot of work that still needs to be done behind the screens.

It's very much less intimidating to users.  Users really do get that you're trying things out, and obviously they're quite keen to give you  useful feedback. And tied up with that is the whole aspect that it just looks much more malleable, much more unfinished than any form of screen markup. So, as a concept, it's quite wonderful, but we don't do enough of it. It's not something you would actually do in an  area where you're *revisiting* the same solution.

So, if your organization produces a lot of e-commerce sites and you've done this particular kind of solution 10 times before, then obviously no need to paper-prototype. But if you're looking at novel solutions, if you're the next big startup and you want to make sure that people understand your proposition and they know how to work with it, then paper prototyping is a great way of starting.

So, here's Carolyn Snyder, a friend of mine, who  has written a book called *Paper Prototyping*. It's not a fantastically long or detailed book, but it does go through all the basics, and you can see just looking at this particular screenshot, or paper-shot even – it's not of a screen of course – it's showing little strips of paper that have been tacked on, and you can see that the cross on the

– with color has just been applied with some sticky tape, literally, and the text in the box underneath has been done the same way. And it's just all done with users, with *a user*, typically, and an agreed script, an agreed set of pages. And you ask users to interact as if this was for real. And they tell you what they would do, and you play-act it. So, it's fairly standard office supplies. You can do most paper prototyping with about

10 pounds', dollars' or euros' worth of office stationery. You need to, as I mention here, make sure that you've *tested* your process before the user arrives, that you know what you're going to do *if* certain things happen, and you need to *agree with the team* what this process is meant to look like so that you're not basically testing something different from what the design team is proposing to do.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No matter which area of design you work in, the same rules apply. If you want to create a truly successful business or service, it's not enough to just create a great product in a vacuum. Instead, you have to ensure that each and every *touchpoint* with your brand or organization delivers a great service experience from *start* to *finish* – both for the business and employees and, of course, the customers. I'm Frank Spillers, and I've created this course on Service Design

in tight collaboration with the Interaction Design Foundation and top service designers in the field. Twenty years ago, I founded the design consultancy Experience Dynamics, and since then I've collaborated with organizations around the world to train and to create UX and service designs that are used by more than 500 million people worldwide. In this course, I'm going to teach you *everything* I know about how to consistently deliver

great service experiences throughout the entire customer journey. Service Design is about looking at the *big picture*, and that means that no matter what design field you're in, you can learn from Service Design methods. It also means that these methods that you'll learn in this course – no matter if you design websites or government or hospital services, apps, consumer or delivery services, or maybe something completely different – you'll get something out of this course. In the course, you'll learn how to go through a Service Design process,

as well as the practical hands-on methods to use at each step along the way. When you reach the end of the course, you'll be able to run your own Service Design process and you'll know which methods to use to create *measurably better* service experiences. For each method, you'll get a downloadable set of templates that will guide you through the method and how to work with it. And I'll provide you with lots of case studies to learn as you go along the way.

And also there will be interviews from top designers in the field. You'll also learn how to create a Service Design *culture* for your organization and how to set up a Service Design *team*. The course contains both multiple-choice and open-ended questions. And – unlike a lot of other platforms – your open-ended responses are actually graded *personally* by an industry expert. We've also included a practical design project, which you can choose to complete to gain hands-on experience with each and every step of the Service Design process.

You can include this design project in your portfolio to show employers that you're skilled in this technique, for example. At the end of the course, you'll gain an industry-recognized course certificate, which is trusted by leading companies around the world. And it'll make a great addition to your LinkedIn profile and your design portfolio. When you become a member of the Interaction Design Foundation, you can take this course as well as any of the other ones for a *flat-rate* annual membership fee.

In other words, you get a *significant* return on investment and a *lot* of value from the course platform. Speaking of value, if you want to deliver efficient services that  deliver value to customers *and* your business, then this is the course for you! In this online course, you'll come away with a lot of practical knowledge and methods no matter if you're new to design or a seasoned designer. And if you're practicing Service Design, you might learn something here, too! I look forward to seeing you on this course!

When you're hiring a user experience  designer, so a UX designer, as opposed to,   a UI designer, are there any hard skills  that you would typically look for? - Yes, in the world of interaction design, the primary way you communicate is through interactive prototypes. So, you want to see that people have a

faculty with one or more of the standard prototyping tools like Axure or Balsamiq. You would expect them to know Sketch or OmniGraffle, the Mac World – things like that, and that they can create interactive prototypes because the skill in interaction design is *designing over time*.   Sketching skills, storyboarding skills – very  important; journey mapping – very important. The specific tool doesn't matter quite as much, because  the tools change all the time.

So, you want somebody who can quickly learn new tools. So, if somebody had been working, let's say, in Sketch and Envision and your team is using a different set  of tools, it probably doesn't matter that much. But, again, in the portfolio would be artifacts of  interactive prototypes and interactive to the level that they could be testable.

So, you have to be able to communicate; if somebody comes in and says, "Well, I build all my prototypes in PowerPoint," you can end the interview.

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.