User Experience Design for Embedded Devices

© Integrated Computer Solutions, Inc. All Rights Reserved
User Experience Design for Embedded
Devices
Part 1

Presented By
Jeff LeBlanc
• Director of User Experience @ ICS
• Software developer for 20+ years
• Certified Qt trainer since 2003
• Adjunct faculty at WPI teaching HCI
Contact me: jeffl@ics.com

About ICS
• ICS is the largest Qt professional services firm in North America.
• ICS provides embedded, mobile, and desktop consulting services for Qt,
multi-touch applications and GUI application development.
• Includes a cross-functional User Experience team
• Focus on delivering high-quality, implement-able, designs
• Visit www.ics.com for more info and free training videos.

Agenda
• Why and what of Embedded and Mobile UX
• Personas, Scenarios, and Information Architecture
• Lunch
• Design Principles and Guidelines
• User Testing and Prototyping
• Wrap-up, Q&A

Story Time
Set the wayback machine to 1979
US president
Jimmy Carter, who created the Department of Energy
Notable movies
Alien, Star Trek: TMP, The China Syndrome
Notable events
Margaret Thatcher
Pioneer 11 visits Saturn
Three Mile Island disaster

Three Mile Island
• Nuclear power plant in Harrisburg, Penn.
• Cost to build: $700 M US dollars
• Only functioned at full power for 4 months
• Meltdown began at 4am, March 28th
• Cost to clean up: $973 M US dollars
• Not decommissioned yet
• Cause: “human error”

Recipe for Disaster
• Problems began at 4am, low point in human circadian cycle
• Valve was left closed at end of previous shift that needed to be open
• More than 100 alarms went off at once
• No way to shut off less important ones
• Printer was recording events
• Two hours behind current time

“Typical” Control Room

Safety Indicators
Safety indicator #1
covered by a paper
tag hanging from
the control above it
Safety indicator #2
located on a panel
behind seven foot
tall display
Safety indicator #3
intended to show
position of a valve
was instead showing
a solenoid status
1 2 3

How to Determine Status
No less than 11 steps
2 memorize / write down
1 required walking to a different location
1 required a paper table look-up
Final step: compare table number with value from step 7
Now, do all that at 4am.
With 100 alarms going off.
And you’re about to die…

Why Do You Care About UX?
Good design effects people
• Reduces irritation
• Improves job performance
and satisfaction
• Saves lives
Bad design effects people
• Adds stress
• Increases the likelihood of errors
• Can cost lives

Why Do You Care About UX?
A commercial mobile app needs to capture the user’s attention very quickly
• 30 seconds or they move on
• The user experience is what…
• makes someone keep using the app
• makes someone recommend it to others

Focusing on UX
• Increase successful product evaluations
• Wixon & Jones case study, 80% revenue increase by focusing on usability
• Reduce training costs
• Reduce support costs
• McAfee reduced support 90% by focusing on UX (2005)

User Experience vs User Interface
All software has an interface of some type, but how do you feel after
using it?
• A positive User Experience (UX) means
• You enjoyed using the system, or at least did not dislike it
• You would use it again and recommend it to others

For Your Consideration
You have reservations at a
high end restaurant for a
special occasion
Everything looks good, but...

For Your Consideration
You’re traveling and you stumble on
this place…

The Whole Picture
• The User Experience isn’t just the UI
• UX also includes things like
• Downloading and installing
• Integration with other apps
• Support and licensing
• The UX considers business goals as well as the end user (customer)

“What’s a good book on design?”
The Design of Everyday Things,
Donald Norman
If the user is confused, it’s the
designer’s fault

The Mobile User
The mobile users (and often embedded system users) are very different
from the desktop user: they are mobile!
• On the move
• Not focusing on device tasks for long
• Highly interruptible
• Often in a social context
To meet the mobile user’s needs, we have make mobile apps, not miniature
desktop apps
• “Don’t convert, create”

What Does “Mobile” Mean?
It can mean:
• Using a phone or phone-like device for common things
• Apps, games, etc
Using non-desktop devices (embedded) designed for specific tasks
• GPS devices (e.g. TomTom)
• MP3 players
• Tablet computing
• E-book readers
• In-Vehicle Info-tainment
(IVI)
• Others?

Mobile Applications
App development for mobile is more difficult than ‘traditional’ software
development
• Screen dimensions and variable orientation
• Physical hardware (buttons, sensors, camera)
Key for success: focus on the one thing your app does well

Mobile Context
• Different ways to think about this
• Mobile Context
• Adding value to the current moment in time, making it a richer experience
• The distracted driver problem:
youtube.com/watch?v=EUgq_h8clv8&feature=player_embedded
• Mobile context
• Simpler, like your physical location or state of mind

Designing with Context
• Who are your users?
• What is happening around them?
• When will they interact?
• Where are they?
• Why will they use your app?
• Know your users goals
• How are they using their device?

Workshop 1
• Break up into teams
• Group vote on what type of mobile app you will design
• A Food Delivery Ordering App
• A Cloud Storage App
• A Hotel Room Finder App
• Design with a 7-inch tablet as your device
• List the who, what, when, where, why and how for your application
• Present to the group

User Personas and Scenarios
Part 2

Agenda
• Personas
• Scenarios
• Information Architecture
• Best Practices
• Summary
• Workshop 2

Designing for the User
Designing for the users means letting users drive design – right?
• The Homer features:
• Large beverage holders
• Little ball on top of the aerial
• Bowling mascot on the hood
• Horns that play La Cucaracha
• Sound-proof bubble for the kids
• Huge motor
• Big fins

User Attributes
We love our users, and want them to have a great product experience. But,
users may be…
• Biased
• ‘Led’ toward answers the developers want
• Unsure of the answer

Developers and Users
• Developers typically create software for “the user”, who will basically be
what the developer wants
• If you dump “the user” into the Windows file system, you are defining the user
to be computer literate
• If you make “the user” use a wizard to do configurations all the time, you are
defining them to be first-time/novice users
• If a developer can’t just say “it will run on a computer”, then they can’t say
it is “designed to be intuitive for the user”

User Personas
• Hypothetical representative users
• Discovered by looking for patterns from user interviews
• Represent a specific set of behavior and usage patterns in the context of a
product
• Have goals and motivations
• Are addressed by name, with relevant characteristics
• Example - “Pat, a postal worker and mother of five, wants a quick and easy
way to manage her family’s schedule. She doesn’t care about…”
• Pro tip - Start with a reasonable user approximation and iterate until you
have 3-5 believable personas

Examples of Goals
Personal / Experience goals
• Not feel stupid
• Not make mistakes
Practical / End goals
• Handle the client’s demands
• Monitor a complex system
• Create a playlist
Non-user goals
• Customer goals: save money
• Corporate goals: increase profits
• Technical goals: cross-platform
consistency

Specific User Personas
• Why not design for all users?
• Lack of design focus
• Scope creep
• A product that does a little bit of everything – and does none of it well
• Pentagon Wars -
youtube.com/watch?v=aXQ2lO3ieBA&feature=youtu.be&hd=1

Constructing Personas
• Created by studying user data from interviews and looking for patterns
• Include information about goals, work flow, environment, skills, etc.
• Personas are not stereotypes – Personas are developed from research,
while stereotypes reflect assumptions and bias

Constructing Personas
• Revisit initial persona hypothesis
• Map interview subjects to behavioral variables (age, education level, etc)
• Identify significant patterns
• Synthesize characteristics and goals
• Check for completeness
• Develop narratives
• Designate persona types

Sample Persona
For a medical monitoring system
Joan is a 45 year old nurse at a CCU
in a busy hospital in Boston. She
often works 12 hours at a time,
including the occasional overnight
shift. Her goals include making sure
all the patients in her care remain
safe, and being able to quickly finish
her end-of-shift paperwork so she
can get back home to her husband
and two school-aged daughters.
Facts that drove the persona
Average age: 46.8
Gender: 95% female
Family status: 70.5% married. 52%
have children at home, 65% of which
aged 6 to 18
Source: American Nursing
Association, 2004

Persona Types
Primary
• Main focus of the design
• Not satisfied by an interface
designed for other personas
Secondary
• Must not be made unhappy by any
design choice targeted for the
primary persona
• Potential customers, or those
affected by products
Supplemental
• Not primary or secondary, often
political
Negative
• Personas that may use the product
we are not concerned over their
satisfaction
• Example - technically savvy early
adopters of consumer products

Personas Case Study
• In a project described in Cooper’s “The Inmates are Running the Asylum”,
an In Flight Entertainment (IFE) system is being designed
• Four personas:
• Chuck, age 54, frequent business traveler
• Ethan, age 9, first time flyer, plays games
• Marie, age 31, bilingual business traveler
• Bob, age 65, doesn’t own a computer
• Interface has to satisfy all four without making any one of them unhappy
(different from making them all happy)
• Who is the primary persona?

Personas Case Study
• Bob!
• Any solution that focused on the other three would be unacceptable to Bob
• Additional features, like shortcuts for Chuck and Marie, can be
incorporated as long as they don’t distract from the primary persona’s
satisfaction
• Final interface ended up using a physical knob instead of just virtual keys
on a touchscreen

Persona-Based Scenarios
• Story-like description of a persona, their life experience, and how the target
system fits in
• Narrative descriptions involving personas using the product to achieve a goal
• “Day in the life” scenarios
• Capture the "non-verbal" dialogue between the user and the system
• Designers "role play" personas in the scenarios, trying to think like the
persona would think

Persona-Based Scenarios
• Scenarios need to consider:
• Product use setting
• Frequency and duration of use
• Frequency of interruptions
• Complexity
• What the persona hopes to accomplish
• Don’t focus on how the interface performs a task, but assume it
“just does”
• One of the few times hand waving is encouraged!

Scenarios and Design
• Use the scenario to communicate ideas describing user behavior
over time
• Personas act as the agents in the scenario
• Bring user's mental model into focus
• Give the developer some empathy for what the user goes through when
using a system

Identifying Needs
• From the scenarios we can derive needs
• Data needs: information the system must present to the user
• Functional needs: operations to be performed via interface controls or places
info must be displayed
• Contextual needs:
• Workflow under various conditions
• Physical or environmental conditions
• Persona skills, abilities, disabilities

Information Architecture (IA)
• Structural design of shared information environments
• Construction naturally follows from needs (data, functional, contextual)
• Combines organization, labels, searching, and navigation
• Designing information products and experiences to support usability and
“findability” of desired info

Facets of IA
Fundamental IA
• How the user finds information or
performs tasks
Interaction Design
• How the user interacts with
presented data to accomplish
their goals
Information Design
• Visual layout of information
Navigation Design
• The “information space” and how
to travel through it
Interface Design
• Visual paradigms to facilitate the
above

Mobile IA
• Keep it simple
• You have limited space and task times, so focus on your users’ goals
• Use very clear, short, and descriptive labels
• Make your site maps shallow with as few branches as possible

Mobile IA Site Map

Interaction Framework
• This is the part everyone wants to jump to… the “tangible” part
• Managers want demos
• Engineers want to start coding
• Personas and scenarios feed this part of the design process
• Without the early parts of the process, you’re designing the wrong product!
• Resist, at all costs, the temptation to start “placing pixels” early
• Photoshop gives you pictures without coding

Best Practices
• Develop 3-5 user personas
• Determine the primary persona for whom you’re designing
• Use the personas to write user scenarios
• Use the scenarios to guide the development of the IA

Summary
• User personas are short descriptions of representative users and include:
• Demographic information
• Goals
• Motivations
• User scenarios are short stories which detail how a user (persona)
interacts with an app
• IA maps the flow of information within an environment

Workshop 2
• Write three user personas
• Determine which is the primary user
• Develop one user scenarios for each persona
• Scenarios should be at most one paragraph long, and should capture:
• User goals
• User motivations
• The environment in which the user is operating (where and when they use
the app)

Mobile and Embedded Design
Guidelines, Principles and Prototype
Techniques
Part 3

Mobile Design Guidelines and Principles
• Style Guides
• Principles
• Patterns
• Guidelines
• Prototyping
• Workshop 3

Style Guides
Most development platforms have
Style Guides
• Follow them, unless you have a
good reason to do otherwise
For Windows 10.x:
• http://msdn.microsoft.com/en-
US/windows/apps/hh779072
For the Android platform:
• http://developer.android.com/
design/index.html
For the iPhone:
• http://developer.apple.com
• Search for “human interface
guidelines”

Principles
• Fundamental, widely applicable, and enduring
• Different levels of detail
• Often a basis for patterns

Levels of Detail
• Principles operate at different
levels of detail
• Conceptual
• What a system is
• User expectations
• Interaction
• How a system should behave
• Interface
• Look and feel
• Most product design tends to
focus here
• Most principles apply across
platforms, while some platforms
have specific considerations
• Web: bandwidth
• Embedded: resources

Design Patterns
• Design Patterns have become a popular method of applying best practices
and shared experiences since the GoF book
• A simple definition of ‘design patterns’ is elusive
• “The abstraction from a concrete form which keeps recurring in specific non-
arbitrary contexts” (Riehle and Zullighoven)
• A literary form of software engineering problem-solving, with roots in
architecture
• Christopher Alexander, A Pattern Language (1979)
• Documentation of best practices
• A common vocabulary and shared language

Design Patterns
Design Patterns: Elements of
Reusable Object-Oriented Software,
Gamma, et al, 1994, Addison-Wesley

Design Patterns
• Designs Patterns typically come in three parts
• Name
• Problem being solved or context found
• Solution, often with (UML) class descriptions
• Goals of Design Patterns
• Reuse ‘good’ solutions
• Encapsulate experience
• That which makes a person an expert
• Solve problems without rediscovering everything from scratch

UI Design Patterns
Designing Interfaces, Jenifer Tidwell
Many UI patterns, mobile and
otherwise

Fundamental Principles
“Know thy user” Hansen (1971)
• Age, gender, physical and cognitive abilities, education, cultural or ethnic
background, training, motivation, goals and personality
• Skill levels play a large part in system design
• Novice or first-time users
• Knowledgeable intermittent users
• Expert frequent users

• Identify, and distinguish between, a user’s goals and tasks
• A goal is an end condition, what the user really wants
• A task is a step a user takes to achieve a goal
• Sometimes innovation changes tasks
• Communication (mail, voice, email)
• A frequent part of system design is task analysis
• Breakdown a user’s real-world tasks into sub-tasks

• In design, “less is more”
• Consider the PDA
• Apple Newton, 1992. Lots of features, but essentially failed
• Palm Pilot, 1996, had less features but was more successful
“You press one button and it shows you your schedule… No struggle, no
effort, no confusion… That’s the key to the whole experience.” – Rob Haitani

UI Design Guidelines
1. Strive for consistency
2. Cater to universal usability
3. Offer informative feedback
4. Design dialogs to yield closure
5. Prevent errors
6. Permit easy reversal of actions
7. Keep users in control
8. Reduce short term memory load
8 Golden Rules for Interface Design
Ben Schneiderman – U. Maryland

Strive for Consistency
• Consistency can be
• Within a product
• Across products within a company
• Across the software industry
• Ctrl-C to copy
• Benefits of consistency
• The user benefits from transfer of learning
• Marketable as a “look and feel”
• Perhaps the most frequently violated or ignored rule…

Consistency

Universal Usability
• Designing software to be usable by the widest range of reasonably
possible users
• Many factors to consider
• Physical abilities
• Vision, coordination
• Cultural differences
• Colors, icons
• Technical experience
• Human perception

Universal Usability
• Anyone can have color vision problems under different circumstances
• “Cut.. the blue wire with the white stripe, not… the black wire with the
yellow stripe…”
Tip: Use
Secondary
Encoding!

Offer Informative Feedback
• Every action should provide
feedback that something
happened, or is happening
• > 1 second and user will get ansy
• Controls should have descriptions
• Describe what is possible or not
possible
• Examples
• Progress bars
• Status messages
• Cursor changes
• Tooltips
• Animations

Design Dialogs to Yield Closure
• Users want to feel confident that a given task has
• Obvious steps
• Well-defined outcome
• A dialog box should
• Appear for a purpose
• Have logical steps
• Give a good indication of the
success or failure of the task

Prevent Errors
• Guide towards correct actions
• Gray out inappropriate actions
• Selection rather than freestyle typing
• Automatic completion
• Input validation
• Error prevention lessens the need for error messages, which are often
poorly worded
• Make error messages specific, positive in tone, and constructive

Provide Proper Choices
• Google Docs Context menu
???

Being Helpful vs Showing an Error
• A typical re-enter password workflow involves a “passwords don’t match”
error dialog
• Here’s an improvement: tell the user before they hit Ok

Unhelpful Error Dialogs

Provide Reversal of Actions
• Give the user some level of safety net
• Undo
• Easy “back to last screen”
• Restore defaults
• Reduces anxiety, encourages experimentation
• Mechanism for reversal is almost always better than a confirmation dialog

Keep the User in Control
• The user believes his/her actions completely control the application’s
behavior
• The user believes certain actions will always provide certain results
• Provide automation to improve performance
• But allow for human oversight (e.g. autopilots)
• Provide flexibility for a user
• Customization, personalization

Reduce Short Term Memory Load
• Don’t make the user have to remember things between steps / screens
• Short term and working memory are highly volatile
• Disruptions cause loss of memory
• Task switching, multi-tasking
• The average person can only remember seven plus or minus two chunks of
information at a time

Chunking Experiment
Observe these letters
C BSN BCI BM

Chunking Experiment
• Hold that thought…
• Now, what were they?
• Does this help? CBS NBC IBM
• Information with structure or meaning is easier to remember

Mobile Device Heuristics
Bertini et al, “Appropriating and Assessing Heuristics for Mobile Computing”,
AVI ‘06
• Visibility of system status
• Match between system and the
real world
• Consistency and mapping
• Good ergonomics and minimalist
design
• Ease of input, screen readability
and glancability
• Flexibility, efficiency of use and
personalization
• Aesthetic, privacy and social
conventions
• Realistic error management
• Losability/findability of the mobile
device

Visibility of System Status
• Always keep the users aware of
what is going on with the device
• Prioritize important messages
• Battery power
• Incoming calls

Match Info to Real World
• Provide information in a natural and logical order
• Consider displaying dates
• In calendar form
• In language specific format
• Sense environment and location, adapt accordingly
• Locator apps knows world location from GPS
• Show distances in kilometers / miles
• based on user’s language

Consistency and Mapping
• Design application to be consistent for the specific platform
• Check the platform style guides
• The user’s mental model should map naturally to actions and tasks
• Even more important in mobile than desktop applications

Ergonomics and Minimalist Design
• Screen real estate is precious
• Use it wisely, displaying relevant information
• Use high contrast colors to good readability
• Use dialogs sparingly
• Avoid those extra “OK” buttons that don’t really add anything to the UI

Ease of Input and Readability
• Input
• Fast, easy
• Example: combo boxes instead of text input
• Reduce need for user to have both hands on device
• Screen content easy to read
• Suitable fonts and colors

Glancability
Make important information available at a glance

Flexibility, Efficiency of Use & Personalization
• Allow customization of frequent actions
• Advanced user appreciate it
• Dynamically configure system according to context
• Location
• Device orientation
• Aesthetic ‘Cool Factor’ very important for apps
• Remember 30 Second rule

Error Management
• Prevent errors than display an error
message
• OpenTable lets us chose dates with
spinners (good)
• Delta.com required text entry of dates (bad)10/18/2010

Losability / Findability
• Provide ways for users to recover critical data if the device is lost
• Network synchronization
• Provide security for sensitive data
• Challenge: balancing ease of use with security.
• Biometrics?

Privacy and Social Conventions
• Mobile apps are likely to be used in social or public settings
• Avoid doing things that might embarrass the user
• Use sound wisely
• Provide fast, efficient ways of silencing audio

Prototypes

Prototypes
• "An easily changeable draft or simulation of at least part of the interface"
(Hackos & Redish, 1998)
• "Prototypes" are representations of a design made before final artifacts
exist. (Buchenau & Suri, 2000)
• A working model(s) of a system being created, possibly at different levels
of fidelity

Why Prototype?
• Early requirements gathering
• Feeds specification work
• Easier to change before its coded
• Cost effective
• Usability testing

Levels of Fidelity
• Rough: stories, sketches, scenarios (low)
• Refined: wireframes, paper, Wizard of OZ (medium)
• More refined: fully working prototype (high)
• requires software tool, machining, etc

Sketches
• A rough image of an envisioned interface
• Not everyone is an artist, but that's OK!
• Avoid focus on too much detail early
• Focus on too much detail early in design shifts the focus to less important
things (Salomon, 1990, HFS Proceedings)
• Low visual fidelity
• “Back of the napkin”

Sketching Example

Wireframes
• Depiction of a page from an architectural focus
• Draw lots of ‘empty’ boxes to represent your intended design
• Describes
• General layouts of page types
• How things are grouped
• Content
• Constraints
• Low to high visual fidelity

Wireframe Tools
• Various tools to do wireframes
• Balsamiq
• Adobe tools (Photoshop, Illustrator)
• PowerPoint
• Some wireframing tools also let you create prototypes
• Axure RP
• JustInMind

Wireframe Example

Paper Prototypes
• Representation of a user
interface using office supplies
• Can vary in aesthetic fidelity
• Can be used to represent
• Software
• Hardware
• Web sites
• Mobile Devices

Paper Prototyping Basics
• Rough sketches and simulated UI objects
• Person uses finger as mouse and simulates typing
• Focus is NOT on aesthetics or accurate screen size
• Encourages creativity that high fidelity prototypes may not
• Person familiar with the design plays the computer
• Can make changes on the fly

Things you can learn from PP
• The user’s mental model of a system
• Navigation and workflow
• Terminology
• What is clickable (in the user’s mind)

Paper Prototyping Example
https://www.youtube.com/watch?v=ppnRQD06ggY
Search on YouTube, you will find many others

Workshop 3
• Put these guidelines to use and create some wireframes
• Create wireframes (or sketches) for a few key screens of your app
• Walk through one of your scenarios and show the app being used

Usability Testing
Part 4

Agenda
• User Testing
• Heuristic Analysis
• Best Practices
• Summary
• Workshop 4

Usability Testing and Labs
• Usability testing and laboratories have been used since the early 1980s
• Usability testing sped up many projects and produced dramatic cost
savings
• Clare-Marie Karat of IBM showed a 100-fold return on investment for a
software product. Spending $68,000 on usability engineering throughout
development resulted in savings of $6,800,000 in the first year alone.
• Source: http://www.uxteam.com/blog/every-dollar-invested-in-ease-of-use-
returns-10-to-100-dollars/
• Movement towards usability testing stimulated the construction of
usability laboratories
• A typical modest usability lab would have two 10 by 10 foot areas, one for the
participants to do their work and another, separated by a half-silvered mirror,
for the testers and observers

• Participation should always be voluntary, and informed consent should
be obtained
• Professional practice is to ask all subjects to read and sign a statement
like this one:
• I have freely volunteered to participate in this experiment
• I have been informed in advance what my task(s) will be and what
procedures will be followed
• I have been given the opportunity to ask questions, and have had my
questions answered to my satisfaction
• I am aware that I have the right to withdraw consent and to discontinue
participation at any time, without prejudice to my future treatment
• My signature below may be taken as affirmation of all the above statements;
it was given prior to my participation in this study

• Videotaping participants performing tasks is often valuable for later review
and for showing designers or managers the problems that users
encounter
• Many variant forms of usability testing have been tried
• Paper mockups
• High fidelity testing
• Universal usability testing
• Field test and portable labs
• Remote usability testing
• Can-you-break-this tests
• Usability Design and Usability Center at Bentley
• Source: http://usability.bentley.edu/usability-labs

Usability Metrics
• Quantifying usability
• Metric:
• “A standard of measurement”
• “A system of related measures that facilitates the quantification of some
particular characteristic”
• “Usability Metrics” is not an oxymoron!
• You can actually measure how usable something is– in the context of its users
and their tasks

Why Quantify?
• Many different goals depending upon the stage of development of the
product
• Determine if it’s ready to launch
• Help identify problem areas or issues that need to be addressed
• Get an overall sense of how good or bad things are
• Determine how your product compares to competitors
• See if things are getting better across iterations, releases, quarters, years, etc.
• Help convince management of the need to fix something

Types of Usability Metrics
• Performance metrics - time, errors, task completion
• Self-reported metrics - ease of learning, ease of use, confidence
• Issues-based metrics - number of problems, severity of problems, number
of users encountering problems
• Combined and comparative metrics - comparisons to goals or “expert”
performance
• Behavioral and physiological metrics - eye-tracking data, facial expression
coding

Usability Testing – Why?
• The whole design team may like the design, but the end user may not
• If it can’t be used successfully in the field, it won’t be a successful product
• You need to test your design against actual users to ensure that your
design decisions are sound
• Not managers
• Not sales people
• Not developers/engineers
• Users should:
• Be able to quickly learn and execute primary tasks
• Remember how to execute primary tasks
• Ideally feel satisfaction from using the system

Source: http://blogs.perficient.com/spark/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Usability Testing
When?
• Put your designs in front of target users before you start coding
• Or at least put prototype code in front of non-engineers
• Lots of metrics in the industry about cost of fixing defects at various points in
the product lifecycle

Usability Testing
What?
• Testing can be done at varying levels of fidelity and formality
• Low fidelity wirerames
• Consider Paper Prototypes
• High fidelity interactives

Usability Testing
Who?
• Make sure your test participants are representative of the target users
• Participants should be chosen to represent the intended user
communities, with attention to:
• Background in computing, experience with the task, motivation, education, and
ability with the natural language used in the interface

Sample Size
• Depends on two main factors
• Goals of the study
• How much possible error you’re willing to accept
• Goals of the Study
• Early phases of a project, looking for major usability issues - fewer
participants (3-4)
• Later phases of a project, looking for remaining usability issues - more
participants (10)

Sample Size and Error
• More participants → Less possible error in most metrics.
• Example - You want to be sure that the mean time to register for a website is
less than 60 seconds
• You test 5 representative users and find that the mean time to register
was 54 seconds
• Are you satisfied?
• Check mean, std dev

Types of User Testing
• User testing can take on a variety of forms
• Expert review
• Laboratory usability testing
• Use your high-fidelity prototypes
• User surveys
• Obtain data from large numbers of users
• Evaluation during active use

User Surveys
• Written user surveys are a familiar, inexpensive and generally acceptable
companion for usability tests and expert reviews
• Keys to successful surveys:
• Have clear goals before developing a survey
• Develop focused survey items to address the goals
• Survey goals can be tied to the task to be performed with a given interface
design
• Users could be asked for their subjective impressions about specific
aspects of the interface, such as the representation of:
• Task domain objects and actions
• Syntax of inputs and design of displays

Likert Scale
• Named for Rensis Likert, who created it in 1932
• Pronounced “lick-ert”, not “like-ert” (claimed to be one of the most
mispronounced names in the field)
• A typical Likert scale has a:
• Statement (positive or negative) to which respondents rate their level of
agreement
• Rating scale
• Commonly a five-point scale, but almost always an odd number to allow for
neutral response
• Most go from negative to positive
• Satisfaction (1=difficult, 5=easy)

Post Task Metrics
• Assess ease of use
• Most common is the Likert scale
• “This task was easy to accomplish”
• 1 = Strongly disagree … 5 = Strongly
agree
• Specific aspects of usability
• Navigation
• Terminology
• Usefulness
• Efficiency
• Likeliness to perform an action

Post Session Ratings
• Administered after the user has completed all tasks
• Usually include rating scales as well as open-ended questions/comments

A (Humorous) Look at
Usability
Usability and fruit

Importance of User Testing
• User testing is often the:
• First thing to get cut to meet schedule
• Most important part of the design process
• Better to know that there are potential user problems during design than
after shipping
• Designs rarely totally “fail” during testing, but potential problems can still
be caught and fixed
• Iterate, go back and fix your interaction framework

Heuristic Analysis
• A Heuristic Analysis is a form of discount usability evaluation
• An expert goes through a design and gives their impressions
• Identify and prioritize usability challenges in an interface and recommend
improvements
• Use a set of heuristics (i.e., 8 Golden Rules) to compare against
• A good start, but shouldn’t be the only testing done

“Do I really need to do all of this?”
• You should, but you most likely won’t…
• Theory vs practice
• Reality, management, and product schedules
• All design is trade off
• Resources, functionality, schedule
• “Good, fast, cheap. Pick two.”
• Things to keep in your design cycle
• User interviews
• Personas and scenarios (limited, if necessary)
• Fight for that user testing time at the end!

Iteration
• Take the results of testing and change your design
• Re-design, re-test, iterate
• Don’t consider a feature “done” until tested
• Be open to iteration
• Don’t ship the wrong product

Best Practices
• Test early and often throughout system development
• Surveys like SUS are a good starting point
• Paper prototypes can be a quick and cost effective way to obtain user feedback
• Ensure the test participants are the actual target users
• Usability metrics can provide insight into user interaction with and
response to your product

Summary
• Usability testing puts your design in front of actual users
• Use low-fidelity prototypes (paper, not code) to do early system testing
• Usability testing can be a relatively quick and inexpensive way to highlight
problems before the product is shipped

Workshop 4
• Combine into two groups
• Each group will pick one design, perform a heuristic analysis
• List issues as facts and areas of improvement, not opinions

UI Design Guidelines
1. Strive for consistency
2. Cater to universal usability
3. Offer informative feedback
4. Design dialogs to yield closure
5. Prevent errors
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short term memory load
8 Golden Rules for Interface Design
Ben Schneiderman – U. Maryland

In Closing…
133

To Recap
• Expand your focus beyond the nuts-n-bolts of the UI to consider the full UX
• Mobile and embedded software have different criteria for success than
the desktop
• Design for a target user (persona) in a particular context (scenario)
• Learn and apply principles, patterns, styles, guidelines
• Research, design, prototype, test, validate, iterate
134

Story Time
135
The Human Factor: Revolutionizing the
Way People Live with Technology
By Prof. Kim Vicente

Story Time
4:30pm Feb 27th, 2000
• Danielle McCray admitted to Tallahassee Memorial hospital to deliver a
baby
6:45pm Feb 27th, 2000
• Connected to a patient-controlled analgesia machine (programmable
infusion pump)
2:30am Feb 28th, 2000
• She had died of morphine overdose
Cause: “human error”
136

Tip of the Iceberg
• 1996, Producer was given a warning about potential interface issues
• 1997, Regulatory watchdog group issued a warning that this device was
“susceptible to misprogramming”
• Company response: problem was not with the design, but lack of user
training
• “the device has no design flaws…the pump is safe if used as directed”
• Likelihood of death: between 1 in 33,000 to 1 in 338,800.
137

Design Can Save Lives
• 1998, Academic analysis showed it was possible to reduce steps from 27
to 12, and totally eliminate the particular error reportedly linked to patient
deaths
• Total number of deaths linked to this device and this problem: Between 65
and 667
138

In Closing
• Consider the applicability of design guidelines, theories, and best practices
to your work
• Remember and apply
• Know thy user
• Be consistent
• Make errors as impossible as possible
• Design first, code later
• Learn from history; examples abound
139

Thank You for Attending
Slides, or further info, contact jeffl@ics.com
Questions?
140

User Experience Design for Embedded Devices

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (16)

Ähnlich wie User Experience Design for Embedded Devices

Ähnlich wie User Experience Design for Embedded Devices (20)

Mehr von ICS

Mehr von ICS (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

User Experience Design for Embedded Devices