Cheating-UX_When-There-Is-Nothing-More-To-Optimize.pdf

A frontend presentation on how to see the waiting time(Loaders) as a UX perspective when creating or i should say building a web page today. We need to think how user perceive what they are using. Is it just a mere website or the good experience of using it and being there is your motive?? Do you want to engage and service your customers better on web???? This presentation will help you a lot in thinking and seeing things in a new way.

Transcript

1. 
 ADCAT ANNUAL STRATEGY MEET June 2019 By - Gaurav Singh
3. Waiting Syndrome
4. Waiting Syndrome
5. Psychological time (perception of time in my brain) Objective time (the clock)
6. Human Perception of Speed
7. External factors might affect speed perception…
8. How fast can users interact with the content?
9. User State of Mind User profile Younger audience is more demanding Speed is perceived as faster by relaxed users Google and Awwwards study
10. User Situation - the ROI for waiting
11. Speed perception impacts user satisfaction.
12. Interface visual time response
13. 0- 300ms Instant UI visual response
14. Instant visual feedback on user micro-interactions
15. Providing states is the designer’s job
16. 300ms - 1 second Delay can be noticed but it’s tolerable, no special feedback is necessary.
17. 2 - 5 seconds Dynamic indeterminate loaders to show that the system is still working
18. “Everything is fine, the system is currently working ”
19. It’s time to get creative
20. Show some brand personality
21. More than 5 seconds Determinate progress indicators to keep user focused
22. ๏ Show advanced dynamic progress indicator
23. ๏ Show advanced dynamic progress indicator ๏ Explain what will take time (and why)
24. ๏ Show advanced dynamic progress indicator ๏ Explain what will take time (and why) ๏ Show current progression (% or steps)
25. ๏ Show advanced dynamic progress indicator ๏ Explain what will take time (and why) ๏ Show current progression (% or steps) ๏ If possible, don’t block users
26. “ “ 10 seconds is about the limit for keeping the user's attention focused (Nielsen, 1994; Bouch, 2000)
27. Seagull Loader
28. “We optimized every piece of code possible but users with big queries are still complaining”
29. A seagull replaces the boring spinner — widely approved by the users — ๏ While users wait for the search to finish, t h e interface displays useful information
30. While users wait for the search to finish, the interface displays useful information
32. It looks fast… Clever transitions and animations
33. Animated page transitions
34. Animate arrivals and departures via Val Head
35. Ease-out works best for instant reactions, menus, buttons, to respond to user input. Ease-in works best for prompt windows and when you need to display information.
36. It’s more satisfying to see the bar speed up towards the end. (Harrison, Amento, Kuznetsov et Bell - 2007 )
37. Backwards decelerating ribbing significantly increased perceived performance by 11% (Harrison, Yeo et Hudson - 2010 )
38. Faking it Building Optimistic UIs
39. Optimistic Home Alarm Status Switching
40. Trusting our API (and server) - providing optimistic instant feedbacks to the user 1.
41. We don’t wait for the server to respond to visually change the status on the interface
42. “But what will be the consequences of a system failure from a user perspective?”
43. 2. Identifying possible failure cases and acting accordingly.
44. Informing users that something went wrong (and helping them fix it if possible) 3.
45. In case of failure: notifying the user and switching back to previous state
46. Smart User Distractions
47. GVBeestje crocodiles by Daniel Disselkoen in Amsterdam’s metro
48. Instagram’s preemptive media uploading upload starts here
49. Skeleton screens and progressively display content as it arrives in the browser
50. Pinterest has some really nice colorful interface placeholders
51. Be careful with content jumps & layout updates
52. Be careful not to overdue it …
53. Car Repair Image Gallery Loading
54. The mechanic takes photos and records small videos to explain what needs to be repaired. 00:35 00:35 Nouvelle Image Nouvelle Video Medias Précédent Suivant 00:35 Vidéo Privé Frontal
55. Understanding the user context and user flow to enhance experience. 1.
56. ๏ Data connection in a body repair workshop can be really slow and wifi is often bad. ๏ Mechanics sometimes miss information because of latency. ๏ Some users share the same device.
57. Discussing and understanding technical scope and requirements. 2.
58. ๏ Medias are deleted from the device once the file is sent (so 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
59. Building the gallery step by step 3.
60. A Skeleton Grid based on the number of medias Nouvelle Image Nouvelle Video Medias Précédent Suivant
61. A gallery of spinners is never a good solution
62. Media type thumbnails to fill the skeleton Nouvelle Image Nouvelle Video Medias Précédent Suivant
63. Pulsing animation as loader
64. Progressively displaying media content as it loads
65. Visual feedbacks for time-out and loading failures. 00:35 Nouvelle Image Nouvelle Video Medias Précédent Suivant 00:35
66. No user flow interruption: users can interact with the interface and take new images while the gallery loads in the background
67. Communicating what is expected with developers 4.
68. ๏ Static mockups ๏ Timer to switch between each screen ๏ Really limited: frame by frame animation = long and tedious Invision prototype for the developers
69. ๏ Flinto to build the pulse animation ๏ Static mockups replaced by GIFs prepared in Photoshop (glitchy in Invision on mobile)
70. Too realistic fake prototypes might backfire during user testing…
71. ๏ Don’t use the same fake prototype for developers and user testing ๏ If possible, test performance on an “coded” prototype with a real user connection What I learned
72. Documentation for the developers: ๏ clickable prototype video animation of the flow ๏ ๏ written specs Invision
73. Wait, let’s slow down a little bit…
74. Do we ALWAYS need to make our interface faster?
75. “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.
77. Wells Fargo’s eye-scan based log-in was too fast for users, they had to slow it down.
78. The Kayak Effect The “labour illusion” - users value things more when they believe effort has been put into them
79. To make conversations with chatbots feel more natural: slow down response time and add a typing indicator Image via Shan Shen
80. In the end …
81. We design and develop in privileged environments and sometimes need a “what is it like for our user” reality check.
82. Our developers use the network conditioner to simulate a bad connection on the iPhone
83. Building a performant product is a team effort!
84. Building Designers and developers need to communicate and work together to come up with the best solution possible.
85. Perceived performance might not be the top priority on the roadmap. Be patient, start small, one step at a time.
86. We can’t all be Instagram, Twitter or Pinterest… And it’s okay.
87. Thank You