Prototyping and Scenario-Based Design – Designer vs. Developer #16

Prototyping and Scenario-Based Design – Designer vs. Developer #16


MUSTAFA: Someone’s
buying a coffee, like them searching online then
from walking down the street. So then you’re
actually understanding the complete experience rather
than just the visual UI. BRENDAN KEARNS: The faster
you can come up with them and throw them away, fine. That’s just the
investment in time that you do as a designer
to get to a solution. [MUSIC PLAYING] MUSTAFA: When someone’s
prototyping something as a designer, what you end
up showing to the developer is not the final thing
but an approximation. How do you feel about the state
of prototyping tools and just the process in general? Because it feels a
bit like a throwaway. You put all the energy and
heart into something which is never going to be used. BRENDAN KEARNS: There’s
probably two different schools of thought. One is you use a prototyping
tool to show intent. This is where we can go, what we
want to do, how it might work. Whereas the other one is
we use a prototyping tool to inform a developer about
something specifically, or here’s the exact
mechanism and parameters and all the redlining
that comes with it or the lack of redlining. In terms of an opinion,
I think the only thing I really care about is the
speed in which you can create a prototype, how you can show
that intent, show a vision, and it’ll show an
iteration on a feature or create something entirely
new with minimal cost. And that’s the best
thing that comes with it. And the evolution of tools
from static images or sketches on a wall or just
pointing at something and saying, I want
it to be like this, to clickable prototypes,
to something that feels alive and has
full-flowing motion and you could almost
test it with a user and have them think that– or
at least their mental model would be this is something real. I can give you real feedback– is fantastic. But I think the problems that
come from that can be you can let teams or organizations
think that you’re much further ahead than you actually are. And then there’s a whole
lot of engineering, both reviews on the
prototypes you’re making, but then implementation
work, setting themselves up in the right way,
having feedback on those prototypes that you’re
making so you’re not creating any unnecessary
debts or complications down the track. MUSTAFA: So give
examples of like where prototyping tools have been
used for the worst possible. And what’s the
best-case scenario? BRENDAN KEARNS: I think
the best one I’ve ever seen was a guy who applied to a
job using InVision while I was working at InVision. He used it because
A, he didn’t know how to build front-end at speed
that he was comfortable with. And B, he could test different
versions with different people and see what his
response rates were like. Sometimes, people were even
leaving public comments on his prototype and letting
him iterate on his case studies. It wasn’t accessible. It wasn’t responsive. It was just a static image. But it was enough for me to
go, that’s an interesting way that he’s taken a
prototyping principle and an iterative approach to
how he’s going to get a job, how he’s going to
communicate his own value. It was pretty cool. MUSTAFA: Do you
build up prototypes, or have you built prototypes,
specifically for the engineers? Because that’s more from
the user testing side. BRENDAN KEARNS: Yeah. I think– MUSTAFA: Or does
the thing change? Because again, I suppose
it’s like intent. BRENDAN KEARNS: I think it
can change purpose over time. You can end up using– to your point about
throwaway prototypes, the faster you can come up with
them and throw them away, fine. That’s just the
investment in time that you do as a designer
to get to a solution. Setting up an engineering
team or pairing with them to kind of hand something
off or start developing it can be something different. That’s why I think specs and
guidelines are a lot more– and principles
are a lot stronger when you can inform the
developer on, like, some of the variables that
they need to stick to or you want them to stick to. But then you show
them a user’s walk through time with a prototype
so they go, all right, I can absorb that,
build something with the technology we
have, invent what I need to, augment what we don’t have
or do have at the moment, and then stick to a set
of principles, variables, guidelines, overall narrative. MUSTAFA: When I came across
the idea of redlining, that seemed such a really alien
thing, where you’re designing your sketch file or whatever. And then you say, OK, this
is going to be from this four pixels to four pixels. It’s a very prescriptive way
and conveyor-belt way of design. I mean, do you find
that to be the case? Or is that maybe me
thinking of an extreme? BRENDAN KEARNS: I
think a few years ago, it was still definitely
something that happened. But now it’s probably a symptom
of something much deeper, which is that your design
and, I don’t know, development or delivery
teams are speaking two different languages entirely. And the only thing
that they can use to translate intent or a vision
into something that’s real is a source of truth that
no one can disagree with. And no one can disagree with
four pixels versus five pixels versus 100 pixels. I don’t think it’s
something that’s really necessary these
days unless you’re getting into something that’s reusable. So you can do a redline for
a component that’s being reused all over the world. But a redline for a specific
instance of something and how it relates to
another component on the page is probably
something that’s just a little bit too rigid I think. MUSTAFA: Yeah,
because, I mean, it’s like we’re talking about
the responsive web, and things can change. Screen sizes can change. Sometimes a site or browser may
not load the thing properly. It just seems such a– it misses the point
of, like, you’re trying to help a user get from A to B. BRENDAN KEARNS: If you’re
obsessing over redlines, you’re probably throwing
something over the fence. I think back to my agency days,
where you would sometimes even give it to an engineer that
was two seats away from you. But their workflow was
so different than yours, and you would move on
to another project, that you had to give them that
source of truth or a reference. So by the time it went round a– or went through a
round of revisions, it would come back to you. And you’d say, yeah, that’s
close to what the spec was. Therefore, I’m
comfortable with it. So you would give
or take a percentage as you do on the web when
things scale and move, degrade, speeds, variable,
things like that. But I don’t know. In product teams these
days, if you’re not designing the future state
of something that you own and looking at its
current state and going, that’s not quite right,
that doesn’t match the original intent,
and saying, can we just nudge this component
here or change this variable, it probably means you’re
not holding onto two tracks at the same time, which
is a little bit naive. MUSTAFA: I mean, I
see, like, AirBnB have got an interesting
approach, where they will– their code represents
the components. So then– MUSTAFA: Is that the
React to Sketch thing? MUSTAFA: Yeah. That seems like a very
interesting approach. I mean, have you
ever worked in teams that do that kind
of very close, where they’re not like for like. But there’s like something
in the middle that translates that they both– that fits neatly
into both workflows. So Figma is one tool as well. BRENDAN KEARNS: Or they just
come out with their APIs. MUSTAFA: Yeah. BRENDAN KEARNS: I think
the closest we’ve had was working with a
design ops team that sat within a product team
but had front-end engineers. So they kind of informed the
product designers and design leadership what variables
we should be playing with by living in two worlds. They would tool you properly,
and they would also make sure that they were drawing from
or pushing those variables in the actual product itself
in all the experiences you’re building. In terms of the
best alternative is every designer can build
everything that they make. I know booking.com does that. A lot of their UX designers have
to build front-end HTML, CSS, and JavaScript as a prototype. So you don’t really
work in static images unless it’s just quick,
divergent thinking. MUSTAFA: Yeah, so you’re just
trying to come up with the idea first without having to try
and design in the browser. BRENDAN KEARNS: Exactly. MUSTAFA: So I remember
you once mentioning scenario-based design. BRENDAN KEARNS:
So traditionally, and still to these days,
you get these requests, which is, we have
problem X. I need you to solve it in these
screens or this single surface. And then you can
go and fix that. And you normally
think about what’s happening before, what’s
happening afterwards, what variables are at play. But scenario basis,
and particularly if you’re inventing
something new or you’re going to change
something radically or push it in a slightly
different direction, is almost like a user journey,
but less static and kind of step-based is you’ll try and
prototype a walk-through time. So you find out and
get to experience what’s happening before a task
is started, how it articulates and is built and experienced,
then what happens afterwards. And a scenario can be
something like buying a car or renting a car or dealing
with a car accident, dealing with an insurance claim. That could be something
that’s much more specific. And the insurance claim– I’ll take an example. That would be a scenario as
a designer at an insurance company might take
versus I’m going to redesign the claim form. And it lets you have a lot
more different perspect– a lot of different perspectives
other than maybe just the leadership
you’re dealing with or the person who’s incentivized
to get less successful claims, more successful claims,
this kind of information. So you can start to
balance that and really be that kind of
stretch-armed person that lives in a few
different worlds but has the
perspective of the user because you’re framing that
argument rather than putting really subjective opinions on
a particular field, screen, or widget, whatever it is. MUSTAFA: So you’re looking
at the context, like, from start to
finish rather than, like you said, designing
an individual– BRENDAN KEARNS: Even
if it’s hypothetical. And you could even go and
validate that scenario. Or the scenario
could be generated from insider research
that you’ve got or data that you’ve got. It’s not hard these days
to visualize a user’s walk through a product or a site. So you can, if you’re going
to make a change to that, run a scenario that would take
that same path or a slightly different one that you’re
trying to make and just see how it feels,
see how it works, test that, see how
it lands internally, see if it’s going to screw
up anyone else’s metrics. And if it is, is that OK? You’re going to create
incentives somewhere else. MUSTAFA: Yeah, and I think
during design sprints, they call it user journey
mapping, where you actually look at the entire step. So someone’s buying a coffee,
like them searching online, then, from walking
down the street. So then you’re
actually understanding the complete experience rather
than just the visual UI. So how can people
really start thinking more about scenario-based design
rather than very specific-based design? I don’t know if
there’s an equivalent or an opposite of that. BRENDAN KEARNS: I
think if you get– and you think about
this every day. You get requests from people. They come to you with a problem. It’s just taking one level up. And that’s it. Just think about the problem
itself that you’re getting and the person who
might be doing it. And then all you have to
do is walk that person through that experience. There’s no hard and fast rule. As long as it’s linear, as long
as someone goes from X to Y, and something
happens in between, that’s a scenario
that you can sell. It also lets you cover
all possible use cases, even if they’re
hypothetical, by coming up with multiple scenarios
in which someone might use this particular
tool or service or product. I’ve found that it’s a lot
more exhaustive than you think it is. And it lets people debate the
merits of the scenarios you’re trying to design for rather
than a specific instance or a screen. Because you can win
that argument, and then lose the entire
experience argument, and you’ve done a crappy job. MUSTAFA: Most of that is
actually processed by the brain and interpreted
based on experience, previous knowledge, and so on. So what we are
seeing isn’t really what the eye’s perceiving. And so it’s very important
to design, again, with intent for those things.


5 thoughts on “Prototyping and Scenario-Based Design – Designer vs. Developer #16

  1. Thanks to Brendan for appearing in this episode, if you have any questions about prototyping be sure to ask them here. Enjoy!

  2. This video makes a lot of sense when design systems are being adopted. I feel that this subject, which is a fairly new for me, is coming up more frequently.

Leave a Reply

Your email address will not be published. Required fields are marked *