The fundamentals of prototyping

The world of UX is fast-moving. Methods constantly evolve, thinking changes and approaches are adapted at an incredible rate. The design community is constantly innovating, especially around the way to approach creating prototypes.

It can be difficult to keep up to speed with various aspects, and it’s probably pretty confusing if you aren’t from a digital or user experience background.

At Freestyle, we use prototyping on the vast majority of projects now both large and small, and it’s something that we encourage clients to embrace as the benefits are huge. It’s obvious when talking to existing clients or prospects that there is still quite a lot of confusion about exactly what prototyping means and ultimately why they should pay for it.

What is a prototype?

With regards to digital products, a prototype is essentially a clickable or interactive journey of a proposed process. Depending on the industry you work in, you might have encountered, had exposure to or helped build a prototype in some manner already, or maybe just heard colleagues talk about the need for prototyping when a project is being proposed.

Prototyping can take a few different forms and can be used in different contexts/frameworks but whatever method you or your team choose to use and the reasons for it, in each instance it’ll allow you to create a version, simulation or demo of a website, digital product, service or experience that helps you to explore, iterate and test your theories or assumptions before the final product is built or a single line of code written.

The level of complexity or fidelity you go to always depends on the project requirements, but the theory remains the same. 

Why do we need them?

Too often, companies invest in exciting new ideas, brainstorm, build out solutions and implement them —only to then realise, after launch, that the brilliant idea doesn’t actually solve customers’ problems, or in some circumstances even creates new problems.

Prototyping helps prevent this from happening as we have the opportunity to test these initial assumptions, iterate them and explore the best possible solutions. To quote Frank Lloyd Wright "You can use an eraser on the drafting table, or a sledgehammer on the construction site.” 

It’s pretty obvious to say, but one of the biggest advantages of creating a prototype (whatever it’s scale), is that it’ll save you or your company time and money by ensuring that development of the final product is based on a process of thought, input from users, data and findings from the outset - rather than untested assumptions that you, your team or client may have had beforehand. 

Secondly, speaking as a designer, working through an entire process of mapping out screens or interactions is much more beneficial in terms of flow, layout, process and user experience. When prototyping, you have to consider much more than when working on static layouts, where these small important details might get missed or are not obvious. Dev teams also get a much closer idea of the desired outcome and can use a prototype as a reference or tool to better understand required functionality, interactions and transitions.

Lastly and probably most importantly, you’ll get much more traction when reviewing your work with project stakeholders or clients with a clickable/interactive solution rather than static concepts. It’ll give a much better indication of your thinking, allowing those involved to understand your process and reasoning.

You may need to build out an entire web experience or app, some complex functionality or simply the best way to create a sign-up form - whatever it is, it nearly always makes sense to spend the time to prototype and iterate the best possible solution.

Everyone (myself included) has been guilty at some point of having pre-formed assumptions on how a solution should be approached or designed. This is especially true at project kick-off meeting where more often than not, there is somebody in the room who believes that they know exactly what is required before the project has started.

As I’m sure you’ll appreciate, designing, building and launching something and then having to make changes soon afterwards because it’s not working as required or has low user engagement is obviously not ideal in any scenario. Having the opportunity to mitigate that is extremely valuable and is largely why prototyping has become less of a ’nice to have’ and more necessity.

Knowledge is king, data invaluable.

So, what should a prototype be based upon? Where do the ideas come from and how do you implement them into something feasible?

Before you can think about starting to formulate a solution, you need to gather as much information as possible around the problem(s) at hand. The best way to do this is to talk to as many people as possible, review what any data is telling you and research the market.

I won’t go into too much detail here because this really is an entire process in itself which could easily warrant another article. But in an ideal scenario, you’ll have the opportunity to conduct interviews with existing users, speak with customers and any company stakeholders to better understand exiting problems, frustration and any suggestions they may have, in order to make improvements.

This kind of first-hand insight is incredibly valuable because by speaking to people directly you’ll nearly always get some insightful nuggets of information that may not be obvious to you or the team. These are the people with an intimate knowledge of the company and market positioning, they may use the existing product every day (if there is one) and understand what competitors are doing.

Secondly, being able to review existing data to get an overall picture of existing problems, drop-offs and bounce rates is a fantastic way of shaping potential solutions both large and small. Review and use data whenever possible as it’ll help inform your thinking massively.

Lastly, conducting research. Looking at competitors is an obvious thing to do, but how are different industries and sectors approaching similar issues? Is there an interesting way of navigating or arranging content that you hadn’t considered?

Only once all of this information is known, collated and understood can a UX team begin to start the process of generating initial approaches and ideas in an accurate way.

How and what?

Whenever we’ve discussed the subject in our studio it’s very clear that members of the team are a little bit confused about how we should talk about, describe and sell prototyping to our clients as a service, or what the best solution is in each circumstance.

The reason for that is that there are no rules about how to approach or produce a prototype, and it’s nearly always down to the UX designer or team you work with on the best way to solve, build and present the correct solution.

Next time…

So, what forms can a prototype take and what is the best way to produce them? How should they be visualised? In the follow-up to this, I’ll be talking specifics - different software, prototype fidelity and how prototyping fits into frameworks like design sprints.

Keep your eyes peeled for part 2! 

✌