04 user centered design

www.dadda.it roberto@dadda.it Excellence in usability 1st semester 2021-2022 1
ERGONOMICS APPLIED TO THE DESIGN OF USABLE WEB
PAGES AND APPS
Roberto DADDA and Paolo NEGRI

User centered design
User first!
2

3

4

Sounds familiar?
• I can’t find anything in this website
• The system is impossible to use
• This is taking longer than it should
• The site is ugly
• I found this yesterday night, now I’m unable
to find it again
• I must have clicked the wrong thing
• I did a mistake, and now what happens
• Those fields should be filled automatically
• Why he is asking me twice the same data?
5

εὕρηκα(1)
(1)https://en.wikipedia.org/wiki/Eureka_(word)
εὑρίσκω, heurískō:
I have found it!

User centered design
User Centered design
(UCD) is an
interactive method
that puts the user at
the center of all
design decisions.

UCD is a design
philosophy and
approach enabled by a
wealth of disciplines
and design methods.
Ultimate goal of UCD
is to optimize the
user’s experience of a
system, often a mix of
product and process.

The main focus is user
perspective during all phases
of development lifecycle
9

User’s
drivers

1 - Needs and wants

2 - Goals, motivations and triggers

3 - Obstacles and limitations

4 - Tasks, activities and behaviors

5 - Geography and language

6 - Environment and tools
1
6

7 - Work life and experience
1
7

Personas
A persona (plural personae or personas), in the word's everyday usage, is a social role or a character played by an actor.

Personas
A persona, (aka user persona, customer persona, buyer persona)
in user-centered design and marketing is a fictional character created
to represent a user type that might use a site, brand, or product in a
similar way.(1)
(1) William Lidwell; Kritina Holden; Jill Butler (1 January 2010), Universal Principles of Design, Rockport Publishers, p. 182, ISBN 978-1-61058-065-6

Personas why
• To keep the users at the center of
design development
• To facilitate conversation
• It provides:
• strategy
• structure
• story
2

Personas
• Foundation for the rest of user
documentation
• Makes data comprehensible and
interaction easier by giving a
NAME
• Sort of imaginary friend
• PROVEN effective in the success of
final product
• Not important how rich, important
how relevant to the process
2
1

Personas as design tools
• Determine what product should do
and how it should behave
• Communicate with stakeholders,
developers and other designer
• Build consensus and commitment
to the design
• Measure design’s effectives
• Contribute to internal and external
marketing
2

UI personas are different from marketing ones

Personas card content
• Name (Mary)
• Short description (not more than 5 words)
• Photo (avoid celebrities)
• Demographics
• Personality
• Technical expertise
• Platform (Browser, iPhone…)
• Goals (Motivation)
• Motto
2
5

Elements of a persona
• Name
• Picture
• Description
• What they want to do
on our site
• And some project’s
specific ones
2
At least

2
7

Suggestions
• Start brainstorming
with sticky notes
• Keep certain persons
you know in mind,
but combine their
goal and
descriptions in
personas
• Mindmapping helps
2

Mind map

Empathy map
• HEAR
• What friends, boss, influencer, partner… says
• SEE
• Environment, friends, what the market offers
• THINK&FEEL
• What really counts, major preoccupations, worries & aspirations
• SAY&DO
• Attitude in public,appearance, behaviour toward others
• PAIN
• Fears, frustrations, obstacles
• GAIN
• “Wants”/needs, measure of success, obstacles

3

Refence material on personas
• https://www.usability.gov/how-to-and-tools/methods/personas.html
• https://knowledge.hubspot.com/contacts-user-guide-v2/how-to-
create-personas
The designer view
The marketing view

Ruyard Kipling poem
• Basic for journalism
• Story telling fundamentals
• Essential for describing anything
•PERSONAS: who and why
•TASKS: what, when, how
and where

5W & 1H

User stories aka TASKS
• Small sentences
• Use essential features first
• Value is in simplicity
• step-by-step description page-by-page
• understand and emphasise emotions
• Behavior
• Motivation
• Environment
• External factors

User’s goal
• Life
• Be the best in what I do
• Learn all there is to learn in
this field
3
• Experience
• Don’t feel stupid
• Don’t make mistakes
• Have fun
• Objectves
• Find the best price
• Process the
customer’s order

Non-user goals
• Managing customers
• Be sure about security of transaction
• Privacy issues
• Corporate
• Increase market share
• Use resources more efficently
• Technical
• Support all major browsers
• Maintain consistency accroisse platforms
• Orchestrate WEB & APPS
3

User stories
AS A type of user, I WANT a feature SO THAT I CAN complete a goal
As a… I want to… So that… scenario 1 scenario 3 scenario 3
1
2
3
4

The requirements dilemma

Not so far from some real project situations

Problem solving vs problem setting

We are ideas and concept midwifes

If is not written does not exist!
4
5
=

Order from caos
4

10 techniques for gathering requirements
1. One-on-one interviews
2. Group interviews (3—4)
3. Facilitated sessions (8)
4. Joint application development (JAD)
5. Questionnaires
6. Prototyping
7. Use cases
8. Following people around
9. Request for proposals (RFPs)
10.Brainstorming
4
http://www.techrepublic.com/blog/10-things/10-techniques-for-gathering-requirements/

A very good analysis of Requirements collection is found in Wikipedia: https://en.wikipedia.org/wiki/Requirements_analysis

Use cases
A use case is a written description of how users will
perform tasks on your website. It outlines, from a
user’s point of view, a system’s behavior as it
responds to a request. Each use case is represented
as a sequence of simple steps, beginning with a
user's goal and ending when that goal is fulfilled.
• Who is using the website
• What the user want to do
• The user's goal
• The steps the user takes to
accomplish a particular task
• How the website should respond
to an action
• Implementation-specific
• Details about the user interfaces
or screens.
Are Are NOT

Benefits of use cases
• Use cases add value because they
help explain how the system
should behave and in the process,
they also help brainstorm what
could go wrong. They provide a
list of goals and this list can be
used to establish the cost and
complexity of the system. Project
teams can then negotiate which
functions become requirements
and are built.

Possible elements of a use case
Depending on how in depth and complex you want or need to get, use cases describe a
combination of the following elements:
• Actor – anyone or anything that performs a behavior (who is using the system)
• Stakeholder – someone or something with vested interests in the behavior of the system
under discussion (SUD)
• Primary Actor – stakeholder who initiates an interaction with the system to achieve a goal
• Preconditions – what must be true or happen before and after the use case runs.
• Triggers – this is the event that causes the use case to be initiated.
• Main success scenarios [Basic Flow] – use case in which nothing goes wrong.
• Alternative paths [Alternative Flow] – these paths are a variation on the main theme. These
exceptions are what happen when things go wrong at the system level.

How to write a use case
Write the steps in a use case in an easy-to-understand narrative.
Kenworthy (1997) outlines the following steps:
1. Identify who is going to be using the website.
2. Pick one of those users.
3. Define what that user wants to do on the site. Each thing the use does
on the site becomes a use case.
4. For each use case, decide on the normal course of events when that
user is using the site.
5. Describe the basic course in the description for the use case. Describe
it in terms of what the user does and what the system does in
response that the user should be aware of.
6. When the basic course is described, consider alternate courses of
events and add those to "extend" the use case.
7. Look for commonalities among the use cases. Extract these and note
them as common course use cases.
8. Repeat the steps 2 through 7 for all other users.
5

A classic example

Matrioska logical structure

KISS

www.usability.gov

Usability
Roberto DADDA
roberto@dadda.it
www.dadda.it
Skype, Facebook e Twitter robertodadda

04 user centered design

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a 04 user centered design

Semelhante a 04 user centered design (20)

Mais de Roberto Dadda

Mais de Roberto Dadda (19)

Último

Último (20)

04 user centered design