20

2015

Kolfe industrial college

Web Design and Database Administration Level III

Modeling website technical requirements

LO2. Define human computer interface

LO2. Define human computer interface

2.1 Conducting user analysis to determine a
user profile and user needs.
2.2 Determining user content and
requirements
2.3 Determining appropriate design principles
for site.
2.4 Identifying appropriate operating system
2.5 Determining appropriate search engine

1
What is a User Analysis?
A user analysis studies the human behavioral impact on product design. UX designers use quantitative and qualitative data to understand user behavior and
guide design decisions.

Research teams create personas and use cases based on user flows to understand how users will use a digital product. For example, UX designers want to know
customers’ demographics, circumstances, environment, process, and devices they use to order a beverage when designing a coffee ordering app.

This analysis will help designers design the appropriate features for customers to order coffee through an application.

Who is Responsible for Conducting a User Analysis?

The person or team responsible for conducting a user analysis will depend on the organization and the product’s maturity. UX designers/researchers are usually
responsible for early-stage user analysis or product redesigns.

Product managers/designers/owners often take over user research for established products, bringing UX designers in to collaborate or solve complex usability
issues.

Further reading: Check out this article for more details about product designers vs. UX designers and how their roles differ.

When Should You Conduct a User Analysis?

There are three primary situations where teams conduct a user analysis:

 Designing a new product

 Redesigning an existing product
 Designing a new feature for an existing product

No matter the circumstance, a user analysis most often occurs early in the UX design process. Design teams use the results to set project goals, guide ideation,
and design decisions.

2
Why is User Analysis Important?
User analysis answers questions about end users’ tasks and goals to guide design and development decisions.

Through this analysis, teams can identify roles and characteristics that aren’t always possible through market research, such as state of mind, use cases,
environment, frequency of use, and how users engage with competing products.

Reason #1: User Analysis Eliminates Assumptions and Bias

A comprehensive user analysis gives customers a seat at the table. Instead of determinations based on stakeholder direction, bias, assumptions, internal politics,
and other factors, teams let user research guide the decision-making process.

Reason #2: User Analysis Identifies Opportunities

User analysis helps teams align customer needs with business goals. Researchers also use a user analysis to look for improvements, competitive edges, market
gaps, and other opportunities.

User Analysis Methods

User analysis methods fall into two categories:

 Quantitative data: Measurable, but it doesn’t show the cause of action

 Qualitative data: Subjective, but you get a chance to uncover the “why”

In UX design, no data set is more valuable than the other. Using one data set only tells part of the story. UX researchers combine quantitative and qualitative
data to understand users, competitors, and the market.

Quantitative Data

Quantitative research produces numbers, time, ratios, and other measurable data. This quantifiable data is relatively easy to analyze because analysts can
identify a baseline and measure whether something goes up or down.

3
Quantitative data also tells designers and researchers about user demographics, which they combine with qualitative data to create personas–a vital UX
research tool.

Qualitative Data

User experience design places a high value on qualitative data. While measurable data is important, it often can’t explain “the why.” UX researchers use
qualitative data to understand the root of issues and opportunities.

For example, quantitive data from Google Analytics will show a high drop-off rate for an eCommerce checkout flow. When UX designers conduct interviews,
users express feeling frustrated and overwhelmed completing the checkout’s lengthy form.

Without this qualitative data, the team might assume the problem lay in pricing, payment methods, or shipping charges rather than simply fixing the checkout
form.

5 User Analysis Artifacts

There are several UX artifacts researchers and analysts use to conduct a user analysis, including:

 User personas
 User stories
 User journey maps
 User content matrix
 User task matrix
 Task analysis

1. User Personas

User personas are the foundation of UX research and analysis. This UX artifact aggregates user demographics, goals, behaviors, and beliefs into a one-page
document with a fictional name and profile image to represent a user group.

Design and product teams use personas to help create a human connection, making it easier to empathize. Personas also create a foundation for developing
other UX artifacts like empathy maps, user journeys, storyboards, flows, etc.
4
2. User Stories

Personas provide designers with a clear idea of who the product is for, and a user story outlines how they might use it. These stories help designers understand
the environment, motivation, circumstance, and mindset of a user as they complete various tasks.

Agile Coach and Senior Consultant at Industrial Logic, Bill Wake, created a simple guideline to follow when developing user stories. Bill’s user-story
methodology provides value to the business and users in a single iteration using the acronym “INVEST.”

 Independent: The user story should be self-contained, so it doesn’t depend on other stories
 Negotiable: Avoid too much detail, so user stories are flexible and adaptable
 Valuable: User stories must deliver value to the end-user
 Estimable: You should be able to estimate the resources needed for a user story
 Scalable: Keep the user stories lightweight so they can be tasked and prioritized with a certain level of certainty
 Testable: Explain the acceptance criteria, so the team knows when a story is complete

Another user story methodology is Intercom’s job stories–a framework designed to remove user persona ambiguity by focusing on causality instead. According
to Intercom, job stories are more actionable because they focus on motivation rather than implementation.

3. User Journey Maps

Also referred to as user experience maps or customer journey maps.

Where the user story provides motivation and context, the user journey map creates a step-by-step visualization of a persona completing a task. Journey
mapping uncovers the critical customer moments that designers can optimize to create a more valuable user experience.

Here are four tips for creating valuable, actionable user journey maps:

5
  Uncover the truth: Scour your user research for quantitative and qualitative data on the experiences you’re mapping. Consider various sources like
web analytics, call center logs, and customer surveys and interviews. Triangulate user data to fill knowledge gaps.
 Chart the course: Experience maps should contain the lens (persona through which teams view the journey), the journey model (touchpoints across all
channels), and takeaways (design principles and insights from the mapping process).
 Tell the story: Map a beginning, middle, and end for user needs. Identify what insights are essential to the narrative and what are “nice to have.” Your
map must have a user needs hierarchy (what stands out immediately versus what sinks in later).
 Circulate the map: Present it in meetings, post it on the wall, and print it, so team members and stakeholders see it. The aim is for everyone to use
your map as a lens to see the world as customers do.

4. Task Analysis

Designers, engineers, product managers, and stakeholders often build products they don’t necessarily use or industries they’re unfamiliar with. A task analysis
seeks to solve that issue by providing insights and context.

A task analysis looks at how users complete tasks, including details like:

 Mindset
 Users’ environment
 Actions (in physical and digital environments)
 Duration or time-on-task
 Frequency of use
 Task difficulty

Unlike user stories and journeys that focus on users, a task analysis dissects the activities users must complete.

5. User Task Matrix

6
When analyzing multiple personas, researchers can use a user task matrix to compare various tasks and metrics. This matrix can help rank tasks in order of
importance so designers can identify key audiences, validate value propositions, and prioritize the product roadmap accordingly.

6. User Content Matrix

A content matrix helps teams visualize existing content, how it satisfies user needs, identify improvements, and prioritize content updates. Analyzing your
product’s content matrix helps eliminate redundant, outdated, or trivial content.

• Identifying needs:
– Understand as much as possible about the users, as well as their work and the context of
their work.
– System under development should support users in achieving their goals.

• Identifying needs is crucial to our next step.

• Establishing requirements:
– Building upon the needs identified, produce a set of requirements.

• A user-centered approached to development:

– Study that investigated the causes of IT project failure found that “requirements definition”
was the most frequently cited project stage that caused failure.
– Understanding what the product should do and making sure it meets the stakeholders’ needs
are absolutely critical to the success of the product.
7
 What are requirements?

• A requirement is a statement that specifies what an intended product should do,

or how it should perform.

• Traditionally, two types of requirements:

– Functional requirements specify what the system should do.
– Non-Functional requirements specify what constraints there are on the system or
its development.

• Interaction design requires us to understand both the functionality required and

the constraints for development or operation of the product.

• Let’s refine these two broad types into further categories.

4
 Categories of requirements

Category
Category Description
Description

• Functional requirements
• Functional requirements • •What
Whatthe the product
product shouldshould
do. do.

• Data requirements
• Data requirements • •The
The type,
type, volatility,
volatility, size/amount,
size/amount, persistence,persistence,
accuracy
accuracy
and and
value of the value of
amounts ofthe
therequired
amountsdata.of the
required data.

• Environmental requirements
• Environmental requirements • •OrOr “context
“context of –use”
of use” – circumstances
circumstances in which theininteractive
which the
interactive
product product must operate.
must operate.

• User requirements • Characteristics of the intended user group.

• User requirements • Characteristics of the intended user group.

• Usability requirements • The usability goals and associated measures.

• Usability requirements • The usability goals and associated measures.

Source: Interaction Design, ch. 7

5
 Choosing between data gathering techniques, continued
Technique Good for Kind of Advantages Disadvantages
data
Design is crucial and
Answering specific Quantitative and Can reach many people response rate may be
Questionnaires
questions qualitative data with low resource low. Responses may
not be useful.
Interviewer can guide
Time consuming.
Some quantitative interviewee if necessary.
Artificial environment
Interviews Exploring issues but mostly qualitative Encourages contact
may intimidate
data between developers and
interviewee.
users.
Highlights areas of
Some quantitative consensus and conflict.
Focus groups Collecting Possibility of dominant
but mostly qualitative Encourages contact
and multiple characters
data between developers and
workshops viewpoints
users.
Understanding Observing actual work Very time consuming.
Naturalistic
context of user Qualitative gives insights that other Huge amounts of
observation
activity techniques can’t give data.
Learning about Day-to-day working
Studying procedures, No time commitment will differ from
Quantitative
documentation regulations and from users required documented
standards procedures

Overview of data gathering techniques used in the requirements activity

6
 Choosing between data gathering techniques, continued
• Your choice is influenced by a number of factors.

• The kind of information you want.

– May also change depending on the stage of the project.

• The resources available to you.

– E.g., your project may not have the time, money or personnel to send out a nationwide survey.

• The location and accessibility of stakeholders.

– You may want to run a workshop for a large group of stakeholders, but could be prohibited
by geography.

• Two main issues to consider when making your choice:

– The nature of the data gathering technique itself.
– The task which is to be studied.

• Data gathering techniques differ in the following:

– The amount of time they take, level of detail and risk associated with the findings.
– The knowledge the analyst must have about basic cognitive processes.

7
 Choosing between data gathering techniques, continued
• Tasks can be classified along three scales:
– Is the task a set of sequential steps or is it a rapidly overlapping series of subtasks?
– Does the task involve high information content with complex visual displays, or low
information content, where simple signals are enough to alert the user?
– Is the task intended to be performed by a laymen with minimal training, or a practitioner
highly skilled in the task domain?

• Example: the design of an ATM vs. the design of a system to support back-room
workers at a bank who are reconciling the machine register with the customers’
deposit slip.

8
 Basic data gathering guidelines

• Focus on identifying the stakeholders’ needs.

• Involve all the stakeholder groups.

• Involve more than one representative from each stakeholder group.

• Use a combination of data gathering techniques.

• Support the data-gathering sessions with suitable props.

• Run a pilot session if possible, to work out any kinks.

• Understand what you are really looking for (though compromise may be needed).

• Carefully consider the means used to record the data during a face-to-face data
gathering session.

9
 Data interpretation and analysis

• Once you have gathered your data, you will need to interpret and analyze it.
– Start interpretation and analysis as soon after the gathering session as possible.

• Interpreting data:
– Begin structuring and recording descriptions of requirements.
– Capture information in documents and diagrams.
– This helps to keep track of context and usage information during the rest of the process.

• Analyzing data:
– Data-flow diagrams, state charts, work-flow charts, etc.
– For object-oriented approaches, can use class diagrams, sequence diagrams, etc.

• Requirements activity iterates numerous times before stable requirements evolve.

– Continued interpretation and analysis throughout the process will result in a deeper
understanding as well as clarification of the requirements.

• We will focus on four techniques that have a user-centered focus and are intended
to understand the users’ goals and tasks.

10
 Task description and analysis, continued

• User-centered task descriptions are created to understand users’ goals and tasks.
– Scenarios
– Use cases
– Essential use cases
– Task analysis

• Methodology for each:

– Description
– Advantages
– Limitations
– How to develop

• Example:
– The shared calendar application

• System-centered descriptions are used to communicate precise information with

developers.

11
 Task description and analysis, continued
Scenarios

Describes human activities or tasks in a story that

Describes human activities or tasks in a story that
Description allows exploration and discussion of contexts, needs,
allows exploration and discussion of contexts, needs,
and requirements.
and requirements.

Telling a story is a natural way for people to explain what

they are doing or how to achieve something. It also allows
Advantages
us to identify the stakeholders and the products involved
in the activity.

Morefocused
More focused onon
task characteristics
task than thethan
characteristics detailthe
of interface
detail design and layout. [2]
Limitations
of interface design and layout. [2]

To Develop Focus on what users are trying to achieve.

Focus on what users are trying to achieve.

12
 Task description and analysis, continued
Use Cases

The main emphasis is on user-system interaction, but

The main emphasis is on user-system interaction,
also user goals. but also user goals.
Description

It
Itisiseasy to grasp
easy key features
to grasp in the user-system
key features interaction activities.
in the user-
Advantages
system interaction activities.

Traditional use cases contain certain assumptions,

Limitations including that there is a piece of technology to interact
with, and the kind of interaction to be designed.

Identify the
Identify theactors, thenthen
actors, examine these actors
examine these and identify
actors their goal or goals in using the system
and
To Develop
identify their goal or goals in using the system.

13
 Task description and analysis, continued
Essential Use Cases

A structured narrative consisting of three parts: a

Aname
structured narrativethe
that expresses consisting of three
overall user parts: a
intention, a
name that
stepped expresses
description ofthe overall
user user
actions, intention,
and a steppeda
Description
stepped description
description of of user actions,
system and a stepped
responsibilities.
description of system responsibilities.

Represents a more
Represents general
a more case than
general casea scenario
than a embodies,
scenario and tries to avoid the assumptions of
embodies,
Advantages
and tries to avoid the assumptions of a traditional use
case.

Difficult to capture concrete and specific activities while maintaining the generality required.
Limitations
Difficult to capture concrete and specific activities
while maintaining the generality required.

Identify user roles, then examine these roles and identify the users’ goal or goals in using the sys
To Develop
Identify user roles, then examine these roles and
identify the users’ goal or goals in using the
system.

14
 Task description and analysis, continued
Task Analysis

Used to analyze the underlying rationale and purpose of

Used
what to analyze
people are the underlying
doing: what arerationale and to
they trying purpose of
achieve,
what
whypeople are trying
are they doing:towhat are they
achieve trying
it, and howto achieve,
are they
Description
why are they trying to achieve it, and how are they
going about it, e.g. Hierarchical Task Analysis (HTA) &
going about it, e.g. Hierarchical
GOMS. Task Analysis (HTA) &
GOMS.

Task analysis
Task analysis establishes
establishes a foundation
a foundation of existingofpractices
existing onpractices
which to build new requirements o
Advantages
on which to build new requirements or to design new
tasks.

In the hands of inexperienced practitioners, too much level

of detail may be entered into; for systems with diffuse
Limitations
objectives, time may be wasted by attempting to apply
task analysis to intractable material. [2]

Break aatask
Break taskdown intointo
down subtasks and then
subtasks intothen
and sub-subtasks and so on.
into sub-
To Develop
subtasks and so on.

15