Planning Your Prototype

[00:00:00]
>> So those are your different options, and it's important to know what you're using and when you're using it and why you're using it. So it's worth just taking a pause before you jump into prototyping. I think a lot of people jump into prototyping maybe a bit too soon.

[00:00:17]
A little bit of upfront planning will help ensure that your time is used efficiently when you do prototype. So one of the things that I like to do is a kind of before prototyping step, although you could argue it's a type of prototype in its own right, is user flows.

[00:00:34]
I don't know whether this is anything anybody has had a play with, but I find it really great to just kind of plan out how the different pages will work and what the flow through the application will be. For a start, I'm particularly seeking to answer what the entry points into the app, how people might arrive in it.

[00:00:56]
Is it always through a login? And do they always land at the same dashboard, or could they come in for a deep link? All of those kinds of things are quite useful to plan out beforehand. Then obviously, there's the key actions and steps, what potential steps a user might go through to reach the different goals that you've got on the site.

[00:01:18]
Whether people are gonna be skipping around the site and a lot. Oftentimes I find with apps that they're not very streamlined in that way. So to complete an overall goal, they have to go into one section, then come out of that section and go into another section, and there's no nice flow through it.

[00:01:35]
So planning all of that out beforehand helps me at least. Then there's decision points so identifying critical decision moments in the flow. So for example, with an e-commerce site, there is obviously the decision of whether to add something to basket. But there's also then the decision of whether to actually proceed through checkout cuz a lot of people add things to a basket and then abandon it.

[00:02:06]
So knowing when those key moments are in the app often is important. And error handling and feedback, right? So I try and think through, where are things likely to go wrong. How are they likely to go wrong and how am I gonna respond to that? So user flow is basically a kind of series of individual screens that kind of show the flow through the application and branching points where certain decisions have been made, etc.

[00:02:38]
So yeah, I'm a fan of those. And then finally, the other thing that I do look at with user flows is alternate paths. So sometimes people can come at a piece of functionality from different directions and will they have the relevant context, etc. So I kind of fiddle around with that a little bit doesn't need to be perfect, but just to kind of get an initial thinking before I go too far into it.

[00:03:04]
Once I've got that, then I've really it's a matter of deciding on the fidelity of the prototype that I need to create. And that kind of depends very much on where I am in the process of the application. Because I don't tend to just create one prototype when I'm building out an app I potentially could make many prototypes.

[00:03:30]
And I know that sounds a little bit overkill but sometimes it's just easier to do it that way and so I do it. So for example, you might be doing ideation right at the very beginning. So you might be running a workshop where you've got stakeholders in and you're kind of trying to create lots of ideas.

[00:03:48]
Hey, wouldn't it be cool if we did this or that and the other? And that's where I see paper prototypes as being really valuable. It's just kinda sketching out ideas in those meetings. I know a lot of people are huge fans of paper prototyping. And they take on those paper prototyping and they test with them.

[00:04:06]
And to me that feels like madness cuz they're very low fidelity. And so, it's quite hard for users to picture what's going on, but also paper prototypes on easy to edit and change and fiddle around with. So I see the main version for me personally, paper prototypes are great for chucking out lots of ideas to begin with and then I kinda lose interest in them after that.

[00:04:34]
So when we start narrowing down our ideas to something that's a bit more solid. Then I'll increase the fidelity a little bit and I'll jump into some greyscale prototyping. So where I'm not really worrying too much about the design but I'm trying to get the main kind of elements in place and how it all flows together and works together.

[00:04:57]
And that's usually tangible enough to do a little bit more kind of development and refine it, test with it and explore it a bit more. So I spend quite a long time in greyscale prototyping generally. Then as I start to iterate on things and it's beginning to come together and I've got a stronger direction then I start to create clickable prototypes.

[00:05:23]
Sometimes this can still be the greyscales, right? So I'm just kind of joining those together and making them click through from one to the other because I'm beginning to have a bit more of a strong direction. And there tends to be more testing that's going on at that stage.

[00:05:40]
And then when we're trying to finalize the approach so that the developers can go off and do their thing and they've got something that is effectively a functional specification. Cuz I'm not a fan of written functional specifications personally because they're open to interpretation. And people can disagree over what was meant in a written functional specification.

[00:06:06]
But a good prototype is much more concrete and much more obvious what's gonna happen. So at that stage, I end up with a much more interactive, richer, higher fidelity prototype. Now, I'm not saying I do all of those steps on every single project because there are constraints. But pick and choose which you feel is the most relevant to you over those journeys, but at least having a clear idea of where the strengths of different types of prototyping comes in is worthwhile.

[00:06:38]
And often a kind of underappreciated part of prototyping. And probably, the bit that I almost like the most out of prototyping is engaging with stakeholders during prototyping. A lot of designers [LAUGH] everybody took a note at that point say I'm not sure I agree with that. I'll have to write that down.

[00:07:03]
A lot of designers like to go away and hide in the cupboard somewhere. And at most talk to some users and then produce the design. But actually, I'm a huge fan of collaborating with stakeholders to create a prototype and I've got several reasons for this. One is that I think it leads to better products.

[00:07:26]
The more perspectives you have in something, the better it tends to turn out. For example, having a developer's perspective in prototyping is really valuable. But even a marketer's perspective is good or somebody with business experience, all of these bring different perspectives to the table that are all valid.

[00:07:47]
You just need to know how to manage those different perspectives and balance them. But more importantly, it leads to faster approval. If a stakeholder helps create a prototype, they're much more likely to approve it, aren't they? Let's be honest. How many times do you reject your own work?

[00:08:06]
Well, unless you got big imposter syndrome. But, yeah, I mean most of us are more likely to back our own work. And taking that even further, more likely to support it in front of other people. So if you can get a senior executive, for example, involved in a limited way in prototyping then you're golden, right?

[00:08:33]
Because that person will back it to the hill and argue on your behalf for it and it's much more likely to get improved and go forward. So of course the challenge is knowing, well, how do you do that? How do you get people involved without it ending up becoming designed by committee, which obviously nobody wants, right?

[00:08:54]
Well, I tend to run workshops, wireframing workshops in particular. I mean, there are lots of ways of doing it. This is one that kind of works quite well for me. So the only problem with it these days is you have to get everybody in a room together, which is increasingly difficult because nobody likes to put on grown-up clothes anymore and leave the house.

[00:09:20]
But other than that, it can be it can be quite a good little session. So what what do I tend to focus on in these sessions? Because you're only talking about few hours maybe three hours if you're lucky, an hour and a half if you're unlucky. I basically tend to get them focusing on the core journey.

[00:09:41]
Let's look at some of the key screens and functionality that are central to the kind of user experience that we're creating. If I know that there are certain controversial screens that people are gonna be argumentative about and are gonna be problematic. I sometimes include those just to, right, let's get this out in the air before I put any work into it.

[00:10:04]
So I don't wanna spend hours mocking up some page that I know everybody's gonna tear apart later. I prefer to have that conversation up front and then we all know where we stand. And then sometimes I'll look at the high effort screens, right? So pages that need a lot of work.

[00:10:21]
And there are many different stakeholders involved in. Again, let's just get it all sorted out and not do it via endless email chains of people going, well, I'm worried about this from a legal perspective and just get them in a room, get them working on it. So what do I actually get them doing is probably a valid question.

[00:10:44]
I'm a fan of Crazy Eights. So I don't know whether anybody's come across Crazy Eights. What's so great about Crazy Eights is it makes people feel like they've contributed. But actually, what they're producing is so low phi that actually it's open to lots of interpretation and still gives you the freedom to do what you wanna do as designers.

[00:11:06]
So just very broadly normally, I'm normally a bit kinder than the most Crazy Eight exercises and most the kind of traditional one. I think you take an A4 sheet of paper, you don't have A4, what's it? Letter, you're so imperialistic, says the Englishman. [LAUGH] So you take your A4 bit of paper and you fold it so you end up with eight boxes, like here.

[00:11:32]
I'm actually usually a bit more generous. I usually take a flipchart piece of paper and fold it up, so they've got a bit more space to work with. But basically what you ask is you ask each team so you split whoever's in the room down into teams, each team and you give him eight minutes to generate eight ideas on a single piece of paper.

[00:11:51]
Now what I love about this exercise is that not only are you involving them. So that they feel they've contributed. But you're also educating them. You're also saying, look, there's more than one way of doing this. Cuz everybody gets in their head how they think it should be done, right?

[00:12:12]
And of course, everybody's thinking a slightly different thing. So by making them come up with eight ideas, right? Of how we might do the checkout or the homepage or the whatever it is, right? By making them generate eight ideas, it forces them to think outside of their, what was in their head initially, right?

[00:12:34]
So it's really worth it from that point of view. Then essentially the group will pick four of those ideas that they like the most, and then they join up with another team. So that's two fours, so that you end up with eight ideas, and you pick the best four again, and you repeat the above steps until you've got four ideas remaining, right?

[00:12:54]
So you end up merging team, merging team, merging all team, and then you end up with the four best ideas. And again, you're ending that exercise with four ideas, not one that you're then forced to go away and do as a designer. So that's one exercise that could be done very quickly and tends to be quite popular and makes people feel engaged.

[00:13:17]
It's not the only option. Another option is to design sprint, anybody ever done a design sprint? Yeah, you have.
>> Kind of a little bit, yeah.
>> You've done a mini design sprint.
>> Like a practice.
>> A practice design sprint. So just in case you don't know, let me run through what a design sprint is.

[00:13:34]
It's a technique that was created by Google and involves a week of research, prototyping and testing. So it's an intensive week-long event and five days. Day one is all about understanding. So you map what you're trying to achieve, you choose a target audience, that kind of stuff. Day two is you diverge, you sketch various solutions.

[00:13:59]
It's pretty much like we were talking about a minute ago, you spend a day exploring different ideas. Day three is you converge, so you decide on the best ideas that were produced on the day before. Day four, you build some kind of prototype that represents your chosen direction.

[00:14:18]
And then day five, you test with that. So that's the idea. I'm not a fan, if I'm honest. I've included it because I knew if I didn't include it, everybody would go, you've done a course on product design and not mentioned design sprints. And the design sprint community is very pro-design sprint.

[00:14:40]
So I'll probably get in trouble again, but you know, I'm beyond caring. Personally, it doesn't work very well for me. I find it very hard to arrange. Getting all the stakeholders in the room for a week is pretty hard. Unless a mature organization with quite a well-established culture of UX, it's really hard to do, which is why Google can do it because they do have that.

[00:15:14]
But if your organization doesn't, you're gonna probably struggle. I also just find it exhausting, perhaps, I'm just old. I don't know, you're young and you're nodding that makes me feel better. So it's really intense, both for you, the person running it and also for attendees. So I'm not a fan of it from that point of view and also it just feels rushed, right?

[00:15:40]
Design sprints leave little room to really consider what you're doing. And in some ways I can understand that cuz it builds momentum and momentum's good and all of that. But if it leaves those stakeholders feeling rushed, they're more likely to push back later. So it's not a massive win in my point of view, I'd prefer just to spend an hour and a half doing some initial sketches and then kind of communicate with them on an ongoing basis, rather than suck a week of their time down, yeah.

[00:16:12]
>> And also it's very expensive?
>> Yeah [LAUGH] I've got nothing to add to that. Yes, it is.