Designing for Great Performance — Designer vs. Developer #9

Designing for Great Performance — Designer vs. Developer #9

[MUSIC PLAYING] MUSTAFA: How do you think
we could get to a place where we can design
with performance in mind rather than it being
an afterthought? ADDY: Shipping a user experience
that is performant on mobile is sort of this symphony
between designers and developers where I think we both have
to understand the limitations of what’s possible. If you’re shipping down
an experience on 3G or 4G, you’re probably trying
to get something that is useful to the user
as quickly as possible. Giving someone a shopping page
where they can see an item, but if they keep hitting
that button to buy, and they can’t
really do anything, that’s probably not what
you want because it’s going to cost you a sale, right? And when we’re trying to ship
these experiences in mind, I think we need to
think about what is the minimal set
of things that I want to get down the wire. What does that mean for the
design of that experience? Does it mean that
I ship something that’s a little bit more
lightweight, a little bit less splashy but is minimal
enough for the user to get maximum benefit from? And if I do want to integrate
other design elements into there, how can
I do that in a way where we can keep loading
performance in mind? It’s completely possible. You look at a lot
of the mobile web experiences, the
Progressive Web Apps that large companies have
been shipping lately, the Twitter Lites, the
Housing.coms, the Flipkarts. And many of those
experiences have thought about performance
kind of holistically. When you land on a landing
page for any of those sites, they load up relatively quickly. They look really beautiful. But then, as you
need to transition from one view to another,
showing in some cases very different experiences. You need to think
about, well, how can I do that in a way where I
can make it look pretty, I can optimize for
perceived performance, and I can give
the user something useful at the same time? Now, from a designer’s
perspective, you might want to make that look
as great as you possibly can, because maybe you’re used
to building a native app. Maybe you’re used to being
able to just shove as much data in there as you want. For a mobile site, there are a
few additional considerations there, because you’re
basically trying to just ship, in real time, all
of these bytes down the wire. And you want them to
load up really quickly. So I think you need
to think about, well, what is the limitation? What is the budget that the
developer probably has in order to ship this down to the user? I’ll let them figure out how
much JavaScript, how much CSS needs to be shipped down. But what can I do in order to
minimize the amount of work that needs to be done to
get that page loaded up and get that page useful? And so I think that,
from both sides, it benefits a lot from
us talking to each other. I think in recent years,
I’ve seen patterns like skeleton loading
screens become quite popular for helping us do that
sort of transition from one view to another. With an experience
like that, I think that that requires both sides
understanding what it is they’re trying to accomplish. They’re trying to accomplish
a really good user experience. And we’re thinking, well, if
we don’t show them a loading spinner and we show them
a skeleton screen instead, the user is going to feel
like something’s happening as soon as they tap on a button. They’re going to see,
oh, so I’m probably going to see a little
bit of text here, maybe I’ll see some images here. And they’re probably going
to stay with that page a little bit longer rather than
saying, oh man, that spinner, it’s still spinning. I’ve been waiting a few minutes,
nothing’s really happening. And they’re probably
going to end up leaving the experience if
they see something like that. MUSTAFA: Absolutely. I know there’s like a– as you get to the three seconds,
the longer something takes, and this is the whole concept
of perceived performance, which is quite new for designers. It’s like something that’s
not necessarily really fast, but it feels forced because
you’re loading the skeleton layout first. So you can feel
something’s happening even though technically,
side-by-side, a blank screen loading and the
skeleton is basically the same. But once you get to
the three-second mark, you’ve basically lost
the people’s attention. ADDY: Yeah, you’re basically
trying to hack human perception as much as you can. MUSTAFA: Yeah, but what’s
interesting is when we design, we always design the
final loaded thing. We don’t really think
about, all right, as this thing is
being downloaded, or what happens if
x fails to load? What happens if this image is
in a poor network environment? How do we get to a
point where we can design before the final thing? Because you’ll get
there eventually, but what is understanding
what a budget means from a design point of view? Because we don’t really
have a tool to actually say, all right, say you
were in Sketch, and you were to
highlight something. This is going to cost you 10
seconds, or the equivalent. ADDY: I feel like we’re
both in the same bucket where as we’ve been getting
closer and closer to thinking about mobile experiences
and how to build them in an efficient
way, we’re having to think about loading
a little bit differently to how we have in the past. Now, as it developer, I think
about loading these days in sort of three stages. You’ve got the
“is it happening,” so is there anything
actually on the screen. Even if it’s just a
toolbar or a header. Then you’ve got
the “is it useful,” so maybe you’re showing me
some text at that point. If I’m on the Times or
something, and you’re showing me an article. And then there’s the
“is it useful” moment. So if I start tapping
around the experience, can I actually go
to other pages? Can I have something happen? And from a developer
side of view, that requires you to
think a little bit differently about how
you’re shipping things down. A developer probably has to
think about maybe breaking up their Javascript, breaking
up or CSS, anything else that they’re going to ship down
the wire so that you’re just having the minimal
set of things. A designer has to
think about, well, what are all of
these loading states that the developer’s going
to try showing to the user? And how can I make
sure that that looks as pleasing as possible
but is also improving perceived performance? Providing a
performant experience is something that requires
close collaboration between two sides. I don’t think I’d ever seen
skeleton screens as a concept until I started reading blogs
that designers were working on. MUSTAFA: Is there
like, A to Z of states? I’ve worked on
coming up with sort of visual concepts
for offline stuff. You have like a component,
or a widget, or a thing. Is there different states? Or is it almost like
I’m asking for something that doesn’t exist because
it depends on the context? It just depends, right? ADDY: It’s almost
as if you’re asking for is there a holistic
piece of guidance for anything on the web. And the answer’s no, just no. Write it yourself. I think the answer to
that is, it is nuanced, and it depends on
what components you’re displaying
in your experience. I certainly know that
if you’ve got a card UI, you probably want to show the
card as maybe your skeleton. And then maybe you
show a placeholder for the images and the text that
are going to be in that card. I’ve certainly seen some
people have taken it to extremes where
they’ll even show a blurred-out
version of the image, or just use CSS to approximate
what that piece of square is going to look like, and
then transition in the actual content when it’s there. But it’s going to vary. It really depends on what your
application is trying to do and what your
latencies look like. If you think that
you’re going to be able to deliver an experience
in two or three seconds, then maybe you only need two
states, two or three states. If you are something
super complex, you might need more than that. As we’re thinking
a little bit more holistically about loading,
from a developer side, we are considering ideas like
progressive bootstrapping or progressive
rendering where we go through these
different loading states and try to show more and
more things on the screen as they come in rather than just
holding off, going from a page being completely
blank and white, and then waiting
until the very end, and then just showing
everything at once. Because as a user,
you’re going to enjoy, I think, seeing at least
something on the screen sooner. MUSTAFA: I also wanted to bring
up Flash, because I know– ADDY: Get off Flash. MUSTAFA: Flash seemed to be
like the middle person that could really bridge the
gap between a developer and a designer. Conceptually, I
learned about code just through ActionScript
and the concept of the stage. It always seems to me
it feels like the tool, but I don’t know. Maybe I’m reminiscing
about something that was great for designers
but terrible for the users. ADDY: I would actually
say at that time we were developing very
heavily for the desktop web. I used to be a Flash developer
and an ActionScript developer. So if it weren’t
for the Flash ID– I know exactly what you
mean about the stage and everything– I would never have been able
to do like complex animations or anything like that
were it not for Flash. And it was just
such a great tool. But it let you take
all of your creativity and then export it into
this sort of black box that you just through
with the browser. And I think we all got used to
this idea of, you know what? I’m just going to
be OK with waiting three minutes for this
custom loading progress bar to show up and do something
at the very end of it. On the web today, you
could you could build tools that do these things. But having them do that
in an efficient way without requiring a bunch
of manual work on your part, we’re not quite there just yet. I would love if
there was a tool that allowed you to work as
productively as Flash allowed you to do, and
exported decent stuff. But it’s been one of those
historically hard problems with web content,
like generating code. MUSTAFA: And also I
think users are not as patient as they once were. I was almost like, well,
back in the old days, which wasn’t that long ago. ADDY: Back in my day. MUSTAFA: Yeah, but I
remember watching– I think it was the MTV website
back in like, 10, 15 years ago, or like “Dazed and Confused.” Five-minute loading
time, and you would wait. And then you couldn’t
read the article properly because it was something
that was made for the maker, not for the viewer. People not willing to wait
for that sort of thing. ADDY: Definitely not on mobile. We say that three seconds
is the ideal loading time. Try to get interactive
in five seconds. We also know that for a
lot of the long tail web, it’s not uncommon for pages
to take 19 seconds to load. And maybe 19 seconds is OK if
you’ve got a giant Flash movie, but people are just going to
leave the experience on mobile. So I think that we need to find
that balance where you can come up with a tool like a
Flash ID or something, but have it either
generate better code, or just work better with
the rest of the tools that we have available
in the ecosystem. I’m personally a big fan
of things like FramerJS where designers can
use code to come up with really
beautiful experiences that can be complex, and then
hand it off to developers to try to figure
out, OK, well, how do I actually implement
this in a way that can be loaded
efficiently, or can be done efficiently on the web. And that’s not a bad
place to be right now. I know that those tools are
also evolving constantly. Maybe a good
eventual place could be where a designer can
design and experience in all the views and
everything and tackle motion and everything in a great way. And the same tool can
give the developer enough of the code as an
output so they can go and start hacking on it without it being
so divorced from whatever the designer was working on. MUSTAFA: It feels like
something’s missing. And it’s almost like
whatever that tool is will be the next evolutionary
step for our industry. And I guess what I’m
saying is, when are you going to build it, Addy? ADDY: Any day now, any day now. This entire thing
is a commercial for my next set of projects. SPEAKER: In order to
be good at something, you need to practice that skill. But in order to judge whether
you are good at something, you just kind of
need experience.

12 thoughts on “Designing for Great Performance — Designer vs. Developer #9

  1. Hey folks! This was fun. Quick slip-up I had at 5:22: the three stages of modern loading are:
    1. is it happening? (is there anything on screen to indicate the page is loading)
    2. is it useful? (is there any meaningful text or useful content on screen)
    3. is it usable? (can the user tap with elements in the UI and interact with it)

  2. Here is the reality, If your App or Ad takes longer than (two)seconds , The odds of that customer leaving increase by 48 percent, I'm more concern with scalability.

  3. Thanks, Addy for all your research on the performance front! You are a great inspiration to me to drive PWA and PRPL adoption on projects in my team. The future sure is bright with service worker coming in Safari πŸ™‚ Keep up the good work.

    P.S.: Really loved the fruitful PWA related discussions with Dan Abramov and Evan You and how that transformed create-react-app and the vue generators.

  4. I think the importance and relevance of content plays a huge factor how long a user will wait for content to load. The rise of "clickbait" and other ad-impression-hunting schemes rely heavily on a fast loading experience because as soon as the user realises the content quality is poor, incorrect or simply false they will move on; by that time you don't care because you have your ad impression.

    On the other hand, if a user is looking for a particular piece of content/media, from a particular source they know and trust, they will wait much longer because they know that once the content loads they will have what they're looking for.

  5. Hi. Nice thought provoking video, thanks! Are you able to share any good resources for implementing Skeleton loading elements, please? I am familiar with the old spinner scenario, so is it just a case of implementing that but on multiple elements rather than just one big one that covers the page? Cheers.

Leave a Reply

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