The document discusses the importance of system performance and responsiveness from the perspectives of users, interaction designers, and software developers. It notes that slow or unresponsive systems can negatively impact the user experience by creating frustration and usability issues. Both designers and developers need to prioritize performance testing and work together in tight cycles to ensure smooth interactions. While performance cannot always be directly improved, the user experience can be enhanced by providing feedback during longer processes.

1. System
performance
as
user
experience
catastrophe
best
and
worst
prac.ces
for
interac.on
designers
and
programmers
Michael
Klein
Interac.on
designer,
developer
and
UI
connoisseur
h<p://gplus.to/michaelklein27,
h<p://www.linkedin.com/in/michaelklein3,
@mischkl

2. System
performance
as
user
experience
catastrophe
best
and
worst
prac.ces
for
interac.on
designers
and
programmers
What
am
I
talking
about?

3. What
am
I
talking
about?
Let’s
take
a
look
at
some
examples
h<p://www.youtube.com/watch?v=HyA6UXi0v6g

4. What
am
I
talking
about?
h<p://xkcd.com/612/

5. What
am
I
talking
about?
h<p://www.youtube.com/watch?v=sxtYxIObjWg

6. What
am
I
talking
about?
h<p://www.youtube.com/watch?v=nfnM_8JBmmA

7. What
am
I
talking
about?
h<p://www.youtube.com/watch?v=apN0_NQrC0s

8. What
do
all
these
examples
have
in
common?

9. What
do
all
these
examples
have
in
common?

10. TIME
(aka
a
temporal
sequence
of
events)
What’s
so
special
about
it?
(from
a
user’s
perspec>ve)
• “HCI
impedance
mismatch”
(my
phrase)
–
user’s
ac.ons
are
too
fast
for
the
system,
system’s
responses
are
too
slow
for
the
user
• Without
immediate
feedback,
user
error
is
introduced—they
click
bu<ons
mul.ple
.mes,
try
to
swipe
mul.ple
.mes,
try
to
close
unresponsive
apps
even
if
they
are
not
actually
frozen,
poten.ally
leading
to
data
loss,
etc.
• When
things
don’t
work
smoothly,
users
are
reminded
that
they
are
“using
a
computer”,
sense
of
magic/fun
decreases,
sense
of
control
decreases,
frustra.on
increases
• Unresponsive
apps
violate
4
of
Nielsen’s
10
usability
heuris>cs
(Visibility
of
system
status,
match
with
real
world
(real
objects
don’t
stu<er/freeze),
user
control/freedom,
error
preven.on.)

11. TIME
(aka
a
temporal
sequence
of
events)
What’s
so
special
about
it?
(from
an
interac>on
designer’s
perspec>ve)
• Difficult
to
portray
.me-­‐sensi.ve
interac.ons
in
sta>c
mockups,
or
even
in
higher-­‐level
prototypes
• Time-­‐based
performance
characteris.cs
are
invisible
and
unpredictable,
which
makes
it
hard
to
iden.fy
them
as
“features”
or
“defects”
• UI
performance
considera.ons
are
largely
qualita>ve
in
nature
–
the
answer
to
the
ques.on
of
“what’s
good
enough?”
varies
widely
• Because
of
their
invisible
and
qualita.ve
nature,
UI
performance
characteris.cs
tend
to
rate
low
on
the
list
of
managers’
and
programmers’
priori.es

12. TIME
(aka
a
temporal
sequence
of
events)
What’s
so
special
about
it?
(from
a
soMware
developer’s
perspec>ve)
• Notoriously
difficult
to
handle
npredictable
.me
values
in
code
–
u
event/callback-­‐driven
asynchronous
programming
is
easy
to
screw
up
(or
is
avoided
due
to
fear
of
complexity,
lack
of
understanding)
• Race
condi.ons
• Error
handling
issues
• “Feedback
loops”
• Execu.ng
on
UI
thread
• Asynchronous
APIs
are
harder
to
understand
and
debug
• Difficult
to
pin
down
sources
of
performance
issues
• UI
toolkit
weaknesses
(e.g.
Flash,
HTML5)
• Difficult
to
judge
real-­‐world
performance
characteris.cs
because
developers’
machines
tend
to
be
high-­‐spec’d

13. So
what
can
we
do
about
it?
1. Acknowledge
that
UI
performance
characteris.cs
are
a
key
component
of
user
experience.
Designers
can’t
be
sa.sfied
with
sta.c
mockups
alone.
Developers
can’t
be
sa.sfied
with
simply
“looking
like”
a
design.
2. No
“designing
it
and
then
dropping
it
off
at
the
programmers’
feet”.
Designers
need
to
work
closely
with
developers
and
test
itera>ons
in
>ght
cycles—that’s
what
UCD
is
all
about!
3. Enough
>me
needs
to
be
devoted
to
fine-­‐tuning
UI
performance.
It
should
be
a
key
ongoing
task
for
developers
and
testers,
not
an
aqerthought.
4. Programmers
need
to
wrap
their
heads
around
asynchronous
APIs
and
event-­‐driven
programming,
if
they
haven’t
already.
5. In
cases
where
performance
can’t
be
directly
improved,
don’t
keep
the
user
wai>ng
–
show
some
kind
of
progress
indica.on,
use
cached
content
liberally,
and
don’t
block
the
UI
(thread)!

14. Thanks
for
listening!
and
now
it’s
.me
for
some
Q&A
/
discussions!
Michael
Klein
michaelklein27@gmail.com
h<p://gplus.to/michaelklein27
h<p://www.linkedin.com/in/michaelklein3
@mischkl

15. Links
Jakob
Nielsen,
Response
Times:
The
3
Important
Limits
h<p://www.nngroup.com/ar.cles/response-­‐.mes-­‐3-­‐important-­‐limits/
Jakob
Nielsen,
Website
Response
Times
h<p://www.nngroup.com/ar.cles/website-­‐response-­‐.mes/
Steven
Seow,
Designing
and
Engineering
Time
(Book)
h<p://www.engineering.me.com
Steven
Seow,
User
Interface
Timing
Cheatsheet
h<p://www.stevenseow.com/papers/UI%20Timing%20Cheatsheet.pdf
GNOME
Human
Interface
Guidelines
2.2.2,
Characteris>cs
of
Responsive
Applica>ons
h<p://developer.gnome.org/hig-­‐book/3.5/feedback-­‐responsiveness.html