Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cheating the UX When There Is Nothing More to Optimize - PixelPioneers

Cheating the UX When There Is Nothing More to Optimize - PixelPioneers

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!

I take a look at a few projects I worked on to show how to use various design and UX techniques to improve web performance also at the level of user perception.

Stéphanie Walter

June 08, 2018
Tweet

More Decks by Stéphanie Walter

Other Decks in Design

Transcript

  1. Cheating The UX When There Is
    Nothing More To Optimize
    Pixel Pioneers 2018 — Stéphanie Walter

    View full-size slide

  2. UI & UX designer.
    Mobile enthusiast Pixel and CSS Lover.
    Currently working for
    stephaniewalter.design @WalterStephanie

    View full-size slide

  3. Psychological time
    (perception of time in my brain)
    Objective time
    (the clock)

    View full-size slide

  4. Human Perception of Speed

    View full-size slide

  5. External factors might affect speed
    perception…

    View full-size slide

  6. How fast can users interact with the content?

    View full-size slide

  7. User State of Mind
    User profile
    Younger audience is more demanding Speed is perceived as faster by relaxed users
    Google and Awwwards study

    View full-size slide

  8. User Situation - the ROI for waiting

    View full-size slide

  9. Speed perception impacts user
    satisfaction.

    View full-size slide

  10. Interface visual time response

    View full-size slide

  11. 0 - 300ms
    Instant UI visual response

    View full-size slide

  12. Instant visual feedback on user micro-interactions

    View full-size slide

  13. Providing states is the designer’s job

    View full-size slide

  14. 300ms - 1 second
    Delay can be noticed but it’s tolerable, no special feedback is necessary.

    View full-size slide

  15. 2 - 5 seconds
    Dynamic indeterminate loaders to show that the
    system is still working

    View full-size slide

  16. “Everything is fine, the system is currently working”

    View full-size slide

  17. It’s time to get creative

    View full-size slide

  18. Show some brand
    personality

    View full-size slide

  19. More than 5 seconds
    Determinate progress indicators to keep user focused

    View full-size slide

  20. ๏ Show advanced dynamic
    progress indicator

    View full-size slide

  21. ๏ Show advanced dynamic progress
    indicator
    ๏ Explain what will take time (and
    why)

    View full-size slide

  22. ๏ Show advanced dynamic progress
    indicator
    ๏ Explain what will take time (and
    why)
    ๏ Show current progression (% or
    steps)

    View full-size slide

  23. ๏ Show advanced dynamic progress
    indicator
    ๏ Explain what will take time (and
    why)
    ๏ Show current progression (% or
    steps)
    ๏ If possible, don’t block users

    View full-size slide



  24. 10 seconds is about the limit for
    keeping the user's attention focused
    (Nielsen, 1994; Bouch, 2000)

    View full-size slide

  25. Seagull Loader

    View full-size slide

  26. “We optimized every piece of code
    possible but users with big queries
    are still complaining”

    View full-size slide

  27. A seagull replaces the
    boring spinner — widely
    approved by the users —
    ๏ While users wait for the search to finish, the
    interface displays useful information

    View full-size slide

  28. While users wait for
    the search to finish,
    the interface displays
    useful information

    View full-size slide

  29. It looks fast…
    Clever transitions and animations

    View full-size slide

  30. Animated page transitions

    View full-size slide

  31. Animate arrivals and departures
    via Val Head

    View full-size slide

  32. 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.

    View full-size slide

  33. It’s more satisfying to see the bar speed up
    towards the end.
    (Harrison, Amento, Kuznetsov et Bell - 2007 )

    View full-size slide

  34. Backwards decelerating ribbing significantly
    increased perceived performance.
    (Harrison, Yeo et Hudson - 2010 )

    View full-size slide

  35. On Demand Surveillance Video
    Loading

    View full-size slide

  36. Discussing with the development
    team to understand technical
    requirements.
    1.

    View full-size slide

  37. 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

    View full-size slide

  38. Deconstructing the waiting timeline
    millisecond by millisecond.
    2.

    View full-size slide

  39. 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

    View full-size slide

  40. Communicating and sharing the
    specifications with the development
    team.
    3.

    View full-size slide

  41. Step by step static states in design tool.

    View full-size slide

  42. Specifications document for the developers

    View full-size slide

  43. Faking it
    Building Optimistic UIs

    View full-size slide

  44. Optimistic likes

    View full-size slide

  45. Optimistic Home Alarm Status
    Switching

    View full-size slide

  46. Trusting our API (and server) -
    providing optimistic instant
    feedbacks to the user
    1.

    View full-size slide

  47. We don’t wait for the server to respond to visually
    change the status on the interface

    View full-size slide

  48. “But what will be the consequences
    of a system failure from a user
    perspective?”

    View full-size slide

  49. Identifying possible failure cases
    and acting accordingly.
    2.

    View full-size slide

  50. Informing users that something went
    wrong (and helping them fix it if
    possible)
    3.

    View full-size slide

  51. In case of failure: notifying the user and switching
    back to previous state

    View full-size slide

  52. Smart User Distractions

    View full-size slide

  53. GVBeestje crocodiles by Daniel Disselkoen in Amsterdam’s metro

    View full-size slide

  54. Instagram’s preemptive media uploading
    upload starts here

    View full-size slide

  55. Skeleton screens and progressively display content as it
    arrives in the browser

    View full-size slide

  56. Pinterest has some really nice colorful interface
    placeholders

    View full-size slide

  57. Be careful with content jumps & layout updates

    View full-size slide

  58. Be careful not to overdue it …

    View full-size slide

  59. Car Repair Image Gallery
    Loading

    View full-size slide

  60. 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

    View full-size slide

  61. Understanding the user context and
    user flow to enhance experience.
    1.

    View full-size slide

  62. ๏ Data connexion 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.

    View full-size slide

  63. Discussing and understanding
    technical scope and requirements.
    2.

    View full-size slide

  64. ๏ 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

    View full-size slide

  65. Building the gallery step by step
    3.

    View full-size slide

  66. A Skeleton Grid based
    on the number of
    medias
    Nouvelle Image Nouvelle Video
    Medias
    Précédent Suivant

    View full-size slide

  67. A gallery of spinners is
    never a good solution

    View full-size slide

  68. Media type thumbnails to
    fill the skeleton
    Nouvelle Image Nouvelle Video
    Medias
    Précédent Suivant

    View full-size slide

  69. Pulsing animation as
    loader

    View full-size slide

  70. Progressively displaying
    media content as it
    loads

    View full-size slide

  71. Visual feedbacks for
    time-out and loading
    failures.
    00:35
    Nouvelle Image Nouvelle Video
    Medias
    Précédent Suivant
    00:35

    View full-size slide

  72. No user flow interruption:
    users can interact with the
    interface and take new
    images while the gallery
    loads in the background

    View full-size slide

  73. Communicating what is expected
    with developers
    4.

    View full-size slide

  74. ๏ Static mockups
    ๏ Timer to switch between
    each screen
    ๏ Really limited: frame by
    frame animation = long
    and tedious
    Invision prototype for
    the developers

    View full-size slide

  75. ๏ Flinto to build the pulse
    animation
    ๏ Static mockups replaced by
    GIFs prepared in Photoshop
    (glitchy in Invision on mobile)

    View full-size slide

  76. Too realistic fake prototypes
    might backfire during user
    testing…

    View full-size slide

  77. ๏ Don’t use the same fake prototype for
    developers and user testing
    ๏ If possible, test performance on an
    “coded” prototype with a real user
    connexion
    What I learned

    View full-size slide

  78. Documentation for the developers:

    ๏ Invision clickable prototype
    ๏ video animation of the flow
    ๏ written specs.

    View full-size slide

  79. Wait, let’s slow down a little bit…

    View full-size slide

  80. Do we ALWAYS need to make our
    interface faster?

    View full-size slide

  81. “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.

    View full-size slide

  82. Wells Fargo’s eye-scan based log-in was too fast for
    users, they had to slow it down.

    View full-size slide

  83. The Kayak Effect
    The “labour illusion” - users value things more when they believe effort has been put into them

    View full-size slide

  84. To make conversations with chatbots feel more natural: slow down
    response time and add a typing indicator
    Image via Shan Shen

    View full-size slide

  85. In the end …

    View full-size slide

  86. We design and develop in
    privileged environments and
    sometimes need a “what is it like
    for our user” reality check.

    View full-size slide

  87. Our developers use the network conditioner to simulate a bad
    connexion on the iPhone

    View full-size slide

  88. Building a performant product is a
    team effort!

    View full-size slide

  89. Building Designers and developers
    need to communicate and work
    together to come up with the best
    solution possible.

    View full-size slide

  90. Perceived performance might not
    be the top priority on the
    roadmap. Be patient, start small,
    one step at a time.

    View full-size slide

  91. We can’t all be Instagram, Twitter
    or Pinterest… And it’s okay.

    View full-size slide

  92. stephaniewalter.design @WalterStephanie
    Attribution-NonCommercial-ShareAlike 4.0 International

    View full-size slide