Building a prototype is a great way to get feedback on a feature without dealing with the red tape that comes with engineering. As an engineer, you might be tasked with building a prototype and become instantly wary: every ‘prototype’ you’ve built before ended up in production and you’ve been suffering from the technical debt ever since, or it was too far removed from reality to truly answer any questions.
But prototyping is still valuable. Not only is it a useful tool to have on hand in product development, it’s also a great way to hone the craft of writing code outside the scope of engineering. So, how do you reap the benefits of prototyping without suffering from “prototypes last forever”? This talk will cover strategies to ensure your time is spent effectively, and how to communicate and present your work to stakeholders so everyone is on the same page.
The Art of the Prototype
Jessica Edwards: UX Developer – Canva
Jess is a creative technologist at Canva. She’s done prototyping in the context of a unicorn startup for the past couple of years and is going to share some learnings around being the bridge between design and engineering, and between design, engineering, and product and what prototyping means to all the stakeholders within a project.
Prototype definition: A first or preliminary version of a device or vehicle from which other forms are developed. This definition has been appropriated from the hardware world and is loaded. The word prototype has different meanings to engineers, designers, and product owners. Without a shared understanding, issues can arise.
So you want to ask at the outset:
Related to these are: should we, can we, and how do we do this?
Concept of a Spike: A task aimed at answering a question or gathering information, rather than at producing a shippable product (term from Agile).
Engineers want to understand what is technically viable
Spike process example of Jess building out an ‘eyedropper’ tool at Canva. From an engineering perspective, this is technically complex, the shipping issues were technical rather than design based. They knew they wanted the tool, so ‘should we do this was not the core question, and the how we do this had to come after the technical exploration, because why waste designer’s time on something that’s not technically viable.
For this prototype, the why was: Is it technically viable? The who was engineers, managers, and designers, and the where in the life cycle was ‘as early as possible’.
Spike is the term that creates common understanding between engineers, owners and designers.
Breaking down the eyedropper spike for the can we build this, Jess could tick several yes boxes for what the tool could do, but it couldn’t do them at required speed, so on performance it was a no we can’t. So for this prototype, the spike was successful in that it answered the question even though they did not have the product they wanted.
Moving from the spike into the design phase. The standard definition of design: a plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is made.
In software, design becomes fuzzier – static design has been empowered by tools like Sketch, Figma, Framer, but engineers still have to build out prototypes with code to find out what’s actually realistic.
This led Jess to implement a ‘prototyping hour’ at Canva, where a tiny design problem is posed – for example a notification bell animation – and each engineer produces their own interpretation to the solution. The designer who posed the question is the end user of the prototype and they now have multiple perspectives to consider. So the conversation is about code, but geared toward the designer – this demonstrates how asking different questions around who you are building for can be a useful frame.
Example of an animation effects panel. Here, the designer had a good idea of what they wanted, but needed a clickable prototype to play with to hone in on details. Design tooling has yet to bridge the gap between interactivity vs static design, so they needed engineers to create a prototype for verification and feel into their proposed solution.
A similar example is found in a proposed audio trimming tool. Here the designer had ideas but didn’t really know what they wanted so there was much more room for exploration and iteration. The designer is making the decisions, but the engineers are building out options for them. So the project here is still very much rooted in the design phase.
As an engineer, Jess’s role is often to build tools that empower the designer. Many iterations are often involved which can lead to delays and miscommunications. The easier she can make it for designers the smoother the process.
This brings us to Specification: a detailed description of the design and materials used to make something. This is also part of the design phase but often a prototype that started out for the designer becomes a specification that is passed on to an engineer. This is where confusion can happen so questions matter.
Here the why of the build moves to ‘helping with the engineering hand-off’, the who expands from just designer to designers and engineers, and the where in the lifecycle is after design but before development. The relationship between engineer role and desginer’s scope needs to be explicated.
In this phase you’re still in the how do we do this? phase, but you’re refining the questions to adapt to the handoff between designer and engineer.
Example of a video player. Jess worked with a designer for the initial iterative process and from there came up with a set of written specification needs. You may not always need to be this detailed as the engineer will implicitly understand and work with certain elements of your design (e.g matching pixels, copy box shadow etc) but it can be useful.
An accidental example: Returning to the example of the clickable animation panel tool: Jess made this purely a tool for the designer to play with and as such many of the values didn’t make sense and animations were unpolished as during that phase they didn’t need to be, but when handed off to the engineer, they took the values as is and did not have enough information to proceed. Different users will have different sets of needs around the prototype.
There is a danger when taking the design used for the iteration process into the specification and handoff process as this point is ripe for miscommunication.
Here is where there is confusion over ‘is this just an idea?’ or ‘are these just guidelines?’ or is this actually a specification?
Final example: Storytelling: a narrative, either true or fictitious, in prose or verse, designed to interest, amuse, or instruct the hearer or reader. This idea can often be tough for engineers to get their heads around.
This falls in the realm of should we do this?and often represents throwaway code. Engineers have a visceral reaction to this as it feels useless.
Example – When Jess joined canva they didn’t have an app store or curve text. Curve text was becoming very popular so they used it in a prototype of their app store design because the app store could then enable the curve text.
The app store they now have does not have curve text so it seems like wasted time on the prototype, but the value lay in the process of thinking through and getting excited about what the app store could enable.
So in terms of the product lifecycle, it kicked off something that wasn’t there before. This is powerful and often overlooked. Just because the end product doesn’t reflect earlier prototypes does not mean you wasted time.
The storytelling aspect moves beyond should we do this? to how do we get people excited about this, how do we get buy in from others.
Example of talking presentations. A simple prototype that Jess made for Canva in a couple of hours was new and exciting enough to get others interested and drive the project forward. It planted a seed.
A common concern for engineers is how do I stop prototypes hitting production? They don’t want something in production before it’s properly tested.
Jess gave an internal presentation to Canva on this called How to build a prototype without someone telling you to ship it to production. and the engineers were very pleased because they often felt strong-armed into shipping something they weren’t confident in.
One solution is making the prototype so terrible that no one will want to ship it to production! This is a joke but has a kernel of truth.
One way of ‘making it terrible’ is that in practice, engineers often lie to stakeholders and say it’s not ready to ship because of x. X is made up but owners often will not understand that. This breeds distrust on both sides.
TL;DR – Communicate! Be upfront! Specifically around design. Ask questions upfront to clarify who, why and how you are building.
If your organization is large enough, have a dedicated person such as Jess’s role to drive this process. This signals to others that there are stopgaps in place before prototypes are shipped. It is still under the design umbrella and not at the build stage yet so engineers are ‘safe’.
Prototype the right things. A crucial part of the process asking these questions. Don’t waste everybody’s time. There are no hard and fast rules for design and often designers spend extended time on iterations which may be technically untenable. Engineers ask different questions which can make iterations redundant.
This is because the prototype itself is not necessarily the best way to answer these questions. IF the question is should we> then build a prototype. Or can we? do it with a spike, if it’s how do we?, prototyping may not be the best use of your time. Think through this.
Having a strong designer and engineer relationship is paramount. Smoothing out miscommunications often provides more answers than building a prototype, and improving design tooling to empower the designer can also be more useful than building a prototype.
Communicate with others. Prototyping is about understanding what your intent is and ensuring everyone else is on board. Thanks for listening!