Achieving Usability and A Great User Experience For Enterprise Software Products - Presented at ProductCampAustin09, 15 August 2009.

1. Paul Sherman
Sherman Group User Experience

2. 1. The
enterprise
app
vendor’s
lament…
2. And
the
silver
lining
3. Know
thy
user…but
more
importantly,
know
thy
user’s
problems
4. Buyers…how
to
push
on
your
vendors
2

3. 3

4. It’s
HARD
to
change
enterprise
software
applications!
Why?
4

5. Big
fat
releases
Big
fat
customers
=
multiple
squeaky
wheels
Customization
Embedded
in
customers’
workflows
5

6. 6

7. There
are
leverage
points
for
improving
the
user
experience
of
enterprise
software.
7

8. Captive
users…
You
have
an
opportunity
to
improve
the
user
experience
without
immediately
losing
the
user
base.
8

9. It’s
almost
always
about
workflow…
If
you
improve
the
workflow,
you
improve
the
user
experience.
And
you
make
your
customer
very,
very
happy.
9

10. 10

11. If
you’re
going
to
improve
your
app,
you
have
to
know
what
you’re
solving
for!
11

12. Your
boss/VP/CEO:
“We
need
to
make
the
product
more
usable!”
You:
“In
what
particular
areas
are
users
having
trouble?”
Boss:
“It
just
needs
to
be
easier
to
use!”
12

13. Usability
means
different
things
in
different
contexts.
It’s
all
about
the
users’
needs
and
goals.
Do
you
need
to
solve
for…
Learnability?
Memorability?
Efficiency?
Error
prevention?
13

14. Learnability
Sa3sfac3on
Memorability
Usability
Error
Preven3on
Produc3vity
Shneiderman,
B.
(1998).
Designing
the
User
Interface.
Reading,
MA:
Addison
Wesley
Longman

15. Ask
yourself:
Do
you
*know*
what
the
users’
problems
really
are?
15

16. A
story
about
an
expense
reporting
application…
…built
for
the
wrong
context
and
wrong
users.
16

17. Vendor
X
built
an
expense
reporting
app.
The
little
bit
of
research
they
did
was
flawed…
They
interviewed
executives,
execs’
admins,
and
finance/accounting
staff
to
determine
the
workflow
and
terminology.
17

18. Accounting/finance:
Thought
in
financial
terms.
Cost
centers,
allocations,
etc.
Execs:
Frequent
travelers.
Wanted
quick
and
efficient
expense
report
entry
for
their
admins.
18

19. So,
Vendor
X
made
the
application
quick
and
efficient...with
loads
of
accounting
and
finance
terminology.
19

20. What
do
you
think
happened?
20

21. The
application
worked
great
for
exec
admins
and
accounting…
But
for
the
95%
of
users
who
weren’t
in
these
groups…it
sucked.
21

22. Most
users
(technical
staff
and
first-­‐line
managers)
traveled
1x
per
quarter
or
less.
They
forgot
how
to
use
the
app
between
trips.
And
the
finance
terminology
made
no
sense
to
them.
22

23. Lots
of
expense
report
errors
The
books
were
screwed
up
Reduced
productivity
for
majority
of
users
Non-­‐compliance
Frustration
23

24. OK,
we
get
it.
Now
give
us
some
guidance!
24

25. Always
discover
the
context
of
use!
Who’s
going
to
use
the
app
most
(and
least)
How
often
Why
What
else
they
do
✔
✖
25

26. Don’t
just
take
the
buyer’s
word
for
it…
especially
if
it’s
the
IT/IS
group.
Sorry!
But
it’s
true.
26

27. Before
you
redesign
anything,
identify
the
problems…
Is
it
navigation?
(“I
can’t
find
how
to…”)
Is
it
workflow?
(“This
takes
too
long.”)
Is
it
mental
model?
(“I
don’t
know
what
you’re
asking
me
to
do
or
why.”)
27

28. Usability
test
it
before
releasing
it.
My
favorite
product
manager
referred
to
usability
testing
as
“decision
insurance.”
It’s
2009…do
I
really
need
to
say
this?
28

29. Vendors
in
the
house?
Discuss.
29

30. 30

31. Buyers!
Your
technology
selection
processes
are
incomplete.
You’re
not
assessing
the
user
experience
of
the
technology
you
buy.
You’re
incurring
huge
hidden
costs.
You’re
letting
enterprise
vendors
get
away
with
building
products
with
poor
usability.
31

32.  The
enterprise
identifies
the
need
for
a
better,
more
scalable,
or
faster
process,
and
makes
the
business
case
for
deploying
a
new
application.
 The
IT
org
sets
technical
and
feature
requirements…that
are
often
informed
by
vendors’
feature
lists.
 Purchasing
solicits
vendors.
 Purchasing
evaluates
vendors
on
the
basis
of
their
responses
and
generates
a
short
list
of
possible
vendors.
 IT
brings
vendors’
systems
into
the
enterprise’s
test
labs
for
performance
and
technical
trials.
 The
enterprise
selects
a
vendor.
 IT
deploys
the
new
application.
 Employees
freak
out
to
varying
degrees.
32

33. Where
was
the
workflow
analysis?
The
usability
testing?
33

34. 1. Identify
and
describe
the
target
user
groups
that
currently
perform
the
task
or
process
the
software
will
automate.
Make
sure
you
know
their
characteristics,
motivations,
and
work
context.
34

35. 2. Model
and
describe
the
current
workflow
the
target
users
employ
to
accomplish
the
task
or
process.
Use
simple
methods
like
task
analysis
and
time-­‐on-­‐task
measurement.
35

36. 3. Discover
what
the
target
users
typically
do
before
and
after
the
task
being
automated.
This
will
give
you
an
understanding
of
whether
you
can
automate
the
task’s
precursors
and
antecedents
or
somehow
include
them
in
the
potential
solution.
36

37. 4. Then
assess
the
technology
solutions
for
their
goodness-­‐of-­‐fit
to
the
context,
tasks
and
workflow
of
the
target
users.
37

38. Feature
comparisons
and
demos
matter
a
whole
lot
less
than
actually
putting
real
users
on
the
application
and
having
them
perform
tasks.
38

39. Enterprise
buyers?
Do
you
assess
usability?
39

40. Paul
Sherman
Sherman
Group
User
Experience
www.shermanux.com
paul@shermanux.com
Twitter:
pjsherman
40