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.