Prototyping; how to move from idea to reality. Harry’s talk at Bath Digital Festival 2020
To give you a very brief overview I’ll tell you who I am and why I’m talking today; I run Haio (now Unfold) which is a digital agency based in Bristol. We partner with startups, scale-ups and SMES and we help people take ideas right through to building and shipping products, generally these are MVPs and digital platforms.
Today we’re going to be talking about my favourite part of the whole product development process which is prototyping. Getting all those ideas and the madness that comes with them and channelling that into a real world product.
The plan of attack is this [on the slide]:
- What is a prototype and why should we use them (and why they’re so important in this process)
- Our 4 step process for successful prototyping, (the four levels of fidelity you have in a prototyping process)
- Thinking differently about prototyping. (how we can use prototyping in practise and stirring the pot so you have some things to think about after this talk)
It’s going to be fairly introductory level talk. We’re going to cover a lot of ground and touch on lots of different bits and hopefully I can signpost you to some further reading if you want to dive into a specific part of this talk. Or reach out to us and we’ll be more than happy to help.
What is a prototype?
This seems like a logical place to start. A prototype is an experimental model of a long-term vision or idea. It’s constantly being worked on, developed and tested.
So in that sense a digital product that a business is producing is always a prototype, because we’re always testing and developing our ideas around things. But as we can see on the screen it can mean lots of things and lots of different phases in a business, whether that’s a sketch (which is an equally valid prototype), or a digital mock-up or whether you’ve built the product and actively have a user base. We can consider all these things as being prototypes, it’s really about matching the stage we’re at as a business with the level of fidelity of the prototype that we want to use in order to progress.
So why should we use a prototype?
If you take anything away from today, it’s that prototypes allow us to learn and iterate faster. In the earlier stages if you’re talking about sketching and design mocks-ups they’re something you can tear down and build up again very quickly. And in a game where who learns fastest wins and with the least waste wins, prototypes are a huge asset for us when we’re considering how we’re going to get to that final product.
In the same vain that we can iterate faster, it helps us to avoid costly mistakes. One thing we have to avoid when developing products is spending too much time running in the wrong direction and reducing the time to learning and speeding up our ability to iterate our ideas. This means when we do spend our time building something we can be more confident from the start about how effective it’s going to be.
Thirdly and finally one of the most common pitfalls, is that we come to the table with a lot of preconceived ideas around what the solution is going to be. Whereas we should almost be working on the basis that our ideas are wrong. We use the prototype to go out into the market, go to users and let them guide the direction, let them decide what’s valuable about the product and what’s not. This actually takes a lot of pressure off you as the designer because it’s more about following the process, having faith in that and letting the user decide what goes into the prototypes.
With that in mind, what are the 4 stages of prototyping?
Thinking about this as a process; it something which can be scaled up or scaled down depending how much time and effort you have to put into this process. It can be very effective at solving very niche problems or much larger challenges, depending on how you want to approach it – and that really is the beauty of the process in terms of having that flexibility.
We’ve taken exercises from loads of places here, but if you’re looking for more resources we’re a huge fan of Sprint the Google Ventures design book, The Lean Startup and the IDO also have a fantastic set of resources surrounding human-centred design which I’d encourage you to have a look at. But we’ve pickled the gems and the bits which we really like to use and I’m going to talk through those today.
The first step is Sketching. (Even before this there are some exercises we can run through)
Before you come to this stage of the project you should already have a clear definition of the problem space that you’re trying to work in and the challenges you want to overcome.
This is the start of the “I’ve got a problem how do I get that down on paper” phase.
4 activities: it’s really important to know that these activities can be done as a team, we’d recommend between about 3-7 people. But they should be done alone within the team and not out loud – so the opposite of brain-stroming. You should have moments of quiet reflection and work and then sharing that with the team.
Brainstorming has been shown to be very poor for bringing about innovation and good ideas, because it’s subject to a whole world of bias, group thinking and the “loudest person wins” etc. so we try to avoid it where possible.
The first exercise which we like to do when we’re looking at getting an idea down into a prototype is called “How might we? (HMW?)”;
How might we? (HMW?) – this is really simple, you’re trying to reframe every problem that you have or you’re trying to solve and you write those down in the form of a “how might we” question. eg this could be something very small such as “we can’t get customers to sign up to our service.
The “how might we” could be: “How might we redesign the sign up page to help users sign up to our service.” So it frames the challenge in an opportunity for design, maybe somewhere specific, maybe somewhere a bit broader. There are lots of different ways to frame the question but it just starts to get the brain cells firing in terms of where should we be focusing effort? and where can we do that?
Get loads of sticky notes – it’s good fun (if you’re working remotely Miro is a great tool as well, as a virtual white board to use) – get these all up. And then voting on those afterwards as a team once people have had a chance to talk about those questions. Sharing them as a group, voting on them – this helps you pin down what’s most important to focus on. There are hundreds or thousands of problems we could all be trying to solve, but we need to focus in on the ones that bring the most value.
Remix and improve – this is about bringing ideas together to make new ones. A lot of innovation comes from smashing two existing ideas together and bringing out new innovation. What we do is get the team in the workshop to go away again and spend some time and research some different solutions, look at different industries and contexts.
Who has tried to solve similar problems before? What can we learn from them? Capture the ideas down in a quick sketch, give it a catchy title if you can and bring it back and present it to the team. At this point we’re still trying to just broaden our horizons and give ourselves loads of ideas about where potential good ideas might come from.
Crazy 8s – this is the most fun part! You fold up a piece of paper into 8 squares. You’ve got 8 minutes in total, with 60 seconds per square to draw an idea down. And this is where we start to feed in all the stuff we’ve talked about in step one and two – and you will have literally no time at all to try and process that into ideas. You will come up with a lot of really bad ideas but there will be a few little gems in there that will have been sparked from all the build up that can be really valuable to this process.
It’s really key that everyone draws – if you can’t sketch – it you’re listening to this thinking; “can’t draw” – it’s not about making them pretty, ugly is fine, it’s about getting ideas down on paper. I’m going to talk about why sketching is so important in a minute.
Sketch – this is the last exercise – sit down for 20/30 minutes and draw out solutions to the problems you’ve identified through the process. The only rules are that the sketch should be self explanatory, it should be anonymous and should use real copy (no placeholder text). There is a really good reason for this and is why sketching is so fundamentally important to this process before we get onto our computers and design software. Sketching introduces a much higher level of critical thought than discussing ideas. When we’re talking about ideas for features, products or services, we mask a huge amount of the complexity which sits behind these ideas and it’s very hard to see that until you have to actually commit it to paper. Sketching forces us to start thinking through the different implications and we have to start making design trade-offs as part of that process but it’s hugely valuable. And that’s why everyone has to do it, not just the designers.
Sketching is also a universal language, so it can’t be misinterpreted. When we talk in words you’re interpreting what I’m saying and you might interpret it differently to how I meant it. But when we sketch stuff it’s much harder for that misinterpretation to occur, and hence it’s super valuable
It’s never too early to get sketches in front of stakeholders – now we have something which is universally recognised and can be understood and we’re experiencing the same thing – let’s start getting feedback on it. Lets fail fast and find out what people think about what we’re doing before we expend any more effort.
The next step is to actually get onto the laptop. A few years ago I would have said to continue doing paper prototypes, you can create full prototypes on paper, but design software (prototyping software in particular) has come on so far in the last few years, with the likes of adobe XD, Sketch, Figma. We’re Adobe XD fans ourselves, it’s personal preference – but they’re so accessible (I think XD is actually a free Adobe product). You don’t need to be able to code, they’re a lot less daunting than things like Illustrator or Photoshop and you can move a lot quicker once you’ve got those initial ideas down into a low fidelity prototype.
So that’s what we would tend to do next which is; to get something like what you can see here [on the slide], I think this is an ecommerce store and go really low fidelity. And the aim here is to start testing functionality and start understanding how the prototype is going to fit together as a whole piece. Rather than just individual pages or an individual concept of how something might work. It starts to complete the picture in terms of functionality and then we can go out and test this with users and get feedback. And because it’s so rough and ready we can tear it down and we can build it back up again super fast.
After that we’d go for a digital prototype and this is where XD really comes into its own because you can add design (which is a very important aspect), but crucially also you can start wiring up the prototype. So you can actually completely mimic the experience of the real application that you’re building through the design software – so you still haven’t had to write any code at all! If you want to reorder stuff or change something, you can do that in minutes rather than days or weeks if it was actually a built prototype. Again, using this as an opportunity to go out and get user feedback and slowly, incrementally adding a layer of fidelity.
Once you’ve finally got there and you’ve done all the validation and you’re really confident in your ideas, it’s time to build an MVP. This is where you look to actually build something and get it out into the hands of users in an actual market environment.
The important thing recognise here, is that the process of prototyping and being really lean and working in short quick bursts doesn’t end. It’s tempting to spend a long time building lots of features, but the focus should still be on small deployable increments and trying to get out there really fast to start learning.
And that’s the other thing I would add about MVPS as well is that once you do launch a product, you should become absolutely fixated on the right metrics to be tracking and let that become your guiding star in terms of what you’re going to be changing and what you should be iterating on in the product. For example if you were an ecommerce store, there are huge amounts of metrics, is it; basket size, number of customers, is it repeat purchases? Work out what you need to do to reach the next milestone, whether that’s a fundraise, financial goals etc. Then become fixated and make sure every change you do is about improving one or two key metrics.
No matter what the stage, the principles remain the same;
Be very clear about who you’re designing the prototype for – there is no point creating a product which is ‘pretty good’ or sort of good or pretty good for lots of people, because then it’s not really perfect for anyone. Have a really clear picture of who you are designing the product for and allow that to be the guiding force behind decision making as well.
Make sure your product does one thing really well – you need to become known for doing something. It’s easy to make something complex very quickly – but it’s so much more valuable to do just one thing well – they’re much stickier and it’s a really good principle to take through your prototyping phase.
Like I say, you’ve got; build, measure, learn and that’s the iterative process which you should go through whether building is a sketch or actually coding a product. Use that to measure and learn something and feed it back into the process.
More ways to test your ideas and prototypes
Wizard of Oz MVP
Basically what you see on the face of it is not what is going on behind the workings. So if we’re creating design mock-ups, what other things can we do to make those feel more real for the customer when we’re testing them? to learn more at this stage. So if you think about if you were asked to prototype Siri or a voice software for example, you wouldn’t start by thinking about the AI tech and starting to build those algorithms. Actually we can just do that by creating a really crummy prototype in XD and then maybe someone sits in another room and manually types responses back to someone. We’re going to learn way more about how a user is going to interact with a service and what kind of questions they might ask. Which will form how we should then build the tech, so it’s very much user-led. But there are so many creative ways to do this and I encourage you to think of lots of different potential ones.
The landing page MVP
Putting a landing page up to see whether there is interest in your product or proposition before you’ve done it. A word of warning on this one though – I’m not a huge fan of it because it’s very hard to isolate the specific variables in the landing page which you’re testing. And you have to think about how much traffic or the amount of views you’re going to need to get on that landing page to get some kind of statistically significant judgement on it. So be very clear about what you need to learn and whether you can isolate that down to one specific learning.
We really like this one and you’re seeing a lot more of them – this is the idea we can use existing tools and solutions to mimic what our potential solution might look like in the future. There are great low and no code options like Airtable which offer fantastic opportunities (similar to the Wizard of Oz style), but it allows us to mimic services and learn from customers before we then go out into building something we can scale.
- Prototypes allow us to learn faster – hopefully you can see why this is so valuable
- Design is more powerful than words – sketch as early as possible in the process
- Match prototype fidelity to the stage of your idea (Sketch > Wireframe > Mock-up > MVP) – so if you’re a really young company or it’s a fresh idea, just start sketching stuff, don’t feel you need to dive into full mock ups. Equally if you’re a fully fledged business, don’t be afraid to go back to utilising sketching to get new ideas.
- Do one thing well for one user
- Get creative with how you test your prototypes – think about different ways to mimcik your service to learn before you invest in building.
- Further reading: Sprint, The Lean Startup, Design Kit from IDEO
Q1: If you show sketches to potential stakeholders, do they struggle to get the vision?
A: Sometimes, yes. One of the key principles of the sketch is that it should be anonymous and self explanatory. You can create a sketch but it’s really helpful to annotate it with words, (doesn’t have to be totally self isolated in terms of a sketch of a wireframe or whatever it is), but they should be understandable. The idea is that if you’ve got 5 people doing that exercise you can put them up on the wall and people can wander around and get the picture out of them. So it is difficult to get that explanation across, but if you’re explaining it to a stakeholder and you’re in that scenario, let them initially interpret it and ask them how they interpret it because it’s really important, but then you can add context later. So you can then explain through if you felt the sketch as lacking in details.
Q2: With such a lean process, how do you incorporate accessibility?
A: Good question. There are lots of core practices you can do at the UI design step so the digital prototyping phase, where you can do some really quick wins for accessibility. Things like making sure text size is big enough, colour contrast ratios is another great quick win – make sure you test all your designs and buttons for that kind of thing. When we build products (I know that’s slightly different to prototyping) if you’re using good clean markup so that screen readers can access the content as well, that’s really important and you can also try and test that with a broad range of users to make sure it works for accessibility. So yes it’s something you have to find time for and is very important.
Reach out on Twitter and we’ll be happy to answer any questions!