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.

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 includedin 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 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.
• 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 allowyou 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).]

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:
• 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 andFacts
• 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 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.
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.
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.
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.
 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.
 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 inthe
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

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 placingthe 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.
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.
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.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 GoalsChristie 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

radarjust 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.
Both descriptions are based on the same research data. The first is not incorrect, but is farless
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.
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 itwill
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.

Then you give all participants a number of votes (around 3–4 should do) to choose and writedown
their personal favorite ideas.
Participants vote by using stickers or simply using a marker to make a dot on the ideas theylike.
You can also use variations in color in order to let participants vote on which ideas they likethe
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

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

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 thishat,
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 mechanismthat
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.

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.
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 bestally
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. InAgile,
―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.
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 >.

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 astory 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 orenvironment 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 focuson
the key tasks within a system.
User scenarios help you examine how your design will work.
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.

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
asit 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.
Then it’s time to take some baby steps and walk through the scenario in the shoes of youruser
(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.
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 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

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 productsUser

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.
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
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.
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
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 seekinformation.

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 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,Hirerachies, 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 userinterface second (if at all);
The IA understands how people actually use content and how the structure
should function tosupport that;
The IA grasps the range of content and functionality on a project and how
that needs to bestructured.

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.

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.