Why prototyping is a must for designers
Have you ever set in a meeting trying in vain to describe exactly how you want a transition in your design to work? Or even worse, you were trying to use words in a document to describe how you want the navigation to fade in or out? I’m sure you have and you’ve probably seen the confused faces of your audience trying to work out what you are talking about and wished the ground would just swallow you up. Modern web and mobile app experiences are becoming highly immersive, thats no secret. Gone are the days of designing a series of linked webpages with full page reloads. Thoughtful animation and interaction design is key to defining amazing user experiences. Apple’s world famous design director Jony Ive has this to say about the modern day design process;
[the design process] is about designing and prototyping and making. When you separate those, I think the final result suffers.
Too often teams do seperate the two. Many screens will be created in high fidelity and “signed off”, before anyone even thinks about creating a prototype or getting it into the hands of customers. In modern day web and app design, you need to see and feel the interactions rendered by the software to know if you’ve nailed the experience, and so prototyping helps get you to that a lot earlier and faster in the development cycle. It also helps teams grok concepts much faster. Generally designers find it much easier to visualise abstract concepts, but not everyone in a modern software team can do this.
Prototyping benefits
Prototyping gives everyone in a team a single idea to work from and is a far more effective way to communicate a designer’s intent than a group of static screenshots. For example, a well crafted prototype can show an entire team exactly how an “on hover” state in a design should work, rather than leaving this open to interpretation by the rest of the team or just stuck in your head.
Most software teams work within an agile framework. But often designers may feel like they are still working in a waterfall style as teams they are asked to do a lot of upfront design as teams can struggle to get on the same page about a project. The agile manifesto promotes “working software over comprehensive documentation”. Prototypes are a natural extension to this, and reduce the need for documentation. So, a prototype can save a lot of time, wasted effort, and frustration during the development lifecycle as multi-disciplined teams will need to go back and forth far less to validate interactions and flows. Just like a picture paints a 1000 words, a prototype can paint a 1000 user stories. Watch as the quality of conversations around the interactions and designs increase as you integrate prototypes into your workflow.
The other beauty of a prototype is that you can see customers interact with your finished design, before you’ve written a single line of code. Conducting well structured user research using a prototype is extremely cheap and easy, even if you don’t have access to a full-time researcher. To conduct our user research at Atlassian, we set up our own usability testing lab (“AtLab”) in less than 24 hours and for under $200. We even created a simple step by step guide for how you can do it yourself. When you combine a well crafted prototype with simple-to-setup usability testing, you can save yourself a ton of wasted engineering hours building something that either customers do not want, or that has a poor user experience. Much better to find and fix these things early, than ship a poor experience to customers.
Level of fidelity is important
Now, the level of detail in a prototype can range depending on what you are trying to find out. There is no right or wrong answer to the level of detail you need to add to your prototype. You just need to pick the right tool at the right time in your process. A scrappy sketch can be far more effective than a highly polished visual mockup in the right circumstance. I’ve had amazing success in the past using crude paper prototypes, which literally are a group of hand drawn sketches that you manually swap in and out as a customer “clicks” links or images. But my main aim when using this level of fidelity was to quickly get some very early directional validation about an idea I was considering. Now if I had been about to ship that design to customers, it goes without saying that a paper prototype would have been the wrong level of fidelity for the job at hand.
There are various ways to prototype, with various levels of detail and what to use depends on where you are up to in your project.
Type of Prototype: Paper
Sketch out the screens you want to test. Put them in front of a customer and when they “tap” or “click” on the screen, swap out the screen for a new one manually.
Best for: Very early rough concept validation
Type of Prototype: Wireframe
Stitch together your wireframes with links that transition between each screen. Sketch will let you do this, or even keynote can be surprisingly effective.
Best for: Early validation of the information architecture, or common user journeys within a website or app.
Type of Prototype: Visual design
The same as previous but at a higher fidelity. If you are getting closer to
shipping your designs, you need to start getting much closer to the actual designs customers will see. Tools like InVision or Marvelapp are really easy to pickup and use, even for non designers. They will let you add a vast array of transitions and animations for web and mobile. Once again, keynote can also be surprisingly effective.
Best for: Getting concrete feedback on proposed finished designs from customers.
Type of Prototype: Code
If you can code, or are comfortable with tools like framer or principal you can create the real thing.
Best for: The real deal. If you can get quickly made prototypes in code, these are as close to the real experience that you will ever get.
So what would I do?
It always depends. You need to pick the right fidelity for the work at hand. But ideally I would have all of my team building prototypes in code, as these are always the closest thing to real life. Testing code prototypes early and often with customers allows us to iterate and refine our designs long before any production code is actually written. Once you build in prototypes to your design process, you get a better feel for whether you are solving problems in the right way for your business and most importantly your customers. You will also find it invites more constructive feedback from customers and internal teams, as it feels more real than a static mockup ever can. Refining the prototype multiple times you get to better, more elegant solutions, faster.
Regardless of the method you use, prototyping during any product
development lifecycle is now no longer just a nice to have, but a must in my
opinion. Aligning a multi-disciplined team and ensuring that everyone comes away with a completely clear picture of the intended interaction design is key to successful product development, and building experiences that customers will ultimately love.
Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.
