User Experience Design

User Experience Design

“ I have always wished that my computer would be as easy to use as

my telephone. My wish has come true. I no longer know how to use
my telephone.”

- Bjarne Stroustrup
(originator of C++)

2
User Experience Design
• In designing software, it is
important to consider its
usability and the overall
user experience
• Is it easy to learn?
• Is it easy to use?
• Is it easy to understand?

3
User Experience Design
• Typical design errors:
• Lack of consistency
• Too much memorization
• No guidance / help
• No context sensitivity
• Poor response
• Arcane / unfriendly

4
User Experience Design Elements
• User experience design tries to ensure that no aspect of your software
appears the final product without the explicit decision to include it
• This means that every reasonable user action and expectation should be
taken into account throughout the development process
• To simplify the creation of a positive user experience, Jesse James Garrett
suggests breaking it into component elements:
• Strategy • Structure • Surface
• Scope • Skeleton

5
User Experience Design Elements 2

6
User Experience Design Elements
• For software product development, Garrett’s model can be interpreted as:
• Strategy: Identifies user needs and customer business goals that form the basis for
all UX design work
• Scope: Includes both the functional and content requirements needed to realize a
feature set consistent with the project strategy
• Structure: Consists of the interaction design (how the system reacts in response to
user action) and information architecture (the organization of content).
• Skeleton: Comprised of three components – information design (presenting content
in an understandable way), interface design (proper arrangement of interface
objects to enable interaction), and navigation design (set of elements to traverse the
information architecture)
• Surface: Presents visual design or the appearance of the finished project to its users

7
Information Architecture
• Several architectural perspectives come together here:
• Information architecture – structures that lead organization, labeling, navigation,
and searching of content objects
• Content architecture – focuses on the way content objects are structured for
presentation and navigation
• Software architecture – addresses the way the application is structured
to manage user interaction, effect navigation, and present content
• In many cases, a subject matter expert is helpful to organize the content
items for efficient traversal and use by product users

8
User Interaction Design
• Interaction design focuses on interface between a product and its user
• User interaction should be defined by the stakeholders in the user stories
created to describe how users can accomplish their goals using the
software product
• It is important to recall that the purpose of the user interface is to
present just enough information (and present it well enough) to help
users decide what their next action should be to accomplish their goal
and how to perform it

9
Usability Engineering
• Usability engineering is part of UX design work that defines the
specification, design, and testing of the human-computer interaction
portion of a software product
• This software engineering action focuses on devising human-
computer interfaces that have high usability
• If developers focus on making a product easy to learn, easy to use,
and easy to remember over time, usability can be measured
quantitatively and tested for improvements in usability

10
Usability Engineering
• Accessibility is the degree to which people with special needs are
provided with a means to perceive, understand, navigate, and
interact with computer products
• Accessibility is another aspect of usability engineering that needs to
be considered during design and is vital to removing barriers that
could impede or prevent users from successfully using their software

11
Visual Design
• Visual design (also called aesthetic design or graphic design) is an
artistic endeavor that complements the technical aspects of the user
experience design
• Without it, a software product may be functional, but unappealing
• With it, a product draws its users into a world that embraces them on
an emotional as well as an intellectual level
• Not every software engineer has artistic talent; if you fall into this
category, be prepared to hire an experienced graphic designer to help

12
The Golden Rules of User Interface Design
1. Place the user in control
2. Reduce the user’s memory load
3. Make the interface consistent

• These golden rules form the basis for a set of user interface design
principles that guide this important aspect of software design

13
Place the User in Control
• Define interaction modes in a way that does not force a user into
unnecessary or undesired actions
• Provide for flexible interaction
• Allow user interaction to be interruptible and undoable
• Streamline interaction as skill levels advance and allow the interaction
to be customized
• Hide technical internals from the casual user
• Design for direct interaction with objects that appear on the screen

14
Reduce the User’s Memory Load
• Reduce demand on short-term memory by reducing the requirement
to remember past actions, inputs, and results
• Establish meaningful defaults
• Define shortcuts that are intuitive
• The visual layout of the interface should be based on a real world
metaphor, allowing the user to rely on well-understood cues
• Disclose information in a progressive fashion, presented first at a high
level and then in detail after interest is indicated

15
Make the Interface Consistent
• Organize visual information and constrain input mechanisms according
to design rules maintained throughout the entire application
• Allow the user to put the current task into a meaningful context
• Define and implement mechanisms for navigating from task to task in a
consistent fashion
• Maintain consistency across a family of applications
• If past interactive models have created user expectations, do not make
changes unless there is a compelling reason to do so

16
User Interface Design Models
• Four different models come into play when a user interface is to be
analyzed and designed:
• User model — a profile of all end users of the system, key in adopting a
“user-centric design” methodology
• Design model — a design realization of the user model created by
software engineers
• Mental model (also known as the system perception) — the user’s mental
image of what the interface is
• Implementation model — the interface “look and feel” coupled with
supporting information that describes interface syntax and semantics

17
User Interface Design Models
• Unfortunately, these models may differ significantly
• For example, the user’s mental model may be vastly different from the
software engineer’s design model
• Also, different users might have different mental models
• The only way to reconcile these differences and get the mental image
and design model to converge is to work to understand the users
themselves, as well as how these people will use the system

18
User Interface Design Process
• The analysis and design process for user interfaces is iterative and can
be represented using a spiral model consisting of:
• Interface analysis and modeling
• Interface design
• Interface construction
• Interface validation

• These activities are typically performed more than once in the

creation of the interface

19
User Interface Design Process

20
User Interface Design Process
• Interface analysis and modeling focuses on the profile of the users
who will interact with the system
• Interface design defines a set of interface objects and actions that
enable a user to perform all defined tasks for the system
• Interface construction builds the interface, starting with prototyping
• Interface validation focuses on:
• The ability of the interface to implement every user task correctly
• The degree to which interface is easy to use and easy to learn
• The user’s acceptance of the interface as a tool in her work

21
Interface Analysis and Modeling
• In the case of interface analysis and modeling, it is important to
build a comprehensive understanding of:
1. The people (end-users) who will interact with the system
through the interface
2. The tasks that end-users must perform to do their work
3. The content that is presented as part of the interface
4. The environment in which these tasks will be conducted

22
Customer Journey Maps
• Many UX developers like to create a customer journey map as a
means of outlining their goals and plans for the software product
• This depicts how the users will experience the software as if they
were travelling on a physical trip with touchpoints (milestones),
obstacles, and ways to monitor their progress

23
Customer Journey Maps

24
Creating a Customer Journey Map
1. Gather stakeholders.
2. Conduct research. Collect all information you can about all the things users
may experience as they use the software product and define your customer
phases (touchpoints).
3. Build the model. Create a visualization of the touch points.
4. Refine the design. Recruit a designer to make the deliverable visually
appealing and ensure touchpoints are identified clearly.
5. Identify gaps. Note any gaps in the customer experience or points of friction
or pain (poor transition between phases).
6. Implement your findings. Assign responsible parties to bridge the gaps and
resolve pain points found.

25
User Personas
• User experience designers often create fictional user personas to
summarize the assumptions made for different types of users
• A particular user persona is a representation of the goals and
behaviour of a hypothesized group of users
• Personas are often synthesized from data collected during interviews
with actual or potential users
• Done properly, personas can be used to improve a product designer’s
ability to see through the eyes of target users

26
User Personas

27
User Personas
• Four tasks generally occur when creating and using personas:
• Data collection and analysis: Stakeholders collect information about
proposed product users and determine the user group needs.
• Identification and description of personas: The developers need to decide
how many personas to create and decide which persona will be their focus
• Development of scenarios: Scenarios are user stories about how personas
will use the product being developed and undertake their respective journeys
• Acceptance by stakeholders: Often this is done by validating the scenarios
using a review technique or demonstration called a cognitive walkthrough
(stakeholders assume the role defined by a persona and work through a
scenario using a system prototype)

28
Task Analysis
• Remember that the user’s goal is to accomplish one or more tasks via
the user interface; to accomplish this, the user interface must provide
mechanisms that allow the goal to be achieved
• The goal of task analysis then is to answer the following questions:
• What work will the user perform in specific circumstances?
• What tasks and subtasks will be performed as the user does the work?
• What specific problem domain objects will the user manipulate as work is
performed?
• What is the sequence of work tasks—the workflow?
• What is the hierarchy of tasks?

29
Task Analysis
• Use cases are used to show how an end user performs some specific
work-related task
• Task elaboration refines interactive tasks to assist in understanding
the human activities the user interface must accommodate
• Object elaboration identifies interface objects (classes) that must be
supported from analysis classes from requirements engineering
• Workflow analysis defines how a work process is completed when
several people (and roles) are involved

30
Task Analysis

A swimlane diagram for a prescription refill function.

Swimlane diagrams can be useful for capturing
workflows by indicating the tasks and decisions for
each of the user roles involved in the workflow. In
this instance, we have physicians, pharmacists, and
patients involved in the process, and so we have a
separate lane for each of them.

31
Content Analysis
• During this analysis step, the format and aesthetics of the content (as
it is displayed in the user interface) are considered:
• Are different types of data assigned to consistent geographic locations on the
screen (e.g., photos always appear in the upper right hand corner)?
• Can the user customize the screen location for content?
• Is proper on-screen identification assigned to all content?
• If a large report is to be presented, how should it be partitioned for ease of
understanding?
• Will mechanisms be available for moving directly to summary information for
large collections of data?

32
Content Analysis
• During this analysis step, the format and aesthetics of the content (as
it is displayed in the user interface) are considered:
• Will graphical output be scaled to fit within the bounds of the display device
that is used?
• How will color to be used to enhance understanding?
• How will error messages and warnings be presented to the user?

• The answers to these (and other) questions will help establish

requirements for content presentation

33
Work Environment Analysis
• “People do not perform their work in isolation. They are influenced
by the activity around them, the physical characteristics of the
workplace, the type of equipment they are using, and the work
relationships they have with other people.”
• Consequently, it is important to understand the work environment
that the software will be deployed in and how this will impact or
constrain the design of the user interface

34
Interface Design

As with most things software,

an iterative approach to interface
and user experience design is
likely the best

35
The Google 5-Day Design Sprint
• Google has defined a 5-day sprint for interface and UX design, with
each of the following steps allocated one day:
1. Understand. User research activities (user needs and business goals) are
conducted for the software product. This information (for example,
customer journey maps, personas, user task workflow) is posted for easy
reference throughout the sprint.
2. Sketch. Individual stakeholders are given the time and space needed to
brainstorm solutions to the problems discovered in the understand phase.
Paper drawings and notes are easy to generate, easy to modify, and quite
inexpensive. They can be digitized and disseminated as necessary.

36
The Google 5-Day Design Sprint
• Google has defined a 5-day sprint for interface and UX design, with
each of the following steps allocated one day:
3. Decide. Each stakeholder presents their solution sketch and the team votes
to determine the solutions that should be tackled in the prototyping
activities that will follow. If there is not a clear consensus following the
voting, the development team may decide to consider assumptions that
involve project constraints and resources.
4. Prototype. May be a minimally viable product based on the solution
selected from the sketch phase, or it may be based on the portions of the
customer journey map or storyboard you want to evaluate with potential
users in the validate phase.

37
The Google 5-Day Design Sprint
• Google has defined a 5-day sprint for interface and UX design, with
each of the following steps allocated one day:
5. Validate. Every developer watches users try out the prototype. This is the
best way to discover major issues with its UX design, which in turn lets you
start iterating immediately. This is critical to capturing potential learning
opportunities by exposing product decision makers to user feedback in real
time.

38
Interface Construction
• Interface construction normally begins with the creation of a
prototype that enables usage scenarios to be evaluated
• In most cases, the construction activity involves prototyping, as that is
the only practical way to validate what has been designed
• Initial prototypes might be simple sketches or high-level mockups,
followed by more detailed and interactive mockups
• Later prototypes might be constructed using some kind of user
interface tool kit, preferably what will be used in the implementation
of the software system as a whole

39
Interface Validation
• Once an operational user interface prototype has been created, it must
be evaluated to determine whether it meets the needs of the user
• Interface validation focuses on:
1. The ability of the interface to implement every user task correctly, to
accommodate all task variations, and to achieve all general user requirements
2. The degree to which the interface is easy to use and easy to learn
3. The user’s acceptance of the interface as a useful tool in her or her work

40
Interface Validation

41
Interface Validation
• Can an interface design be evaluated before a prototype is built? These
criteria can be applied during early design reviews:
• The length and complexity of the requirements model or written specification of the
system and its interface provide an indication of the amount of learning required by
users of the system
• The number of user tasks specified and the average number of actions per task
provide an indication of interaction time and the overall efficiency of the system
• The number of actions, tasks, and system states indicated by the design model imply
the memory load on users of the system
• Interface style, help facilities, and error handling protocol provide a general
indication of the complexity of the interface and how it will be accepted by the user

42
Effective User Interfaces
• Effective interfaces are visually apparent and forgiving, instilling in
their users a sense of control; users quickly see the breadth of their
options, grasp how to achieve their goals, and do their work
• Effective interfaces do not concern the user with the inner workings
of the system; work is carefully and continuously saved, with full
option for the user to undo any activity at any time
• Effective applications and services perform a maximum of work, while
requiring a minimum of effort from users

43
Usability Guidelines
• Anticipation—Software should be designed so that it anticipates the
user’s next move
• Communication—The interface should communicate the status of any
activity initiated by the user
• Consistency—The use of navigation controls, menus, icons, and
aesthetics (e.g., color, shape, layout)
• Controlled autonomy—The interface should facilitate user movement
throughout the software, but it should do so in a manner that enforces
navigation conventions that have been well established

44
Usability Guidelines
• Efficiency—The design of the software and its interface should
optimize the user’s work efficiency, not the efficiency of the software
engineer who designs and builds it or the environment that executes it
• Flexibility—The interface should be flexible enough to enable some
users to accomplish tasks directly and others to explore the application
in a somewhat random fashion
• Focus—The user interface (and the content it presents) should stay
focused on the user task(s) at hand

45
Usability Guidelines
• Human interface objects—A vast library of reusable human interface
objects has been developed for software already; use them to leverage
recognizable and already proven interface elements
• Latency reduction—Rather than making the user wait for a lengthy
operation to complete, the software should use multitasking in a way that
lets the user proceed with work as if the operation has been completed
• Learnability— A user interface should be designed to minimize learning
time, and once learned, to minimize relearning required when the
software is later revisited

46
Usability Guidelines
• Metaphors—An interface that uses an interaction metaphor is easier to
learn and easier to use, as long as the metaphor is appropriate for the
application and the user
• Readability—All information presented through the interface should be
readable by young and old
• Track state—When appropriate, the state of user interaction should be
recorded so that a user can logoff and return later to resume their tasks
• Visible navigation—A well-designed interface provides “the illusion that
users are in the same place, with the work brought to them”

47
Accessibility Guidelines
• Application Accessibility—Software engineers must ensure that interface
design encompasses mechanisms that enable easy for people with special
needs
• Response Time—System response time has two important characteristics:
length and variability; aim for consistency to avoid user frustration
• Help Facilities—Modern software should provide online help facilities that
enable a user to get a question answered or resolve a problem without
leaving the interface

48
Accessibility Guidelines
• Error Handling—Every error message or warning produced by an
interactive system should:
• Use user understandable jargon
• Provide constructive error recovery advice
• Identify negative consequences of errors
• Contain an audible or visual cue
• Never blame user for causing the error

49
Accessibility Guidelines
• Menu and Command Labeling—The use of window-oriented, point-and-
pick interfaces has reduced reliance on typed commands; in cases where
command or menu-oriented approaches are still used, it is important to:
• Ensure every menu option has a command version
• Make commands easy for users to type
• Make commands easy to remember
• Allow for command abbreviation
• Make sure menu labels are self-explanatory
• Make sure submenus match style of master menu items
• Ensure command conventions work across the family of applications

50
Accessibility Guidelines
• Internationalization—Software engineers and their managers invariably
underestimate the effort and skills required to create user interfaces that
accommodate the needs of different locales and languages

51