The document discusses principles for creating user-centric interface design. It argues that software teams often focus only on functionality without considering user experience. A good design considers the user and how the interface portrays the functionality. The document outlines several principles for interface design, including observing how everyday objects are used, understanding user needs and constraints, keeping designs simple, speaking in the user's language, and being tolerant of errors. It emphasizes that good design evolves from understanding the user and intended usage.
2. Opera%on
Successful,
Pa%ent
Dead
So=ware
development
teams
o=en
focus
on
just
the
func%onality
and
claim
victory
when
the
so=ware
does
what
it
claims
to
do.
User
experience
is
o=en
forgoDen
or
else
patched
on
top
of
the
func%onality
as
an
“add-‐on”.
This
is
akin
to
a
doctor
saying,
the
opera%on
is
successful
but
the
pa%ent
is
dead.
If
Func%onality
is
King,
Experience
is
Queen
!
3. Basic
UI
Philosophy
UI
is
a
map
that
helps
you
understand
the
territory.
The
map,
however,
is
not
the
territory.
UI
is
not
the
real
func%onality.
Differently
put,
UI
is
just
a
window
to
the
actual
func%onality.
The
key
insight
is
that
the
window
impacts
your
percep%on
of
the
actual
world.
The
art
of
UI
lies
in
choosing
a
window
that
portrays
the
actual
func%onality
in
its
fullest
effect.
4. Observe
the
UI
of
Everyday
Things
These
pictures
reveal
something
interes%ng
about
UX
design
from
the
everyday
world.
Users
make
use
of
things
in
unexpected
ways
because
the
design
‘affords’
those
unexpected
usages.
This
is
called
“affordance”
in
design
lingo.
Examples:
Many
of
us
hang
coats
on
a
fire
hydrant.
Washing
machines
are
used
to
make
Lassi
in
Punjab.
Who
hasn’t
seen
clothes
hanging
on
a
gym
equipment?
5. Observe
the
design
Here
is
something
we
have
used
in
our
daily
lives
:
A
Bicycle.
Let
us
try
to
answer
a
few
ques%ons
now
about
its
design:
a. What
is
the
ideal
user
experience
for
a
bicycle?
b. Is
this
design
good?
c. What
design
improvements
would
you
make
to
improve
it?
Think
for
some%me
before
proceeding.
6. Think
About
The
User
and
The
Usage
Those
were
trick
ques%ons
!
If
you
tried
to
come
up
with
a
beDer
design
without
asking
for
more
informa%on,
you
are
making
a
mistake.
Some
key
ques%ons
you
have
to
ask
before
aDemp%ng
to
redesign:
1.
Who
is
going
to
use
the
cycle?
Kids?
Men?
Women?
Athletes?
2.
What
kind
of
cycle
is
it?
Mountain
bike,
City
bike,
Casual
bike?
Remember,
UI/UX
decisions
should
evolve
from
the
user
and
the
usage.
7. More
Daily
Examples
There
are
cars
where
the
window
controls
are
closer
to
the
gear
box.
Why
do
you
think
the
designers
chose
to
put
the
controls
there?
Maybe
because
if
you
put
them
in
the
center,
the
passenger
can
also
control
it?
Now,
what
are
the
downsides
of
that
choice?
The
interface
and
the
object
are
separated
and
can
cause
confusion.
This
is
another
classic.
We
have
all
experienced
this
one.
There
are
8
switches.
Which
one
turns
on
the
fan?
We
can
learn
this
only
through
trial
and
error.
This
approach
may
not
be
feasible
in
mission
cri%cal
applica%ons.
How
do
you
solve
this?
Using
labels?
Diagrams?
Placing
the
UI
close
to
the
object?
8. Constraints
Drive
Design
Decisions
Design
should
take
constraints
into
considera%on.
In
a
Formula
1
car,
the
driver
is
zooming
at
crazy
speeds
and
cannot
take
his
hands
off
the
wheel.
Hence
controls,
mostly
buDons
and
flip
switches,
are
within
the
reach
of
the
thumb.
Here
is
an
example
from
the
so=ware
world.
If
the
bandwidth
of
the
users
is
poor,
you
cannot
afford
to
have
super-‐
rich
graphics
in
your
design.
You
are
forced
to
think
of
simpler
alterna%ves.
9. Simplicity
:
The
Nirvana
State
As
the
complexity
of
the
system
grows,
so
does
the
complexity
of
the
UI.
The
challenge
for
the
designer
is
to
keep
the
UI
simple
even
when
the
system’s
complexity
soars.
Google
homepage
is
a
great
example
for
brilliant
simplis%c
design
which
masks
the
underlying
complexity
of
the
system.
Click
wheel
of
the
iPod
is
another
example
that
comes
to
mind.
The
Goal
UI
Complexity
<
System
Complexity
10. Speak
in
the
User’s
Language
We
have
all
been
subjected
to
this.
Many
a
%mes,
messages
are
machine
readable,
not
human
readable.
Feedback
for
user
ac%ons
should
be
friendly,
%mely
and
ac%onable.
11. Be
Tolerant
to
Errors
To
Err
is
Human.
System
designers
should
keep
this
in
mind
and
protect
users
in
case
of
a
failure.