High-Fidelity Prototypes

Well, as we know, we're doing interaction design.  We typically have cycles of interaction where we design things, we prototype,  we evaluate the prototype and then redesign when we understand the problems. So, you start with something and we iteratively make it better and better and better.

We do this because we're never going to get it right first time because users are complicated and we're just not good enough as designers and probably never could be good enough to get things right first time. So, we always iterate. That's exactly the thing to do. Completely standard. If at first you don't succeed, try, try again. That's easy. We know this. I hope you've learned that lesson. You might have learned it from me, but you've probably learned it in your own experience and certainly elsewhere as well.

That feels like that's the end of the story. Iterative design. Everybody does it. However, it's not the end of the story. If you just do that, it might work, but often you might actually get stuck in things which are not so good, after all. I'll explain why this is; and so, what I'm going to do is imagine instead of doing a design, I'm walking and trying to get to the highest possible point. So, what you want is the best possible design.

I'm going to think about walking and trying to find the highest possible point. So I start walking, and you can look these up on Google Maps for yourself. But imagine I'm somewhere near the boundary between Wales and England, I'm slightly on the English side, but I'm near... There's a range of hills called the Malvern Hills. So let's assume I'm starting in Great Malvern, which is the village at the bottom of those. And I start walking upwards, and depending on exactly where I start

– let's imagine I get the highest points of the Malvern Hills, and these hills sit in the middle of nowhere. So here's me and I'm starting at Great Malvern and I'm going uphill. I'm going uphill. And then I get to the top. The highest point in the Malvern Hills is a peak called Worcestershire Beacon. And it's just under 1,400 feet tall. That's 425 meters. So it just counts as a mountain by British standards. Anything over 1,000 feet is a mountain.

Obviously not a tall mountain but it's a mountain. But it's the tallest place for miles around. You can look out and you can see – I think it's three counties meet there and you can see forever around. And you feel you're on the top of the world. And you are locally on the top of the world. But of course you're not. It's only 1,300 feet. If you'd started, of course, somewhere in the Alps

and you started walking up and you'd walk up and you'd walk up and maybe you'd need your axe, your ice axe, to help you. You might have got to the top, instead, of the Matterhorn. And the Matterhorn is 14,500 feet tall, more than ten times as tall: 4,478 meters tall. So at the top of Worcester[shire] Beacon you were at the highest point you could get to.

There's nothing you could do, no direction you could move that would make you better than where you are. In fact, everything you do would make you worse. You'd go downhill. But you weren't at the highest point – the Matterhorn's a lot higher. And of course, if you went into the Himalayas – K2, Everest – far higher again. Now that's a story about hill climbing. But that hill climbing applies to prototyping.

When you're prototyping, you're doing iterative design, you are hill climbing the design space. You're looking at the design you've got and you're making it a bit better every time. Now, sometimes you just end up with a really, really good design. But of course, in the physical world, if you start in the wrong place, you don't end up in the highest position. Similarly, if you're prototyping and if you're designing iteratively, if your initial design is a rubbish design, you just end up with a slightly-better-polished rubbish design

at the end of iterative prototyping. If you start off with a really good design, then you end up with a really-polished good design at the end. The start point matters critically. Now when you understand that, you can start to work out what to do. Sometimes that means really completely stepping back, particularly if you find yourself sort of going around circles in your design. Sometimes you do. Every time you fix something, you break something else.

The time to stand back. Or what you might do, which is a technique used for actually computational optimization. You might start with lots and lots of designs and sort of work with them all a bit. See how they all work out and then perhaps throw out the least good ones and go with the best ones. You see that graphical designers do that a lot. It's hard to do that with interaction design because you have to commit a bit more. So it's really important that you don't just rely on the iterative process to fix the fact

you started off with a poor design. You need a really good design to start with, which means you really have to understand deeply what's going on. But also, when you're in the middle of that iterative design process, it's really important to keep an eye on what's going on and to actually ask yourself every so often: "Am I in the right place?" And sometimes you do have to actually call a stop to it. You've learned a lot by where you are, but actually step back and say,

"Actually, we're going to have to completely change some aspects of what we're doing." And basically take the helicopter from the Malverns to the Matterhorn.

How We Can Communicate Better So, the first thing is that we need to establish some *ground rules*. When developers get a design, they know nothing about the product, usually, or almost nothing. And you designers know everything – you are the authority. We just lay the code bricks here and there.

So, *your job is to share your knowledge, share the context with us*, and *our job is to listen, to absorb it*. And this is a moment where there are the most problems. And I think that the reason is that we often *share some misconceptions* about each other's work, and designers often think that their job is to create a design, hand it off, and their job is done.

They also tend to believe that developers are lazy and don't do a good enough job with the designs. And, actually, that's often true, unfortunately. Even in my company – my company started as a design-only agency, and my partner is a designer, but he's seen over and over again how developers  execute the design

and that the design was a totally different thing than the final product. And this is a realistic example, to be honest, so the colors are more or less fine but it doesn't look how it should at all. So, it really happens. And it happens a lot. And also, developers have many problems with designers, especially with some changes in the designs

that we are not aware of and they are made. And also, many times designers think that something is just a minor change. You have to do it, and you have to do  it fast – and, for us, it's a huge thing and not possible to change in a week or even  a month sometimes. So, these accusations are sometimes true but it shouldn't really matter

because we both have our flaws and we have to recognize those flaws, and focusing on that  creates a really toxic and unfriendly work environment. So, I think we don't have to avoid making mistakes and talking about them, but *embrace* them. So, I think there are two important mindset shifts that can help us.

One is to *change the way we think about handoff*. So, handoff – I don't even like the  word 'handoff' because it sounds like a one-time thing, and it really isn't, especially now. It's more of a process. And I really like the term that Brad Frost coined about handoff: He calls it a 'hot potato' process. And the difference between – I called it 'waterfall' here – but the old way when the designer works,

hands off the design, and then the developer works, and the hot potato process is  that 'hot potato' process. In the 'hot potato' process, we work at the same time. So, usually the designers start work, they create some screens, they give it to developers, and we start building them, and we start exchanging information, communicating, improving, working in iterations. So, most digital products nowadays are created like that.

So, that's the first mindset shift. We should  stop thinking about handoff as a one-time thing and *start to think about it as a process*. And the second mindset shift is *giving others the benefit of the doubt*. And I already mentioned that we will make mistakes that happen; we can fix them, we can improve them, and in my experience not thinking about designers as someone who's just an evil overlord

who changes designs when they want, but like another human being who has their problems, too, and their job is very hard. It helps a lot in cooperation.