CCS370-UI AND UX DESIGN PIT-CSE-III Year –V

COMPUTATION SEM

PANIMALAR INSTITUTE OF TECHNOLOGY

DEPARTMENT OF CSE
R-2021
ACADEMIC YEAR :2022-2023
BATCH :2021-2025
YEAR/SEM :III/V
SUBJECTCODE/TITLE :CCS370/UI AND UX DESIGN
UNIT-5
RESEARCH, DESIGNING, IDEATING, & INFORMATION
ARCHITECTURE

1
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
UNIT V RESEARCH, DESIGNING, IDEATING, &INFORMATION
ARCHITECTURE
Identifying and Writing Problem Statements - Identifying Appropriate Research
Methods - Creating Personas - Solution Ideation - Creating User Stories - Creating
Scenarios - Flow Diagrams - Flow Mapping - Information Architecture

IDENTIFYING AND WRITING PROBLEM STATEMENTS

What are Problem Statements?
 Problem statements are concise descriptions of design problems. Design teams use
them to define the current and ideal states, and to freely find user-centered solutions.
 Then, they use these statements—also called points of view (POVs)—as reference
points throughout a project to measure the relevance of ideas they produce.

Examples of problem statements:

 Users of our newspaper app often export content from our app, rather than sharing
content through our app. This is a problem because target audiences are less likely to
know that the content came from our app, leading to lower conversion rates. This is
also a problem for app users, as exporting content is time-consuming and could lead to
a decrease in app usage.
 Sales reps spend a long time planning which leads to visit each month. Because
planning is done manually — using Excel spread sheets and printed paper lists — sales
reps find it difficult to meet their targets. Many have complained that keeping track of
which leads to visit takes away from the time they can spend with them. This is a
problem because, when targets are not met, the business risks losing revenue.

How to Write a Problem Statement?

A problem statement should include:
The background of a problem: Which organization or department has the problem and
what is the problem? Why has the problem arisen? This is what discoveries are for: to
uncover root causes.
The people affected by the problem: There could be multiple user groups affected by a
specific problem in different ways. In the problem statement, you should call out how the
problem affects users. In some cases, internal employees can be affected by a problem, as
they often bear the brunt of poor user experiences –- for example, by handling disgruntled
customers.

2
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
The impact of the problem on the organization: If the problem is not fixed, what will be
the effect on the organization? Reputational damage? Paying unavoidable costs? Losing out-
of-market share? In some cases, you may want to quantify the impact in order to convince
your organization to fix the problem. The discovery could involve working out how much
this problem costs the organization, and this information could end up in your problem
statement.
To gather the relevant facts for your problem statement, you can use a simple technique
called the 5 Ws, which involves answering the questions below. This activity can be included
in a discovery kick-off workshop with your team and stakeholders.
 Who is affected by the problem?
 What is the problem?
 Where does this problem occur?
 When does the problem occur?
 Why does the problem occur? Why is the problem important?

A problem statement should:

 Not be a laundry list of unrelated problems. A discovery effort should have one
problem statement, and the problem statement should be focused on one problem. Of
course, a single problem could cause further problems, and those related problems can
be added to your problem statement. But listing many unrelated problems is a sign that
you’re tackling too much.
 Not contain a solution. Leave solutions out of your problem statement. At the
beginning of discovery, there are too many unknowns, so the the best solution is not
obvious. At the end of your discovery, you’ll be in a good position to confidently put
forward solution ideas that address the problem and take into account what you’ve
learned.
 Be brief. Problem statements are effective when they’re concise. If you can condense
your problem statement down to a few sentences, others will quickly understand what
you focus on and why, and what’s out of scope. Spend some time to draft and redraft
the problem statement with your team.

Problem Statements Don’t Need to Be Negative

Problem statements can also capture opportunities
Here’s an example of a problem statement that highlights an opportunity, rather than a
problem that needs to be fixed:
The process of purchasing a newly built home can take a long time and requires many offline
activities. This means sales often take a long time to close. There’s an opportunity to make
3
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
home buying quicker and easier, and thus improve customer-satisfaction ratings and sales.
How to Use Problem Statements
 The problem statement can be used as the starting point for structuring the discovery
work. For example, if the problem statement was about improving the home-buying
process, the goal for the discovery should be to learn about opportunities to make
home buying quicker and easier.
 Once we have a discovery goal, it becomes easier to know what unknowns need
research. For example, in this case, we probably want to know things like:
 Which activities do homebuyers perceive as difficult or time-consuming?
 Which activities or use cases can slow down the home-buying process and why?
 What does the end-to-end journey currently look like?

Need to define problem statement:

 Well-constructed, valid and effective problem statements are vital for your design
team to navigate the entire design process.
 problem statements are what teams produce in the Define stage.
 To find the best solutions, your team must know what the exact problems are—i.e.,
you first need to define a problem statement.
 The goal is to articulate the problem so everyone can see its dimensions and feel
inspired to systematically hunt for suitable solutions.
 When we unite around a problem statement, the team will have a common view of
how users see what they must tackle.
 From there, all your team will know exactly what to look for and what to avoid.

Features of good problem statement:

 Human-centered: Frame problem statements from insights about users and their needs.
 Have the right scope:
 Broad enough to permit creative freedom, so you don’t concentrate too narrowly on
specific methods for implementing solutions or describing technical needs; but
 Narrow enough to be practicable, so you can eventually find specific solutions.
 Based on an action-oriented verb (e.g., ―create‖ or ―adapt‖).
 Fully developed and assumption-free.
POV :
 Design teams refer to a problem statement as a ―point of view‖ (POV) because they
should word problem statements from the users’ perspective and not let bias influence
them.
4
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
 With an effective POV, your team can approach the right problem in the right way.

A Point Of view (POV) is a meaningful and actionable problem statement, which will allow
you to ideate in a goal-oriented manner.

How to Define Problem Statements through a Point of View Madlib

 To define a problem statement, the team must first examine recorded observations
about users. It must capture your users’ exact profile in the problem statement or POV.
 So, the team need to synthesize research results and produce insights that form solid
foundations

Teams typically use a POV Madlib to reframe the challenge meaningfully into an actionable
problem statement. The POV madlib is a framework you use to place the user, need and
insight in the best way. This is the format to follow:

[User… (descriptive)] needs [need … (verb)] because [insight… (compelling).]

5
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

A POV is combined these three elements—user, need, and insight—as an actionable

problem statement that will drive the rest of your design work.

Example:

With a valid problem statement, the team can explore the framed ―why‖ questions with
―how‖-oriented ones to proceed to find potential solutions. If you have a good problem
statement if team members:

6
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
 Feel inspired.
 Have the criteria to evaluate ideas.
 Can use it to guide innovation efforts.
 Can’t find a cause or a proposed solution in it

Identifying Appropriate Research Methods

Methods of interpreting results and findings from the observation oriented Empathise phase
include:
Space Saturate and Group and Affinity Diagrams – Clustering and Bundling Ideas and
Facts
 In space saturate and group, designers collate their observations and findings into one
place, to create a collage of experiences, thoughts, insights, and stories.
 The term 'saturate' describes the way in which the entire team covers or saturates the
display with their collective images, notes, observations, data, experiences, interviews,
thoughts, insights, and stories in order to create a wall of information to inform the
problem-defining process.
 It will then be possible to draw connections between these individual elements, or
nodes, to connect the dots, and to develop new and deeper insights, which help define
the problem(s) and develop potential solutions.
“How Might We” Questions

 Start using your POV by asking a specific question starting with: ―How Might We‖ or
―in what ways might we‖.
 How Might We (HMW) questions are questions that have the potential to spark
ideation sessions such as brainstorms.
 They should be broad enough for a wide range of solutions, but narrow enough that
specific solutions can be created for them.
Example:
For example, youths tend not to watch TV programs on the TV at home, some questions
7
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
which can guide and spark the ideation session could be:

 How might we make TV more social, so youths feel more engaged?

 How might we enable TV programs to be watched anywhere, at anytime?
 How might we make watching TV at home more exciting?

The HMW questions open up to Ideation sessions where you explore ideas, which can
help you solve your design challenge in an innovative way.

Why-How Laddering
 In Why-How Ladder ultimate aim is to find out how you can solve one or more
problems.
 The Why-How Laddering starts with asking Why to work out How they can solve
the specific problem or design challenge.
Creating Personas
What are Personas?
Personas are fictional characters, which you create based upon your research in order to
represent the different user types that might use your service, product, site, or brand in a
similar way. Creating personas helps the designer to understand users’ needs, experiences,
behaviors and goals.
Personas are distilled essences of real users. In user experience (UX) design, you use
personas to build empathy with target users and focus on their world. You should always
create personas from observations about real users, personas should never be invented out of
your assumptions about your users.
Example:
We divide users into manageable groups and represent each with a typical embodiment – a
persona. For instance, for an app that helps students budget, ―Amy‖ represents 18-year-old
females who must adapt to college life. Through Amy, we see how our app helps these users
in their day-to-day activities. We imagine Amy has just started banking online, lives in
shared housing and works weekends. Her goal is to save money. Her scenario: she stretches
$70 to cover her week’s groceries.

8
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

Create Effective Personas

 Personas are deliverables in design thinking’s Define phase. As they’re extremely
helpful in ideation, they should feature early in design processes. To create them, you:
 Collect extensive data on target users.
 Determine the qualities of and differences between users.
 Develop a hypothesis from the research, determining the qualities of and differences
between users.
 Ensure stakeholders agree on the hypothesis about the users.
 Determine a number of personas – more than one per project, but focus especially on
one.
 Name and describe each persona in 1-2 pages, including:
 A picture.
 User’s values, interests, education, lifestyle, needs, attitudes, desires, limitations, goals
and behavior patterns.

9
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
How to Use Personas in Design Projects
When you bring personas into projects, you help prevent stakeholders from designing for
themselves. It also keeps them from stretching generic users to fit designs. Personas help in
quick prototype testing, too. You’ll confirm a persona works well when you ensure that
―he/she‖:

1. Stays in context – What specific points about his/her situation can you map to how
he/she can use your product now?

2. Reflects a target user’s real behavior patterns, attitudes, skillset, motivations and goals
within the product’s domain.

3. Has an end-goal – What does the user want to achieve? What features would help
him/her do that best?

4. Faces realistic, relevant scenarios—written from the persona’s perspective—to

envision how users would find they’d use the product to attain a particular goal.

5. Occupies a clear setting – a day-in-the-life approach that shows what he/she

encounters in what environment.

6. Has visible pain points – What’s the hardest/most frustrating aspect of his/her
situation/context?
 Extra details about the persona (e.g., interests) – anything to make him/her more real
and relevant and help build empathy. A written story is better than bullet points.

 Describe several situations/scenarios prompting the persona to use your product – put
him/her in contexts with problems to overcome.

 Include everyone involved in the project so they’ll accept the persona or advise
revisions.

 Send them the persona to use in their work.

 Ensure everyone develops scenarios – these should expose the persona optimally to
potential use cases.

 Make continuous adjustments – revisit the persona; add new features; add required
new personas; discard outdated personas.
10
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

Four Different Types of Personas

1. Goal-directed Personas
This persona cuts straight to the nitty-gritty. ―It focusses on: What does my typical user want
to do with my product?‖. The objective of a goal-directed persona is to examine the process
and workflow that your user would prefer to utilize to achieve their goals in interacting with
your product or service.

11
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

2. Role-Based Personas
The role-based perspective is also goal-directed, and it also focuses on behavior. The
personas of the role-based perspectives are massively data-driven and incorporate data from
both qualitative and quantitative sources. The role-based perspective focuses on the user’s
role in the organization.
3. Engaging Personas
Engaging personas can incorporate both goal and role-directed personas, as well as the more
traditional rounded personas. These engaging personas are designed so that the designers
who use them can become more engaged with them. The idea is to create a 3D rendering of a
user through the use of personas. The more people engage with the persona and see them as
’real’, the more likely they will be to consider them during the process design and want to
serve them with the best product.

12
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

4. Fictional Personas
The fictional persona does not emerge from user research (unlike the other personas), but it
emerges from the experience of the UX design team. It requires the team to make
assumptions based upon past interactions with the user base and products to deliver a picture
of what, perhaps, typical users look like.

10 steps to Creating Your Engaging Personas and Scenarios

Engaging personas emphasize how stories can engage and bring the personas to life. This 10-
step process covers the entire process from preliminary data collection, through active use, to
the continued development of personas. There are four main parts:
Data collection and analysis of data (steps 1, 2),
Persona descriptions (steps 4, 5),
Scenarios for problem analysis and idea development (steps 6, 9),
Acceptance from the organization and involvement of the design team (steps 3, 7, 8, 10).
The 10 steps are an ideal process, but sometimes it is not possible to include all the steps in
the project.

Collect data. Collect as much knowledge about the users as possible. Perform high-quality
user research of actual users in your target user group. In Design Thinking, the research
phase is the first phase, also known as the Empathise phase.

Form a hypothesis. Based upon your initial research, you will form a general idea of the
13
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
various users within the focus area of the project, including the ways users differ from one
another – For instance, you can use Affinity Diagrams and Empathy Maps.

Everyone accepts the hypothesis. The goal is to support or reject the first hypothesis about
the differences between the users. You can do this by confronting project participants with
the hypothesis and comparing it to existing knowledge.

Establish a number. You will decide upon the final number of personas, which it makes sense
to create. Most often, you would want to create more than one persona for each product or
service, but you should always choose just one persona as your primary focus.

Describe the personas. The purpose of working with personas is to be able to develop
solutions, products and services based upon the needs and goals of your users. Be sure to
describe personas in such a way as to express enough understanding and empathy to
understand the users.

You should include details about the user’s education, lifestyle, interests, values, goals,
needs, limitations, desires, attitudes, and patterns of behavior.

Add a few fictional personal details to make the persona a realistic character.

Give each of your personas a name.

Create 1–2 pages of descriptions for each persona.

Prepare situations or scenarios for your personas. This engaging persona method is directed
at creating scenarios that describe solutions. For this purpose, you should describe a number
of specific situations that could trigger the use of the product or service you are designing. In
other words, situations are the basis of a scenario. You can give each of your personas life by
creating scenarios that feature them in the role of a user. Scenarios usually start by placing
the persona in a specific context with a problem they want to or have to solve.

Obtain acceptance from the organization. It is a common thread throughout all 10 steps that
the goal of the method is to involve the project participants. As such, as many team members
as possible should participate in the development of the personas, and it is important to
obtain the acceptance and recognition of the participants of the various steps. In order to
achieve this, you can choose between two strategies: You can ask the participants for their
opinion, or you can let them participate actively in the process.

14
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
Disseminate knowledge. In order for the participants to use the method, the persona
descriptions should be disseminated to all. It is important to decide early on how you want to
disseminate this knowledge to those who have not participated directly in the process, to
future new employees, and to possible external partners. The dissemination of knowledge
also includes how the project participants will be given access to the underlying data.

Everyone prepares scenarios. Personas have no value in themselves. Until the persona
becomes part of a scenario – the story about how the persona uses a future product – it does
not have real value.

Make ongoing adjustments. The last step is the future life of the persona descriptions. You
should revise the descriptions on a regular basis. New information and new aspects may
affect the descriptions. Sometimes you would need to rewrite the existing persona
descriptions, add new personas, or eliminate outdated personas.

15
CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

16
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
Example of How to Make a Persona Description – Step 5

We will let you in on the details about our persona’s education, lifestyle, interests, values,
goals, needs, limitations, desires, attitudes, and patterns of behavior. We’ve added a few
fictional personal details to make our persona a realistic character and given her a name.

Hard Facts
Christie is living in a small apartment in Toronto, Canada. She’s 23 years old, single, studies
ethnography, and works as a waiter during her free time.

Interests and Values

Christie loves to travel and experience other cultures. She recently spent her summer holiday
working as a volunteer in Rwanda.

She loves to read books at home at night as opposed to going out to bars. She does like to
hang out with a small group of friends at home or at quiet coffee shops. She doesn’t care too
much about looks and fashion. What matters to her are values and motivations.

On an average day, she tends to drink many cups of tea, and she usually cooks her own
healthy dishes. She prefers organic food; however, she’s not always able to afford it.

Computer, Internet and TV Use

Christie owns a MacBook Air, an iPad and an iPhone. She uses the internet for her studies to
conduct the majority of her preliminary research and studies user reviews to help her decide
upon which books to read and buy. Christie also streams all of her music, and she watches
movies online since she does not want to own a TV. She thinks TV’s are outdated, and she
does not want to waste her time watching TV shows, entertainment, documentaries, or news
that she has not chosen and finds 100% interesting herself.

A Typical Day
Christie gets up at 7 am. She eats breakfast at home and leaves for university at 8.15 every
morning.

Depending on her schedule, she studies by herself or attends a class. She has 15 hours of
classes at Masters level every week, and she studies for 20 hours on her own.

She eats her lunch with a study friend or a small group.

She continues to study.

17
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

She leaves for home at 3 pm. Sometimes she continues to study for 2-3 hours at home.

Three nights a week, she works as a waitress at a small eco-restaurant from 6 pm to 10 pm.

Future Goals
Christie dreams of a future where she can combine work and travel. She wants to work in a
third-world country, helping others who have not had the same luck of being born into a
wealthy society. She’s not sure about having kids and a husband. At least it’s not on her radar
just yet.
Evoking Empathy with Engaging Personas
Developing an engaging persona starts with user research. Collecting insights about the
social and cultural backgrounds of the users, their psychological traits, their feelings of
frustration, and their goals will help you develop a broad knowledge of the users

Compare the following two user descriptions, to get an understanding of what we mean.

Description of the target group of a social media platform for seniors, based on research
results only:

Single elderly inhabitants of the Timbuktu region

Living independently in the house they own

Children living at a distance with their families

Are feeling loneliest when they have to eat alone

Description of an archetypical user of a social media platform for seniors, including some
fictional elements:
Example:
Mrs. Green is 68 years old, and always loved cooking for her husband. Since he passed away,
she has been living alone in her house. Her children are all grown up, and are living outside
the Timbuktu region with their families. They only come to visit her every other week. Mrs.
Green doesn’t want to bother them more, since they have busy lives with their work,
children, and friends. She often feels lonely when there’s no-one around, especially during
meal times. She hates sitting at the table all by herself, so she doesn’t cook as often as she
used to. Sometimes she just has a sandwich in front of the television.

18
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
Both descriptions are based on the same research data. The first is not incorrect, but is far
less helpful when you want to evoke the same empathy you have developed for the target
group, in your fellow designers or client. Once you start putting this data in context, the
archetypical user will come alive as a person they can feel for. An image of the user in
context will help you strengthen this effect even further, as will some other elements that you
should include in a persona.

Elements to Include in a Persona

There are six common pieces of information that make up a persona:

Name, age, gender, and an image of the persona, preferably including some context in the
background

A tag line, indicating what the persona does or considers relevant in his or her life

The experience and relevant skills the persona has in the area of the product or service you
will be developing

Some context to indicate how he/she would interact with your product or service (e.g., the
voluntariness of use, frequency of use, and preferred device)

Any goals, attitudes, and concerns he/she would have when using your product or service

Quotes or a brief scenario, that indicate the persona’s attitude toward the product or service
you’re designing. If the persona already uses an existing product or service to meet his or her
needs, you might describe the use of that here.

19
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

Solution Ideation

Ideation is a creative process where designers generate ideas in sessions (e.g., brainstorming,
worst possible idea). It is the third stage in the Design Thinking process. Participants gather
with open minds to produce as many ideas as they can to address a problem statement in a
facilitated, judgment-free environment.
Converging
At some point in your ideation session, you’ll have reached a critical mass of ideas, and it
will become unproductive to try to keep pushing for more. This is different from the natural
creative slumps that teams experience throughout ideation sessions, and means it is a good
point to stop and focus on pruning. This is referred to as the ―convergent stage‖—where
ideas are evaluated, compared, ranked, clustered and even ditched in an attempt to pull
together a few great ideas to act on
Dot Voting
You write all of the ideas which have been generated in the ideation session down on
individual sticky notes.
20
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
Then you give all participants a number of votes (around 3–4 should do) to choose and write
down their personal favorite ideas.
Participants vote by using stickers or simply using a marker to make a dot on the ideas they
like.
You can also use variations in color in order to let participants vote on which ideas they like
the most or which they dislike the most.
You can invent other voting attributes when it makes sense.

This process allows every member to have an equal say in the shortlisted ideas.

Four Categories Method

The Four Categories method entails dividing ideas according to their relative abstractness,
ranging from the most rational choice to the ―long shot‖. The four categories are: the rational
choice, the most likely to delight, the darling and the long shot.
Bingo Selection
The Bingo Selection method inspires participants to divide ideas. However, in this method,
the facilitator should encourage the participants to split ideas according to a variety of form
factors, such as their potential applications in a physical prototype, a digital prototype and an
experience prototype.
Idea Affinity Diagrams
Use affinity diagrams or similar activities to cluster similar ideas together and make
connections between them that will help you uncover patterns or themes that may be
promising.
Idea Selection Criteria
These idea selection criteria will help you at this stage to provide a guide for choosing ideas
which fit well into your goals, your research about your users and their needs
Now Wow How
The Now Wow How Matrix provides a mechanism for evaluating ideas on a scale of:

Now: ideas that can be implemented immediately but which lack novelty.

Wow: ideas that can be implemented and are innovative.

How: ideas that could possibly be implemented in the future.

Idea Selection – Apply Edward De Bono's Six Thinking Hats

21
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

White Hat: The White Hat calls for information which is known or needed. It’s all about this:
―The facts, and nothing but the facts.‖

Yellow Hat: The Yellow Hat symbolizes optimism, confidence and brightness. Under this
hat, you explore the positives and probe for value and benefit.

Black Hat: The Black Hat is all about judgment. When you put on this hat, you’re the devil's
advocate where you try to figure out what or why something may not work.
Red Hat: The Red Hat calls for feelings, hunches and intuition. When you use this hat, you
should focus on expressing emotions and feelings and share fears, likes, dislikes, loves and
hates.

Green Hat: The Green Hat focuses on creativity: the possibilities, alternatives and new ideas.
It's your opportunity to express new concepts and new insights.

Blue Hat: The Blue Hat is used to manage the thinking process. It's your control mechanism
that ensures the Six Thinking Hats guidelines are observed.

Creating User Stories

What are User Stories?

User stories are short statements about a feature, written from a user’s perspective. A well-
defined user story does not spell out the exact feature, but rather what the user aims to
achieve, to give agile teams the freedom to identify the best possible way to implement the
feature.

22
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

The User
While user stories are mostly written from the end users’ point of view, that’s not always
true. Teams can write them from the perspective of business stakeholders, partners and even
employees and team members.

The Goal / Action

User stories are problem- or goal-oriented and do not include specific solutions or features.
Instead, they aim to serve as a springboard for teams to ideate and arrive at the most optimal
solution to solve the problem for the user. Here’s a hypothetical user story for a mobile
application for diners:

―As a diner, I want to quickly locate good restaurants so that I can get good food fast.‖

Notice that this user story doesn’t include specific features. These come later, when team
members take the user story and work their way towards solutions or features, which, for this
user story, could include:

Be able to save favorite restaurants.

Sort restaurants by location, reviews or delivery times.

View recommendations by friends.

The Outcome
The best stories are ones that lead to measurable outcomes. Examples of good outcomes are
an X% increase in profile completion rates or an N% drop in payment flow errors. Outcomes
that are tied to users or business goals free up the team to think about solutions to problems
instead of churning out features for the sake of shipping something.

23
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
Features of user story
 A user story is short, specific and goal-oriented. It is a one-sentence statement that
tends to have the following structure: ―As a , I want so that ‖.
 User stories are collaborative design tools. All project stakeholders are expected to
participate in the definition and sorting of user stories.
 User stories focus the project on the perspective of those who will use it.
User stories are – obviously – user-centered
The format of a user story forces you to think about others and keep them and their needs in
focus, to work a little bit on your empathy and place yourself in the users’ shoes.
User stories are simple and accessible
Use cases have a specific grammar and structure. Therefore, not everyone participates in
defining them. Only the team or person in charge of defining the requirements or functional
specs would write them.
"As a.... "The role refers to the one who makes the action and who benefits.

"I want... "It is the action executed.

"So That... "It is the added value that the user gets from the action.
User stories are collaborative
To promote a concrete, realistic and shared vision of the end user. User stories are your best
ally here
User stories promote a shift in the way a project is discussed. We do not focus anymore on
solutions and features.
User stories are about the present and the future
A user story has just the right level of detail. At a more abstract level, we have epics. In
Agile, ―epics‖ are used for a high-level overview of the needed features.

Writing User Stories

In many cases user stories are not created by the design or development team – they’re
provided by a customer or a business user to try and explain what they’d like the finished
product to look like
In larger organizations, this responsibility may be covered by product managers in other
organizations it may fall within the remit of the UX team.
A user story is going to capture a requirement of the product functionally they may also be
used to describe non-functional capacities of products too (for example privacy or security
requirements).
The idea is to use a simple question and answer format to develop the story. Then the
designer or developer records each story on a single card. This story may then be revised for
clarity after the requirements capture exercise is complete.
24
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
The generally accepted format for user stories is:

―As a , I want , for this ‖

Writing good user stories in Scrum requires an understanding of the basic user story
template, a focus on the user or customer, and a clear picture of the desired functionality.

User Story Template

When writing a user story, remember that user stories follow a standard template:

As a < type of user >, I want < some goal > so that < some reason >.
User Stories and Agile Development
User stories are used in agile to define all functionality of the final product. They are not set
in stone and it is completely accepted that requirements can (and often will) change
throughout the lifecycle of a project.
Benefits of Using User Stories in Design and Development
There are several benefits of using user stories in design and development cycles:

 They are simple and quick to understand.

 They allow programmers to quickly (using agile) implement customer/user value
 They don’t need very much maintenance
 They can be discounted except when they are being used in development
 They allow a project to be chunked into smaller milestones
 They make it easier to estimate costs on a project for development
 They facilitate cooperative working with clients and users
The Drawbacks of Using User Stories in Design and Development
There are possible drawbacks of using user stories and in particular of becoming overly-
reliant on them at the expense of other tools:

 They are difficult to work into large scale projects (where thousands of stories might
be required)
 They may be too vague to be useful and require a lot of back and forth between
developers and clients
 They fail to capture performance measurements and sometimes non-functional aspects
of the system – e.g. they are too simple
What is a user story?
A user story is a short, simple description of a feature told from the perspective of the person
who desires the new capability, usually a user or customer of the system. User stories
typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.
25
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
What Is a Good User Story?
Agile user stories are composed of three aspects that Ron Jeffries named in 2001 with the
wonderful alliteration of card, conversation, and confirmation:
Card: Written description of the story, used for planning and as a reminder
Conversation: Conversations about the story that serve to flesh out the details of the story
Confirmation: Tests that convey and document details that can be used to determine when a
story is complete.
Examples of User Stories
As a site member, I can fill out an application to become a Certified Scrum Trainer so that I
can teach Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO)
courses and certify others.
As a trainer, I want my profile to list my upcoming classes and include a link to a detailed
page about each so that prospective attendees can find my courses.
As a site visitor, I can access old news that is no longer on the home page, so I can access
things I remember from the past or that others mention to me.
As a site visitor, I can see a list of all upcoming ―Certification Courses‖ and can page through
them if there are a lot, so I can choose the best course for me.
Creating Scenarios
What is a User Scenario?
A user scenario simply describes a basic story of an action or goal that a user wants to
accomplish.
Scenarios can be used to describe both what currently happens within a system or
environment or more typically the intended behavior within a system or environment.
User scenarios can be useful when defining usability testing too. They enable testers to focus
on the key tasks within a system.
User scenarios help you examine how your design will work.

26
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

When Should Scenario Mapping Be Used in a Project?

Scenario mapping can be effective at many points during a project but there are three great
uses for it at specific stages:

Ideation – if you’re trying to create a new product, then having scenario maps makes it very
easy to explore ideas with your team and with users. It also helps, in a similar means to task
analysis, formulate a shared vision for the project. (See the method below as to how to do
this).

Iteration – if you’re new to a product and you’re going to be involved in creating future
iterations then it’s pretty easy to create scenario maps ―on the fly‖ by observing users with
the current product. (This can be done solo and doesn’t need the method below).

Usability testing – user scenarios can also be used to define which are the most important
areas to test during usability testing and to provide guidance on how it should be done.

27
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

How to Do User Scenario Mapping?

It’s a pretty simple process to create user scenarios and here’s a simple way to conduct it:

First, find a place that you can use to get creative – you’re going to need somewhere where a
group can talk and discuss without being interrupted and without disturbing others. You’re
probably going to need between 2 and 3 hours for the session.

Then invite a bunch of relevant people to the session – the UX team, the development team,
the product manager, etc. but don’t invite too many people, a maximum of 7 is a good idea as
it means everyone can contribute without anyone getting lost in the mix.

Then get some post-it notes, flipchart paper, etc. stuff that makes it easy to capture an idea
and get it in front of everyone. Bring sellotape or blu-tack in case things aren’t sticky enough
for the surfaces in your room.

Explain to everyone present what your objectives are and what a user scenario is – it’s
always good to have everyone on the same page. However, don’t spend too much time on
this either; you want people firing on their creative best not snoring in the corner because
you’ve TMI’d them to death.

Hopefully you have user personas because they’ll come in handy as you map your first user
scenario. What is it that this user must do in this interaction with the product? This tells you
what goes into the scenario.

You also need to provide context to make your scenarios as accurate as possible – the who,
what, when, where and why detail that gives a scenario colour and makes it easy to relate to.

28
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
Then it’s time to take some baby steps and walk through the scenario in the shoes of your
user (referring to your user personas). What will the user do? What information do they need
to get that done? What questions will they need answered or will you need answered to do
this? What assumptions will you have to make to make this work?

Finally, you also want to collect ideas from the team that don’t fit within the scenario but
may be related to it.

After you’ve completed each scenario make a written note of it and stick it to the wall. Try
and get scenarios grouped so that you can make easy sense of them and spot any gaps that
arise.
Repeat this process for each scenario. Until you’ve generated scenarios for every key task the
user will perform with the product.

Need to find more scenarios? Then the question is ―what key tasks must be performed in
order to satisfy the user and/or the business‖ (though it’s worth noting that tasks that satisfy
the business and not the user are unlikely to be performed very often).

Once all your scenarios are complete – take a high-res photo of the wall (it saves you from
having to copy all that data down before you give up the room to someone else) and ensure
that you can read the notes you’ve made in the photo.

The last stage is to compile all that data into something useful (say a spreadsheet or a
flowchart) and then share it with other stakeholders to get their feedback.

29
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

Flow Diagrams
User Flows

Illustration depicting a user flow.

A user flow (also known as a task flow) diagram is a simple chart outlining the steps that a
user has to take with your product or service in order to meet a goal. In contrast to the
customer journey map, the user flow diagram considers only what happens with your product
(that is to say, ignoring all external factors). These diagrams can help designers quickly
evaluate the efficiency of the process needed to achieve a user goal and can help pinpoint the
―how‖ (i.e., execution) of the great ideas identified through brainstorming.

Definition: A user flow is a set of interactions that describe the typical or ideal set of steps
needed to accomplish a common task performed with a product.

Compared to a user journey, the underlying goal of a user flow is much more granular, and
the focus is narrowed to a specific objective within one product.

Some appropriate goals to capture in user flows might be: purchasing a tennis racket on a
sporting goods site, signing up for email updates on a credit-score-monitoring application, or
updating a profile picture on a company’s intranet. These goals can be accomplished in the
30
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
short-term (minutes or hours, at the most), and with a relatively limited set of interactions.

User flows can be represented with artifacts such as low-fidelity wireflows, simple flow
charts, or task diagrams. These maps capture key user steps and system responses; they do
not contextualize the process with emotions and thoughts like a journey map does.

The best research method for obtaining the data to map user flows is usability testing, which
allows us to watch users interacting directly with the product in directed scenarios. As with
user journeys, tools that capture analytics (e.g., click heatmaps) are a useful secondary source
of insights.
Comparison: User Journeys vs. User Flows
The main differences between user journeys and user flows are captured in the table below:

User Journey User Flow

A scenario-based sequence of
A set of interactions that
the steps that a user takes in
describe the typical or ideal set
order to accomplish a high-
Definition of steps needed to accomplish
level goal with a company or
a common task performed
product, usually across
with a product
channels and over time
Macro: Broad and high-level
Micro: Specific and granular
(e.g., the experience of
Focus (e.g., signing up for alerts on a
becoming a new patient of a
website)
medical practice)
Zooms in to understand
Zooms out to consider multiple
Scope interactions within a single
touchpoints and channels
product
What it The user’s actions, emotions, Product-based interactions
captures and thoughts, as well as (key user actions and system
31
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
channels responses)
Appropriate Wireflows, flow charts, or task
Journey maps
artifacts diagrams

To determine whether a user journey or a user flow is best for your specific context, consider
the following questions:

Does your user process involve more than one channel or more than one, known product
(e.g., your company’s website)? User journeys are best for capturing activities dispersed over
multiple channels; user flows are well-suited for interactions within one product.
Can users generally accomplish the goal in minutes or hours, at the most, or will they need to
complete activities over days, weeks, or months? User journeys are better for communicating
activities over longer periods of time; user flows are better for relatively short-term goals.
Will it be critical to understand not only the actions but the emotions and thoughts of users
across more complex decision-making? User journeys capture those; user flows are limited to
sequences of steps, with no additional information about users’ emotional states.

How Do We Design for User Flow?

We begin with the user themselves. Instead of going through the technical specification
documents and trying to base designs on that – we examine what the user’s objective (or
objectives) are and what the business’s objective (or objectives) are.

So for example on a retail website this might include:

User wants to buy a new product

User wants to research alternative products

User wants to return a product

By mapping out all the possible objectives and comparing them to business objectives – it
becomes easy to create user flows. Flows are simply the process steps from the user arriving
on a website to completing their task or tasks.

Once you know what users want to do – you might also want to look at where a user might
arrive on your site and where they are coming from. A user who is responding to e-mail
marketing will probably be delivered to a different place in the site to a user who finds you
through organic search.

32
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

Flow Mapping
Flow maps are designed to represent all possible navigational paths of an interface to help
designers plan. However, there are more that users do on interfaces than navigate. A flow
map that only illustrates navigation doesn’t represent interfaces realistically. It fails to
account for the various interactions that occur on each screen. If flow maps are documents
for planning, such a flow map will only plan to fail.
Real interfaces are dynamic, not static. A static flow map only shows you the next screen
users navigate to

33
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM

In contrast, a dynamic flow map shows each screen’s microinteractions. These are the
elements and components users interact with that move them to the next screen. They also
include non-navigational interactions that occur on the screen. It’s important to plan these out
in your flow map so that you and the people you work with know what to expect.

A dynamic flow map should also display context. When you have a sense of context, you can
better identify task complexity. You can see which screens are forms to fill out, and which
ones are more text-heavy and media-rich than others. These details allow you to plan an
interface that’s more aligned with realistic expectations.

Information Architecture
What is Information Architecture?
Information architecture (IA) is the discipline of making information findable and
understandable. It includes searching, browsing, categorizing and presenting relevant and
contextual information to help people understand their surroundings and find what they’re
looking for online and in the real world.

34
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
IA is used in physical spaces like museums or department stores, as well as in websites and
applications. For instance, in a natural history museum, you will find fossils from the Jurassic
period exhibited together, just as your favorite packet of chips will always be in the snack
aisle of your supermarket.

Information architecture operates from two perspectives:

People perceive information, products and services as places made of language.

These places or information environments can be arranged for optimal findability and
understandability.

Language in this instance means visual elements, labels, descriptions, menus, content. We
can arrange this language so that it works together to facilitate understanding.

Context relates to business goals, funding, culture, technology, politics, resources and
35
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
constraints. Content consists of the document or data types, content objects, volume and
existing structures. Users comprise the audience, tasks, needs, experiences and how they seek
information.

Good information architecture is informed by all three areas, all of which are in flux
depending on the information environment.

IA and UX design
As with all aspects of UX design, information architecture starts with understanding
people—namely, their reasons to use a product or service. A methodical and comprehensive
approach to structuring information is needed to make it findable and understandable
irrespective of the context, channel, or medium employed by the user.

Once you understand how a user behaves and seeks information, you can design a successful
sitemap (like the one shown below), website navigation, user flows and so on.

Designers need to understand the following when designing websites and applications:

the information needs of users

36
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
the site or app’s content

the business goals of the website, app, or organization

An information architect’s deliverables typically include:

site maps

wireframes

hierarchies

navigation

and metadata.

Information architecture should be a holistic process, so when a new product or service is

being designed, it’s important to start with IA. Good IA serves as the foundation of effective
user experience design.

Principles of Information Architecture

The IA’s main focus is on the structure of information first, and the design of the actual user
interface second (if at all);
The IA understands how people actually use content and how the structure should function to
support that;
The IA grasps the range of content and functionality on a project and how that needs to be
structured.

Principle of objects
The principle of objects says that content should be treated as an evolving thing that has its
own lifecycle. Different content has different attributes and behaviors, and this has to be
recognized in order to best utilize that content. You should start every project by identifying
the kinds of content that will be present. That means both on a broad scale and a more
granular one.

Principle of choices
The principle of choices means that you should offer your users meaningful choices.
However, you need to make sure that those choices are focused on something specific. Too
many choices can overwhelm a user and negatively affect their experience using your site.
37
 CCS370-UI AND UX DESIGN PIT-CSE-III Year –V
COMPUTATION SEM
Information should be arranged in hierarchies, avoiding long lists of options, which can
become cumbersome to sort through. Categorizing and sub-categorizing content is much
more effective if you have more than a handful of options to begin with.

Principle of disclosure
It's important to give your users the information they need. But be sure you identify what the
necessary information actually is, and don't just give them information because you feel like
it. Give them the information they need to have an idea of what they can expect to find as
they delve deeper into your site, no more, no less (this is called progressive disclosure).

Principle of exemplars
Describing the content within a category of information via example makes it easier for your
users to understand what they’re getting. It greatly improves user experience. For example,
when browsing categories on Amazon, they often show products that fall within that
category. This makes it easy to immediately identify the correct category, especially if you’re
not exactly sure what the category in question might be called.
Principle of front doors
Half of your visitors are likely going to arrive on your site via a page other than your home
page. That means that every page they land on should include some basic information so that
they know what kind of site they're on. It also means every page should include at least top-
level navigation, as well as navigation to related pages. There are two major avenues that
visitors will access interior pages of your site from: search engine results and social media
links.
Principle of multiple classification
Multiple classification means that there should be different ways for your users to browse the
content on your site. Different people are likely to use different methods for finding the
information on your site. For example, some users may go straight to your search function
while others may want to browse
Principle of focused navigation
Navigational menus should not be defined by where they appear, but rather by what they
contain. Your menus form the primary method for most users to find content on your site. In
many cases, there may be more than one navigational menu on the site, to provide different
ways to access the content.
Principle of growth
On the vast majority of sites, content is a fluid, changing thing. The amount of content you
have on a site today may be only a small fraction of what you’ll have tomorrow, next week,
or next year. Organize your content in a way that allows it to grow over time. Your
navigational menus and general information architecture should be able to scale to
accommodate a lot of content without becoming cumbersome or unwieldy.
38