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