The Art of the Prototype

Jessica Edwards–The Art of the Prototype
(upbeat music) - The Art of the Prototype.
So context, I'm Jess and I've been doing prototyping at Canva for a couple years now, and my role is a creative technologist.
What does this actually mean for you guys? So I've been doing prototyping in the context of a unicorn startup for a couple of years now. And so there's obviously some learnings that don't necessarily apply to everyone, but I was hoping that I can share some of my knowledge of prototyping and sorta being that bridge between design and engineering and furthermore, design, engineering, and product, and teach you guys about what it actually means. What prototyping actually means to all the different stakeholders within the project. So to begin with a prototype is, we've borrowed this term from hardware development where it's quite obvious what a prototype actually is. So, a first or preliminary version of a device or vehicle from which other forms are developed. So in hardware, that's quite you have this understanding of what a prototype is, right? It's like this early, early version of hardware. And so we've appropriated that for product design and development but it's actually quite an overloaded term. Because what is a prototype to me as an engineer is quite different to you as a designer or you as a product owner.
And people when we don't share the same understanding then that's where issues can arise.
So some of the questions that you would wanna ask with your prototype to determine like, what we actually wanna achieve with this is like, first off, why are we building this? It's very broad.
So we'll go into some examples of answers to that question. And so like, who are we building this for? So, and I'm not talking about the actual feature, like the end feature.
That's a separate concern is like actually, who is the prototype for? So it could be a designer, it could be an engineer, could be a decision maker of some sort.
And so we might wanna try and answer questions. That's what's where the, why are we building this? That's like so for your end-user, the people paying you money.
But who are we building this prototype for? That's a very important consideration as well. And last time it was like, where does this actually sit in the product development life cycle? So it could be quite early on.
It could be just before engineering.
Probably not after.
I can safely say there's probably not after you've built it, but it's yeah.
So it varies between that.
And so we wanna like figure out what actually with these questions in mind we can actually figure out what we're trying to achieve. And so there's a few of these three main questions that I think we want to answer with that prototype. So should we do this is? Is it even worth pursuing this? Can we do this? So this is a true or false, yes or no.
It's the most well-defined these questions and so this might be say a spike for example like, is this actually even possible? Unless is how do we do this? So this is where you might need to iterate. And this is like design, mostly like design is a sorta concerned a lot with like, how do we actually get the best results for our end users? What does this look like? How can we do this nicely basically? So we think about a spike.
So that's quite, it's a task aimed at answering a question or gathering information.
So that means it's like quite early on.
It's like a time from agile, but it's a time that engineers.
And I think we mostly sorta understand quite well. Is that like, as an engineer, I just wanna find out what's technically viable. And so we think about, so here's an example of one of my earliest spikes at Canva.
Is like actually building out what we call an eyedropper and for engineering reasons this is technically a kind of complex, but the issue with actually shipping this was a technical constraint.
We knew already that we wanted an eyedropper. It's not, should we do this? And the how we do this would have to come after the technical exploration ,right? That's because we don't actually wanna put in too much effort upfront for something that's just not technically viable.
But we still know that we actually do really want this feature. That's quite obvious.
So why aren't we building this? It's again to something that's technically viable. Who we building this for? So it was just mostly everyone, like your product managers is probably like the most important.
There'll be the most concerned about this.
But designers as well, this is an important step in the design phase. And that has to, you don't want as a designer to put in too much effort and then find out Oh, I can't, this doesn't actually work the way I intended. So a lot of the designers work as in sorta just thrown away because the technical limitations weren't clear to them upfront.
And for engineers as well, it's mostly just give them an idea of like what ahead if this is okay to go with.
And so again with the product development life cycle, it's as early as possible.
So let's, I think spike we want to spend too much on spike time on spike because I think that's the time that we all sorta understand together engineers, product owners and designers.
Can we do this? Yes or no? So we think about the Canvas.
You might wanna break it down into a few different questions but at the end of the day it's like, can we build an eyedropper? And so there's a few different questions.
So, and I was able to answer say, can we grab a colour from a plain design tick? Can we grab a colour with design with images tick? A brand tick, but could we do that with performance? Like with performance in mind? It was just too slow.
So we couldn't actually ship it.
So in terms of the prototype, it was a spike that was successful in that we answered the question but not we didn't actually get the result that we wanted. That's so means it's a successful prototype but it was just unfortunate that we couldn't go further along with that. Now, once you we've got a spike done you want like design will need to start.
And so it's design is quite obvious.
It's a plan or drawing So produced to show the look and function of workings of a building, a garment or other object before it's made.
And in software, I think the lines become a bit blurry because a static design with.
So we have our static designs but then there's tooling such as Figma and Sketch and Framer that has really empowered designers to take their own design bringing their own designs to life.
But there's still a big part of building out a prototype as an engineer with codes to actually understand design a bit closer to reality rather than just purely static.
So one of the things I introduced at Canva is the prototyping hour.
And so this is just an hour where we have a tiny design problem.
And this case for example, we had, we want a notification.
We want notification animation for people.
And so each engineer that participated produced their own understand like their own interpretation and answer to the solution. And then the designer who really wanted to answer this question had a few different things that they could play around with.
But the result is so it's code but with a primarily a designer is the end user of a prototype.
And it's purely for designers.
It's you don't wanna get your PM's involved or engineers involved at this stage. Because generally asking different questions involving different people.
You should already know that you want to build this.
Like you're answering a question exists.
Yeah, it's yes.
And it's could be various stages throughout the design phase.
So how do we do this? We want how do we tell users that they have a notification. And within that, there might be separate questions but that's the broad question that the designer is trying to answer.
And what the prototypes trying to answer.
Another example is here is I've got an animation panel.
And so this was just the designer already had a really good idea of what they wanted but they really needed to play around and feel, feel around with the prototype to actually make a good decision, yeah.
So the broad question was, how do we give an indication of animation before applying it? And the designer already had their own solution. This was their idea but they couldn't actually verify without actually playing around with feeling it. And design tooling it's just, it's getting them, but still not quite they still haven't bridged that gap between a lot of the interactivity purposes versus aesthetics, yeah. Same with us, we've got an audio trimming, for example.
And this was purely, so this was quite more complex in that a designer actually didn't really know what they wanted in terms of like, actually moving around audio.
Like they had some ideas but they weren't actually that certain.
And there was a lot of like room for exploration. And so there's a lot of iteration that needed to happen.
But again the design was sorta leading this process like so I was just sorta helping as an engineer to build out a solution.
But again, the designer is making those decisions. It's still very much a design phase thing.
So how do we visualise editing audio? How do we provide high accuracy editing without overwhelming users? And those are the questions that we wanted to answer. Finally, there's a as an audio.
So we're having an audio player here.
And to sorta really own it on the fact that it is part of the design phase, I've often built tools that as an engineer, I can help empower the designer to make those design decisions.
It can be quite frustrating when there's a lot of iteration that happens just because that iteration is between two different people because things can get lost in communication or like misunderstandings.
And basically it can sorta prolong the process. So this is a way of sorta really giving sorta earning out on the fact that design is really drive this process.
And at the end of the day, we wanna make them help make it easier for them to make those decisions.
No, specification is often, it's part of the design process as well.
And often you'll find that a prototype that started out purely for the designer then becomes a specification that's then handed off to an engineer.
And I think this is the one way the lines get blurred and becomes quite confusing both for engineers and designers because they're not speaking the same language. So if we're thinking about like so a prototype that's purely for design and our end user isn't a designer. We're thinking about we just they'd explore options.
This isn't necessarily like an engineer doesn't necessarily need to give feedback on it. It's purely a as a designer, do I think this is a good experience or not? But then once we have that handoff, some things need to be made to look clearer. Engineer might not want to fill in the gaps or like give an idea about if you're given a design they don't wanna sorta have to fill in too many gaps themselves.
Whereas the designer for them, they can see the whole picture in their designs, but once that skin handed off to an engineer they've misinterpreted it or actually they might need to go back and forth and sorta figure out some details, yeah.
But at the end of the day, it is that engineering and designing relationship that we're focusing on.
It is still answering that question of how do we do this? But it's just really sorta refining those questions and sorta saying we instead of trying to find the answer, of how do we do this? We've already answered the question.
And it's really selling for handoff.
So here's like an example.
So I was working with video and so video is very hard to design statically. So I worked with a designer so that help create all these different.
Think of video and use video in a sorta more realistic environment compared to say Figma or Sketch.
And this is like that early phase in the design phase. There's a lot of iteration.
But then at the end of it, we come up with an actual specification and not every prototype need this not every design needs this but it's actually a really breaking things down. And it design could be a specification without writing things out explicitly because your engineer's probably going to, you know inspect your design and then copy the corner radius copy the box shadow that you've provided.
There's an implicit specification there.
They'll match up pixels as they see fit.
And then say, for example so this was the animation panel that I showed earlier and this was purely used in the design phase. And then it was handed off to an engineer.
Whereas an issue came about was because I had purely designed this purely made this for the designer.
And so a lot of the values actually didn't make sense. And so the engineer had taken this and implemented as his even though the animations themselves they weren't polished, they weren't correct, the timing was a bit off but for the designers purpose, they were like, Oh yeah, like that seems like the right direction.
I have enough info.
Whereas for the engineer they didn't have enough info based on this. So there's a danger of taking that design all the way through the early stages of the design iteration process to the handoff and specification process.
You have to really, this is where issues arise is that there's this miscommunication of like, is this just an idea? Or are these just guidelines? Or is this actually a specification? And the last one for a prototype that coming from an engineering background, I found the most difficult to get my head around is the idea of storytelling.
So really just a narrative.
This is throw away code at the end of the day. And it's really just it's really answering this question of should we do this? And yeah, as an engineer like this is you get a visceral reaction to like this, the idea of throw away code.
'Cause it feels quite useless in terms of that, I'll show you an example. So when I first joined.
So at Canva, we didn't have an App Store when I joined. And we didn't have curve text and curve text is sorta like this big, like yes, must have feature right.
But for engineering purposes quite difficult. And then the App Store was just an idea, right? And so built this prototype of like, what could an App Store look like? And it used curve texts because everyone wanted curved texts.
And I do have that, Hey, an App Store could enable this feature. It got people really excited about the idea. And now we do have an App Store within Canva, like our own developed platform.
And it doesn't look anything like this.
You can't use curved texts.
And so from that point of view, it does feel quite useless but it actually really got people excited about this idea. It really drove home the point of like, what could an App Store enable? So, and yeah, as an engineer that like it just felt useless that, Oh, no one actually built this but in terms of the product life cycle, it actually kicked off something that wasn't there before which I think is a really powerful and something that's often ignored and sorta like these prototypes is like it. Yeah, hanging on the point that just because your end product didn't look like whatever you started off with, it doesn't mean that that was a waste of time. So really driving in this, like, not even should we do this you might think like, maybe you're trying to convince others that you should do this.
Yeah, it's really yeah.
About excitement and yeah, that's what a story is. It's like, it needs to be interesting and it doesn't answer the like, how do you do this? Or how should we just purely excitement? How do you get people on board? And so the last example is a talk.
And so I initially built in this talking presentations. So you can now record in Campbell, nothing that, and I made this sorta within a couple of hours and people really came on board with the idea of like this new feature. Like, what could we open the possibilities with? And it doesn't really look like this, but it was interesting enough that people got really excited about it.
And that really drove the project forward much quicker than any specification or design could. So in terms of like, so how do you stop a prototype from hitting production? That's a common question from engineers is I don't want to build a prototype because I'll have to maintain it.
It'll end up sorta in production where it's not been thoroughly tested. And yeah.
And so when I gave a similar presentation to this one within Canva and I called it how to build your prototype without someone telling you to ship it to production. And the engineers were very happy about it because that they are often found in this position where they've somehow been strong armed into shipping something that they are not confident in. So I was jokingly saying, I was just make it so terrible that no one will actually want to ship it to production. And that's actually kind of accurate is that. So there's a few different approaches.
So if you make it terrible, you can say, what happens is engineers often they will lie to stakeholders and say, Oh, we can't ship this because of X and X is just something that's made up.
And they know that a product owner will not push them on it.
And it's an unfortunate reaction.
It's from engineers that often like find themselves burned by previous experiences of ending up with prototypes and production. But then you have like this sorta war that's waging between the two, between your product owners and your engineers. And you don't want distrust there.
I think that's important to note.
I think being upfront is obviously like the tail dears communicate obviously with everything, but specifically with design.
And building these prototypes is be clear about once you're actually building and that's done by Frank asking these questions upfront like, who is this for? Why are we doing this? What kind of prototype is it? Is it a spike? An engineer might think they're building doing a spike but for a product owner, it was an MBP, yeah. And say, if your organisation is large enough, say you could have a dedicated person such as myself is that it then is a signal to others that like Hey, if the creative technologist is building this then therefore it can't be pushed to production. That's just like a big signal.
Is that like your engineer isn't building it. It's a person under the design like umbrella. Last is prototyping the right things.
It's a crucial part of this is, if you have to ask these questions of like, why should we, if a prototype might not actually be the best use of everyone's time, a little bit of the design, part of the design phases, it can sorta really blow out because there's no really like hard and fast rules. The issue there is that as a designer can really feel the need to like continuously iterate before they even hit engineering.
And then once the design actually does end up in an engineer's hand and have to build it, something else comes up. And so then, a lot of the prototyping that you've done actually doesn't make any sense.
Like it answers different questions to the ones that arise in engineering.
And so then the iteration has to continue.
And so that's an issue that comes about because the prototype is not necessarily the best way to answer those questions.
So if the question is, should we do this? I think you definitely should build a prototype sorta, can we do this? Definitely with the spike, but if it's how do we do this? If you already know that you want to build a feature, prototyping is maybe not the best use of your time. An engineer could probably get started building it right away because you do know that you want to ship it. It's just that how question flows out.
And so that's best served, I believe, with a strong engineering design, sorta relationship.
But having someone there such as myself, sorta to help smooth out miscommunications that could be the answer that you're looking for, or maybe it's improving design tooling sorta to get a designer sorta, to like, be confident in their decisions.
So they don't need a prototype.
So, conclusion, communicate with others.
That's the best way to approach this.
Prototyping is all about understanding what your intent is and making sure everyone else is onboard.
So that's me.
Thanks for listening.
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!