 Hello there. My name is Mustafa, UX designer at Google. And in this talk, I'm going to be covering designing for speed and hacking user perception. So I'll go through some research and some design examples. But before I get into that, I'd like to talk through a story which will summarize pretty much most of the talk. And that's the story of the slow elevator. So people often complain to building managers that the elevator is running really slow. So this is a big pain point. One potential solution is to make the elevator faster. So you can install a new motor, you can upgrade the motor, you can rip out the elevator, try different algorithms. The problem with this, though, is quite an expensive thing to do. And for legacy systems, this is really difficult. So this parable kind of describes the web. When new technologies or new techniques come out, it's really difficult to rip out old code and replace it with new code. So what can we actually do in these situations? Well, if we look at the problem and the pain point, the elevator is slow. Really, from a user point of view, it's not so much the elevator being slow, but it's actually the waiting being quite annoying. So if we reframe the problem, we say, OK, waiting is annoying. So what can we do to actually make the waiting feel shorter? So we say, OK, building managers will put up mirrors, they'll install a hand sanitizer, and perhaps they'll play music. And this distraction technique will actually make the whole experience feel much faster. So reframing the problem can actually help us think about how we can hack things perceptively for the users. Because speed is broken down into two things, real and perceived. So looking at some of the technical speed data, like we see like the financial times. So the financial times have this interesting algorithm called the tipping point. If the user comes to the website five times a month to read five articles a month, they're more likely to subscribe to their site. And if they reach nine articles a month, then they'll definitely more likely to subscribe. So they have this tipping point, the moment the user starts accessing the site five times a month. So they'll start targeting and engaging with that user. But what they found was by making the website one second faster, they increased engagement for everybody coming to the website. So making the experience faster from a technical point of view is really critical. But also the opposite of true. For every two seconds for a site text to load, bounce rates go up by 50%. So it's really critical to make your sites technically fast. And from a UX point of view, when you ask users what's the most important thing on the page, they always talk about speed. As a matter of fact, the top four things here are all about speed and perception if you think about them. The bottom one, how attractive a site looks is quite depressing for me as a designer. But on the mobile web, speed is really, really critical. But what can we do as a quick win? So we have an app called Squoosh that we released last year. This optimizes images on the web. Why is that important? Because average page content is images, and images are really heavy. So this is a PWA. You can drag and drop images and start reducing the size of the images. And we demonstrate this at Chrome Dev Summit 2019 and showed by taking the iOS home page image, we reduced it by 83%. So we can all collectively start improving the experiences on the web just by making images much smaller. You can download the code here and also grab any of the components that are useful, such as pinch to zoom. So please do check that out. But speed on mobile web is important, but the perception of speed is just as important. Because what we find is, at least the third of users still feel experiences that are technically fast are actually feel really slow. So what can we do to actually improve that? Well, perception and recognizable UI. Making navigation front of center is one small thing that you can do. Because if a button is recognized straight away, the experiences feel faster based on the research that we've seen. So another example is making buttons recognizable as buttons. So the blue button here looks like a button. It's more likely to be engaged with. As opposed to the text button, which it may be a button, it may not be a button. So if a person is looking around a page to see what they're supposed to tap or click on, the experience feels slower. So make your navigation items recognizable. Also, give feedback to the user. So the typical life of a button is a user will see a button. They'll tap on a button, engage with it. They get enraged because they don't know what's happening. And then they may tap on again because maybe they didn't tap on it correctly the first time. So what can we do to stop this? Well, just giving back feedback mechanisms like the ripple that we have in material design can help. Because on touchscreen devices, you won't have a hover. So just giving reassurances to the user is a small thing to actually change the perceptive speed of an actual experience. Progression is really key here as well. Giving users some indication how long something takes to load. One interesting thing in research that we find is ripples that animate towards the left feel faster than other forms of progression. So if you can see in this animation, they're all the same. But the one third from bottom feels faster. And YouTube, what we do is we will stagger the progress bar across the top just a little bit because it gives this anticipation and hanging. So it feels like the site is loading. Again, this is a small perceptive thing that hacks the perception that the experience is actually in progress. One other thing that you can do is skeleton screens, which are placeholders for content. So one thing that you don't want to do in the scale of good to bad is a blank screen. You want to make sure you show something. The next thing along is an actual spinner. Spinners are better than showing nothing on an experience, but they still don't give any clear indication of what and when something's actually coming. Replacement of that would be the skeleton screens. Now, when you ask users about skeleton screens, generally speaking, they'll say gray boxes makes the experience feel broken. And there's this mass reveal, which isn't great because conceptually, it's the same as the spinner. What we really would need to do is have metadata, giving an indication to the user that what is coming above the skeletons. The moment we have content, we load it. And perhaps if images will frost or show a pixelated version first and then load the actual full quality image. So you want to show every step some form of progression so the user is reassured that something is definitely coming. Now, again, this is contextual to your own experiences. So in YouTube, what we do is we'll load the video first as opposed to the rest of the content, even though it's the heaviest thing on the page. Because as part of the experience, the video is the most important thing. So again, you have to target which content pieces are critical in your experience and load them first. Because the transitions that we use, we want to give the feeling of progression rather than processing. So we don't just show a spinner and give no indication of what's going. We want to show content coming in slowly and coming out because it feels like a much more faster, progressive experience. So in summary, you want to make sure you reframe the problem. You want to avoid blank screens. You want to show bold animations, making sure that you're progressing rather than processing, and keep navigation clear and simple. To find out more about the research on speed, you can download our ebook here called Brain Food. We can also check out our PWA ebook to learn more about progressive web apps. And I also have this course on Skillshare that you can learn about the process of UX to help improve your experiences. And with that, I'd like to say thank you.