DEPARTMENT OF INFORMATION TECHNOLOGY

ACADEMIC YEAR 2024-25(EVEN)

Course Code & Name: CCS370 & UI/UX DESIGNS

Degree/Branch/Year/Sem: B.tech/IT/III/VI

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.
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 canhelp 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 designerswho 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 aboutthe 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 senseto 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 bycreating 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 alwaystrue. 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 thisuser 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 onthis 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 theuser 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 the
steps that a user takes in order toA set of interactions that describe
accomplish a high- level goal with athe typical or ideal set of steps
Definition company or product, usually acrossneeded to accomplish a common
channels and over time task performed with a product

Macro: Broad and high-level (e.g.,

the experience of becoming a new Micro: Specific and granular (e.g.,
Focus patient of a medical practice) signing up for alerts on a website)

Zooms in to understand interactions

Scope Zooms out to consider multiple within a single product
touchpoints and channels

What​ it The user’s actions, emotions, and​ Product-based​ interactions

captures thoughts,​ as​ well​ as (key user actions and system

channels responses)
Appropriate Wireflows, flow charts, or task
artifacts Journey maps 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 tosequences 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
theelements 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
outin 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
canbetter 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’renot 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.