1. Role
of
an
Architect
in
Software
Usability
Engineering
Thina
Kesavan
Senior
Software
Architect

2. The
world
is
littered
(or
cluttered,
I
should
say)
with
articles
and
essays
written
about
various
aspect
of
software
usability.
What
I
have
tried
here
is
to
give
a
comprehensive
coverage
of
all
aspects
that
a
software
architect
should
look
at
when
designing
software.
My
goal
is
to
reassure
that
software
usability
is
an
integral
part
of
any
software
development
program
in
organizations
that
develop
products
for
users
and
that
software
usability
can
never
be
an
after
thought.
In
fact
there
are
businesses
thrive
today
just
by
beating
the
competition
with
just
a
better
usability
in
their
software.
Organizations
that
does
take
usability
seriously
and
establish
dedicated
programs
with
usability
experts,
sometime
fails
to
realize
the
goals
for
various
reasons.
This
essay
focuses
on
one
such
a
reason.
Hence
the
title:
Designing
for
usability.
Organizations
fails
because,
there
isn’t
a
dedicated
bridge
that
crosses
the
usability
and
software
development
departments.
A
software
architect
who
is
dedicated
to
software
usability
could
be
that
bridge.
They
must
know
the
users,
domain,
usability
tactics,
and
know
the
technologies
required
to
achieve
the
usability
goals.
They
should
be
able
to
architect,
design
and
code.
That
should
be
their
only
focus
fulltime.
This
essay
can
be
treated
as
guidance
document
for
those
who
play
the
role
of
that
bridge.
What
is
the
usability?
Lets
see
what
we
get
from
some
sources:
“Usability
is
a
measure
of
how
easy
to
use
a
product
to
perform
prescribed
task”
-­‐
Microsoft.
“The
extent
to
which
a
product
can
be
used
by
specified
users
to
achieve
specified
goals
with
effectiveness,
efficiency,
and
satisfaction
in
a
specified
context
of
use”
–
ISO
9241
“In
order
for
the
software
to
be
useful,
the
software
must
satisfy
the
following:
Efficient,
Effective,
Engaging,
Error
Tolerant
and
Easy
to
Learn.
(Whitney
Quesenbery)”
There
are
two
kinds
of
users:
The
internal
users
and
end
users.
The
internal
user
includes
the
User
Experience
Researchers,
Information
Designers,
Usability
Testers,
Software
Developers,
Architects,
Business
analysts
and
Software
Testers.
There
are
other
internal
users
who
typically
do
not
take
part
in
how
the
product
is
being
built,
for
example,
product
service
technicians.
However,
organizations
should
include
them
in
the
process
and
make
them
as
well
responsible
for
the
product
outcome.
At
the
end
there
can
be
only
two
kinds
of
users:
The
end
users
who
pay
for
your
product
and
the
internal
users
who
gets
paid
to
develop
the
product.

3. From
the
end
user’s
perspective,
it
is
all
about
how
usable
the
software
is.
It
is
about
how
easy
for
the
end
user
to
exercise
its
features,
how
intuitive
to
work
through
and
how
easy
it
is
to
learn.
What
is
your
responsibility?
It
is
how
the
internal
user
approach
the
usability
will
influence
what
the
external
users
get
at
the
end.
It
is
how
the
requirements
are
developed,
its
how
the
software
is
designed,
its
how
the
software
is
developed
and
tested
will
impact
the
usability
of
the
software.
You
are
the
one
who
play
an
important
role
in
gluing
together
all
these
discipline
in
achieving
usable
software.
You
play
a
key
role
in
making
sure
that
the
software
is
usable
to
the
target
customer.
After
all,
if
the
software
is
not
usable,
then
all
the
effort
went
into
development
of
the
software
would
be
useless.
Usability
of
the
software
is
a
broad
term
in
software
development
and
several
quality
attributes
contributes
to
the
overall
software
usability.
For
example,
if
the
software
doesn’t
meet
the
performance
quality
attribute
then
will
most
likely
not
usable.
If
the
software
is
not
reliable,
then
the
user
may
not
use
it.
If
software
is
not
flexible,
then
it
may
not
be
usable
and
so
on.
Overall
the
usability
of
the
software
can
be
achieved
by
making
sure
that
the
software
is
easily
understandable,
learnable,
operable,
and
attractive.
Understandable:
The
software
must
be
relevant
to
the
customer
domain
and
speak
the
language
of
the
customer.
The
workflow
of
the
software
should
be
simple
and
straightforward.
Learnable:
The
software
should
be
easy
to
use
and
intuitive.
User
should
be
able
to
learn
the
feature
easily
and
quickly.
Operable:
The
user
should
be
able
to
operate
the
software
under
all
uses
cases
of
the
system.
The
software
must
be
responsive
and
the
software
must
give
feedback
appropriately
through
textual
or
visual
cues.
The
user
should
be
able
to
access
all
desired
functionalities
with
ease.
Attractive:
The
user
should
enjoy
working
with
the
software.
The
look
and
feel
of
the
software,
the
usage
of
the
colors
and
the
size
of
text
should
complement
each
other
and
give
pleasant
experience.
What
are
the
usability
activities
that
you
must
be
part
of?
Before
involving
in
any
usability
activities,
you
must
understand
the
user
and
the
usability
requirements.
This
understanding
will
enable
the
architect
to
be

4. part
of
usability
testing,
usability
assessment
and
usability
interviews.
Involving
in
each
of
this
activity
will
help
you
translate
the
findings
into
the
software
architecture
and
design.
Understanding
the
user
and
usability
requirements:
To
understand
the
user
and
the
usability
requirement
for
the
product,
you
must,
Know
the
user:
To
understand
the
usability
requirements,
the
architect
must
first
know
who
the
end
users
are,
including
their
demographics,
gender
division,
and
the
cultural
distribution.
Unless
you
are
developing
software
for
mass
consumers
or
in
social
media,
you
probably
targeting
a
specific
user
in
a
specific
domain
and
you
should
know
them
well.
Know
the
environment:
To
create
better
user
experience,
you
must
first
know
where
the
software
will
be
used.
For
example,
developing
software
that
will
be
used
in
a
dark
lab
is
different
than
developing
software
for
the
kiosks
in
the
shopping
malls.
Similarly,
you
must
also
take
the
users
location,
culture
and
language
into
account.
Know
the
domain:
To
develop
software,
you
must
know
the
domain
well.
For
example,
developing
an
office
productivity
tool
is
different
than
developing
an
aerospace
application.
Understand
the
user
requirement:
Understand
the
customer
requirement.
In
certain
domain,
you
can’t
create
software
that
is
so
generic.
For
example,
we
can’t
use
software
developed
for
ocean
transport
industry
in
ground
transportation
industry
even
though
they
both
are
transportation.
Sometime
implementation
of
business
software
such
as
SAP
fails
in
organizations
because
users
are
no
longer
tolerating
poor
usability.
Know
the
competitive
advantage:
This
is
very
important
as
sometime
the
only
reason
customer
may
buy
your
software
is
the
differentiating
usability
features
that
you
provide
beyond
the
core
business
features.
Architect’s
involvement
in
Usability
testing:
Usability
testing
typically
involves
letting
the
users
use
the
system
in
a
working
state
and
gather
their
feedback.
You
must
participate
in
the
usability
testing
and/or
review
the
usability
testing
outcomes.
The
following
are
the
typical
activities
when
working
with
a
usability
analyst.
Help
decide
what
to
test:
While
the
usability
analyst
is
more
focused
on
the
easy
of
the
use,
you
must
focus
on
non-­‐functional
requirements
of
the
system
such
as
performance
and
responsiveness.
You
must
guide
the
team
to
test
certain
quality
of
the
system.

5. Help
prepare
for
testing:
With
the
help
of
development
team,
you
should
help
prepare
for
the
usability
testing.
You
should
help
the
usability
engineer
to
decide
what
data
to
include
in
the
system,
what
test
cases
to
execute,
what
are
the
critical
tasks
and
what
are
the
specific
problem
areas.
Help
conduct
the
testing:
You
should
help
the
usability
engineer
to
define
what
data
to
capture,
how
to
capture
such
a
way
that
the
data
can
be
used
is
designing
the
software
or
evolve
the
design.
You
can
also
help
in
defining
the
workflow
for
the
testing.
Participate
in
usability
testing:
Participating
in
usability
studies
and
getting
first
hand
impression
is
very
important.
It
will
be
useful
to
know
what
is
difficult
to
use
in
the
software,
what
is
liked
and
what
is
disliked
in
the
software.
Architect’s
involvement
in
Usability
interviews:
Usability
interviews
will
not
be
useful
if
wrong
questions
are
asked
to
the
users.
Help
with
user
interviews/Surveys:
You
must
help
the
usability
analyst
ask
the
right
questions
to
the
user.
Sometime
users
do
not
know
what
they
want,
however,
when
they
hear
it,
when
they
see
it,
they
would
be
able
to
decide.
You
can
help
the
usability
expert
by
letting
them
know
upfront
what
more
you
can
provide
in
the
software.
The
main
goal
for
an
architect
is
to
get
the
feedback
that
can
be
translated
into
architecture
tactic.
Help
with
proactive
field
study:
You
must
think
how
to
build
the
user’s
feedback
mechanism
into
the
software
itself.
The
software
then
can
collect
the
feedbacks
proactively
which
can
help
in
evolving
the
architecture
and
improve
software
for
future
releases.
Architect’s
involvement
in
the
Usability
assessment:
When
it
is
time
to
analyze
the
result
of
the
usability
study,
your
involvement
is
key
in
translating
the
result
to
implementable
tasks.
Find
key
takeaways
from
the
testing:
There
may
be
a
lot
of
takeaways
from
the
feedback
from
the
users.
Since
the
usability
means
different
things
to
different
users,
it
is
very
important
to
filter
out
the
noises
and
take
away
the
important
feedback.
Prioritize
the
issues
from
the
findings:
You
must
assess
the
issues
and
prioritize
them
based
on
the
severity
for
implementation.
There
may
be
a
very
significant
usability
issue
that
requires
changes
to
the
architecture
that
must
be
addressed
quickly
and
effectively.

6. Derive
architecturally
significant
usability
requirements:
Based
on
the
assessment,
you
must
derive
design
tactics
that
are
strategic
as
well
as
tactics
in
nature.
Deliverables:
The
following
deliverable
are
required
to
make
sure
that
the
product
meets
the
end
users
usability
requirement.
These
deliverable
are
primary
responsibility
of
usability
engineering
team.
As
an
architect,
you
must
take
input
from
these
artifacts.
Usability
Requirements:
The
product
must
have
an
explicitly
identifiable
usability
requirement.
This
will
help
determine
what
the
user
value
most
and
how
this
will
help
the
user
get
the
job
done
in
the
most
efficient
manner.
End
user
case
study:
This
will
give
a
picture
on
who
the
user
is,
how
the
user
use
the
software,
what
is
the
typical
background
of
the
users,
their
skill
levels
and
so
on.
This
will
help
in
designing
simple
and
usable
system.
High-­‐level
work
flow
and
story
boards:
This
is
often
the
first
glimpse
that
the
stakeholders
see
how
the
software
product
is
shaping
up.
The
storyboard
helps
visualize
the
workflow
and
helps
in
reviews
and
gets
early
feedback.
User
experience
style
guide:
User
experience
guide
defines
the
user
interface
and
workflow
paradigm
of
the
software
that
must
be
followed
when
designing
and
developing
the
system
to
provide
consistent
user
experience.
Usability
test
report:
Usability
test
report
will
help
to
give
a
picture
of
what
kind
of
issue
that
end
user
facing
and
how
to
mitigate
such
issues.
User
profile
report:
A
set
of
user
profile,
summarizing
the
key
properties
of
the
user
group.
This
will
allow
determining
the
different
levels
of
user
workflows
and
varying
complexities
that
can
be
introduced
in
the
system.
For
example,
this
will
help
in
designing
various
user
login
levels
such
as
beginner
level
to
advanced
user
level.
There
are
several
other
deliverables
including
information
architecture,
interaction
design,
visual
design
and
prototyping
that
can
help
assure
that
you
are
meeting
end
users
usability
requirements.

7. Design
guidelines:
Designing
for
usability
is
one
of
the
most
challenging
aspects
of
the
software
development.
Having
a
good
usability
may
be
better
than
having
less
functionality
but
having
more
functionalities
and
a
bad
usability
can
result
in
failures.
It
is
the
responsibility
of
the
architect
to
consider
all
the
facts
involved
in
end
user
acceptance
of
the
system
and
prepare
from
the
beginning.
Usability
is
one
of
the
quality
attribute
that
architecture
should
address,
however,
there
are
several
other
quality
attributes
need
to
be
addressed
to
meet
the
usability
quality.
In
the
traditional
approach
to
software
development,
one
of
the
primary
concerns
typically
is
that
‘Architecture
restricts
the
usability’.
This
is
because,
the
usability
issues
are
discovered
only
towards
the
end
of
the
project
due
to
unavailability
of
a
working
system
at
the
beginning
and
not
all
the
requirements
are
finalized
and
evolved
throughout
the
project.
The
traditional
software
architectural
response
to
repeated
and
expected
modifications
to
the
user
interface
is
to
use
separation
and
encapsulation.
Following
are
the
overall
design
guidelines
that
will
help
meet
the
end
users
acceptance
of
the
software.
To
safeguard
the
software
architecture
from
continuously
changing
usability
needs,
or
to
make
architecture
flexible
to
accept
late
breaking
change,
the
architecture
and
the
designs
followed
by
it
must
meet
the
quality
attributes:
Flexibility,
Modifiability,
and
Extendibility.
Following
are
some
of
the
design
guidelines
that
will
help
ensure
the
acceptance
of
the
software
by
the
end
user.
1. Separate
the
UI
from
the
rest
of
the
system.
The
UI
workflow
and
visual
changes
should
not
impact
the
rest
of
the
system.
MVC
(or
one
of
the
extension
such
as
MVVM)
would
be
a
typical
pattern.
2. Layered
architecture
–
separate
the
UI
layer
from
the
rest
of
the
components
in
the
system.
The
UI
layer
can
change
all
the
time
that
should
not
affect
the
entire
system.
This
will
also
help
with
prototyping
with
dummy
data
for
the
user
experience
study.
3. Configurable
/
customizable:
Make
sure
that
the
software
is
customizable
and
configurable.
User
should
be
able
to
customize
the
software
for
their
need
to
get
the
work
done
faster
and
most
efficient

8. manner.
Ability
to
add
and
remove
features
using
Plug-­‐in
pattern
is
one
of
the
examples
for
such
architecture.
4. Responsive
user
interface
–
Make
user
interface
highly
responsive.
User
action
should
have
immediate
feedback
regardless
how
long
the
total
task
will
take
to
complete.
Asynchronous
calls,
background
threads,
delayed
or
lazy
loading
are
some
of
the
design
tactics
to
employ
that
provides
responsive
user
interface.
5. Error
prevention
and
handling
–
Design
in
such
a
way
that
the
user
can’t
make
mistake.
In
case
error,
system
should
recover
from
it.
Handling
right
exceptions
and
graceful
recovery
are
some
of
the
examples.
6. Performance:
Present
the
data
quickly
with
immediate
feedback
for
the
user
action.
Fetching
only
minimum
necessary
data
and
upon
user
request
loading
further
data
is
a
potential
design
approach.
7. Use
industry
standard
design
patterns
and
user
style
guidelines
for
usability
as
much
as
possible.
8. Establish
certain
visibility
of
the
architecture
to
the
end
user:
Making
certain
aspect
of
the
architecture
visible
to
the
end
user
helps
them
understand
the
product
little
better.
This
is
especially
helpful
in
the
medical
equipment
products
where
there
are
several
layers
of
end
users
such
as
systems
engineers,
service
engineers,
lab
managers
and
the
operators.
The
service
engineers
often
need
to
know
certain
architecture
elements
to
successfully
install
the
system
at
the
customer’s
site.
9. Select
right
technology:
Choice
of
technology
plays
a
major
role
in
the
end
use
acceptance.
The
choice
of
UI
framework,
communication
protocols,
database
capabilities
and
operating
systems
are
all
major
contributors
towards
the
end
user
acceptance
of
the
system.
End
user
acceptance
and
the
software
architecture:
For
the
most
case,
the
software
architecture
has
to
play
a
key
role
in
the
end
user
acceptance
of
the
software.
Well-­‐architected
software
is
flexible,
modifiable
and
extendable
to
the
users
need.
Instead
of
conducting
usability
testing
at
the
end
of
the
software
development,
the
architecture
must
be
evaluated
against
the
usability
requirement
and
revised
multiple
times
during
the
development
of
the
software.
End
user
should
be
involved
as
much
as
possible
from
the
very
beginning
of
product
development
and
the
user
input
should
shape
the
architectural
development.

9.
Platform
software
consideration:
All
the
aspects
discussed
in
the
above
sections
are
all
applicable
for
platform
software
development.
In
addition
to
those
aspect,
the
platform
software
has
additional
requirements
such
as
common
user
experience
across
several
products
in
the
product
line,
additional
concerns
related
to
meeting
more
than
one
type
and
demographics
of
the
customer
and
additional
efforts
involved
in
considering
potentially
different
workflows
between
multiple
products
in
the
product
line.
The
usability
studies
may
involve
customers
of
different
products
and
deliverables
are
tailored
for
each
product
in
the
product
line.