Lightning fast UX: faking performance when there’s no code left to optimize

You have optimised every line of code of your site or mobile app and used all the techniques at your disposal to have the fastest loading time possible. But you don’t have Instagram or Pinterest’s budget, right? Let's talk about perceived performance and influencing the users' perception of speed!
Stéphanie Walter will take a look at a few projects she worked on to show us how to use various design and UX techniques to improve web performance also at the level of user perception.

Transcript

1. Lightning fast UX Stéphanie Walter - Senior UX Designer & Mobile Expert – 2019 Faking performance when there’s no code left to optimize
2. Senior UX Designer Mobile expert. Pixel & CSS Lover stephaniewalter.design @WalterStephanie
3. Psychological time (perception of time in my brain) Objective time (the clock)
4. Human Perception of Speed
5. External factors might affect speed perception…
6. The tip of the iceberg: how fast can users interact with the content?
7. User State of Mind User profile Younger audience is more demanding Speed is perceived as faster by relaxed users Google and Awwwards study
8. User situation and the ROI for waiting
9. Speed perception impacts user satisfaction.
10. UI visual time response
11. 0 - 300ms Instant UI visual response
12. Instant visual feedback on user micro-interactions
13. Providing the different states is the designer’s job
14. 300ms - 1 second Delay can be noticed but it’s tolerable, no special feedback is necessary.
15. 2 - 5 seconds Dynamic indeterminate loaders to show that the system is still working
16. “Everything is fine, the system is currently working”
17. It’s time to get creative
18. Show some brand personality ๏ training + le chat
19. More than 5 seconds Determinate progress indicators to keep user focused
20. ๏ Explain what will take time and why
21. ๏ Explain what will take time and why ๏ Show advanced dynamic progress indicator with current progression (% or steps)
22. ๏ Explain what will take time and why ๏ Show advanced dynamic progress indicator with current progression (% or steps) ๏ If possible, don’t block users
23. (Nielsen, 1994; Bouch, 2000) 10 seconds is about the limit for keeping the user's attention focused “
24. The Seagull Loader
25. “We optimized every piece of code possible but users with big queries are still complaining”
26. A seagull replaces the boring spinner
 — widely approved by users — ๏ While users wait for the search to finish, the interface displays useful information
27. While users wait for the search to finish, the interface displays useful information
29. It looks fast… Clever transitions and animations
30. Animated page transitions
31. Animate arrivals and departures via Val Head
32. It’s more satisfying to see the bar speed up towards the end. (Harrison, Amento, Kuznetsov et Bell - 2007 ) demo by Geoffrey C.
33. Backwards decelerating ribbing significantly increased perceived performance (Harrison, Yeo et Hudson - 2010 ) demo by Geoffrey C.
34. On Demand Surveillance Video Loading
35. Discussing with the development team to understand technical requirements. 1.
36. How this works Camera takes the video and sends it to the server Server reencodes the video and sends it to the app The app displays the video and users can play it
37. Deconstructing the waiting timeline millisecond by millisecond. 2.
38. Interface Transition 300ms 2s 3 - 8s Video player components load on the screen with a fade in transition Indeterminate waiting indicator Video plays as soon as loaded
40. Communicating and sharing the specifications with the development team. 3.
41. Step by step static states in design tool.
42. Specifications document for the developers
43. Faking it Building Optimistic UIs
44. Optimistic likes
45. Optimistic Home Alarm Status Switching
46. Trusting our API (and server) - providing optimistic instant feedbacks to the user 1.
47. We don’t wait for the server response to visually change the status in the interface
48. “But what will be the consequences of a system failure from a user perspective?”
49. Identifying possible failure cases and acting accordingly. 2.
50. Informing users that something went wrong (and helping them fix it if possible) 3.
51. In case of failure we notify the user and switch back to previous state
52. Smart User Distractions
53. GVBeestje crocodiles by Daniel Disselkoen in Amsterdam’s metro
54. upload starts Instagram uploads medias in the background while user fill the rest of the post
55. Skeleton screens and lazy loading * * Test it on your users
56. Pinterest has some really nice colorful placeholders
57. Be careful with content jumps & layout updates
58. Don’t overdue it …
59. Car Repair Image Gallery Loading
60. The mechanic takes pictures and records small videos to explain what needs to be repaired. Vidéo Privé Frontal 00:35 00:35 Nouvelle Image Nouvelle Video Medias Précédent Suivant 00:35
61. Understanding the user context and user flow to enhance experience. 1.
62. ๏ Data connexion in repair workshop can be really slow and wifi is often bad. ๏ Mechanics sometimes miss information because of latency, both network and human ๏ Mechanics share the same device.
63. Discussing and understanding technical scope and requirements. 2.
64. ๏ Medias are deleted from the device once received by our service —> we need to load them again when we edit a file. ๏ Size, media type, number of medias is sent in a JSON file, ๏ Thumbnails are loaded from Amazon S3 00:35 00:35 Nouvelle Image Nouvelle Video Medias Précédent Suivant 00:35
65. Building the gallery step by step 3.
66. A Skeleton Grid 
 based on the number of medias (sent by JSON) Nouvelle Image Nouvelle Video Medias Précédent Suivant 9 medias!
67. A gallery of spinners is never a good solution ๏ Un indicateur alors que
68. Media type thumbnails to fill the skeleton Medias
69. Pulsing animation 
 as loader
70. Progressively displaying media content as it loads
71. Visual feedbacks for time-out and loading failures. 00:35 Medias 00:35
72. No user flow interruption
73. Communicating what is expected with developers 4.
74. ๏ Static mockups ๏ Timer to switch between each screen ๏ Really limited :/ Invision prototype for the developers
75. ๏ A video animation of the expected flow (Flinto) ๏ Static mockups replaced by GIFs prepared in Photoshop
76. Too realistic fake prototypes might backfire during user testing…
77. What I learned ๏ Don’t use the same “fake prototype” for developers and for user testing ๏ If possible, test performance on an “coded” prototype with a real user connexion
78. Wait, let’s slow down a little bit…
79. Do we ALWAYS want to make things faster?
80. “It can’t be THAT fast, there must be a trick somewhere”
 - me, the first time I saw my bank instant notification after paying in a shop.
81. Wells Fargo’s eye-scan based log-in was too fast for users, they had to slow it down.
82. The Kayak Effect “Labour illusion”
 Users value things more when they believe effort has been put into them
83. Making conversations with chatbots feel more natural: slow down response time 
 and add a typing indicator Image via Shan Shen
84. In the end …
85. We design and develop in privileged environments and sometimes need a “what is it like for our user” reality check.
86. Designers and developers need to communicate and work together to come up with the best solution possible.
87. Perceived performance might not be the top priority on the roadmap. Be patient, start small, one step at a time.
88. We can’t all be Instagram, Twitter or Pinterest… And it’s okay.
89. Senior UX Designer Mobile expert. Pixel & CSS Lover stephaniewalter.design @WalterStephanie