Storyboards

A story board is basically a visual depiction of a scenario.

"A storyboard is a series of sketched frames that visually depict how and under what circumstances; environmental and emotional does a user engage with the solution being developed."

if story boards are just scenarios drawn out, then why make them? Storyboards provide a few important advantages over scenarios:

• Better visualization of environment, a picture is worth a thousand words
• Visualize physical constraints, size of space, setting
• Depict users motivation and emotion
• Visualize interactions between multiple users.

Elements of a Storyboard

• Zoom: how wide/narrow is the focus of the frame, on the device on the user, the environment
• POV: from what perspective is the frame depicted, 1st person or 3rd person?
• Detail: what is the frame trying to communicate, the interaction, the users mood, the situation, what's the frame's focus?
• Emotion: What emotion is the user expressing: Lonely, Guilty, Happy, Energized, Board,etc
• Setting: where is the action taking place, in a car, on transit, at home, the toilet 

When creating storyboards, there are a number of things that need to be thought out:

• How many frames should the storyboard be?
• Should it depict one interaction by one user? or many interactions by many users?
• how will time be represented, sequential interactions or ones that span a day or longer?
• how will the actor(s) be represented in the frames, POV? 3rd person?
• Should there be text? if so how much?

when making these decisions your audience should be taken into account, if you're just creating a storyboard to flush out your own ideas, then as long as it makes sense to you great. However storyboards are often used to convey your idea to clients or the team, in those cases you need to keep the message your trying to convey in mind and just ask yourself, does this communicate my message?

Scenarios

Scenarios are descriptions of how specific users are leveraging technology to solve a particular problem within in a defined context.

"Scenarios are short stories about specific users who are using technology designed to accomplish specific goals in a specific context."

Scenarios bring together the research results of user needs and ideas and how to solve those needs; they are used to address user needs with design ideas. Scenarios are usually one ore two paragraphs long and they describe a particular use case, they expose various characteristics about our user and under what circumstance that user would need the solution; the elements of a scenario are:

• Setting: the situation or state of the system/context of use in which the activity occurs
• Actor(s): person or people performing the action in the given scenario
• Objectives: what is the person or people trying to accomplish
• Actions: activities that are being done to accomplish the actors objectives
• Events: things that happen to the users while performing the actions in the scenario.

Scenarios should aim to answer the following questions directly or indirectly  

• What: what problem does the user need solved?
• Why: why can't your user solve their problem without your solution
• How: how is your solution going to facilitate your users solution.
• Where: under what circumstances would your user want to engage with your application
• When: at what point in their day would your user want to engage with your application

Scenarios are a process, they are open ended, easily revised stories that are up for discussion, once a scenario is created it can be revised numerous times by the team, it is a design artifact that can be shared with the client for feedback or to gain further insight, it's used as an input not output. Scenarios like personas and all other design artifacts are used to understand a problem and communicate that understanding to further investigate and collaborate on the solution.

there are multiple types of scenarios

• Problem scenarios: define the problem that is faced before and type of solution is proposed
• Goal scenarios: describe the the goal and any roadblocks between the user and what they're trying to accomplish
• Activity scenarios: briefly describe how the proposed solution is going to help the user with their problem.
• Task scenarios: are elaborate activity scenarios that describe with great detail the interaction between the user and the proposed solution. 
• Information scenarios: describe how the users view and interpenetrate the information presented to them
• Interaction scenarios: describe the physical actions a user must take when interacting with a solution and how the solution responds to the actions.

Good design is a pragmatic process, not all types of scenarios are going to be valuable every single time, the key is to focus efforts on value added artifacts. If there is no value added, if the artifact doesn't help the team understand or communicate the problem or solution then the opportunity cost is taking away from effort that can be spent on something more valuable. the catch however is it take a lot of experience to know which artifacts will be value added and under what circumstances, thus a try it before you buy it approach is recommended; that is start each type of scenario and mature it to such a point that you can either definitely see value or definitely see no value.

Scenarios are short stories that help the design team understand:

• What the users problem is?
• Why the user has the problem?
• How is the solution going to solve the problem?
• Where is the user going to use the solution?
• When are they going to use it?

Scenarios should also be quick; these aren't suppose to be master works, they are after all just a tool to help understand and design the solution, 15 to 30 minutes per scenario assuming that you understand the problem domain and have completed your research. Rough and fast is the idea, get your thoughts on paper, iterate and refine. The reason you don't want to put too much effort into scenarios or any design artifacts is because you don't want to become a victim of "Escalation of commitment"

Scenarios are an excellent artifact to build before getting into wire-frames, and prototypes, they are a sounding board to help designers understand how to best go about designing solutions to help users accomplish their goals. Scenarios facilitate the reflection of intended and unintended consequences of their designs to maximize the value added aspects and minimize the unwanted side effects.

User Journey vs User Flow

What is the difference between these two? what do we need to know before we start either?

firstly let's answer these two questions
Who is our user? in our case it'll be Tom, a guy waiting in reception, for a doctor, mechanic or any other professional service.
What is our user's goal? to fight off boredom, waiting is boring; Tom just wants to kill some time while he waits to be called by the receptionist.

Now that we know who our user is and what he wants we can work on what steps will Tom take to accomplish his goal?

Let's start with User Journey; lets hypothetically say we are designing a blackjack application; the user journey may be at a high level something along the lines of

1. Tom is sitting waiting at the doctors office, he is board and wants to occupy himself
2. Tom pulls his phone out of his pocket
3. Tom opens up BlackJack stars
4. Tom joins a blackjack game
5. Tom plays 5 hands
6. Tom closes the app because he is called up by the secretary.

notice that in a user journey there is no real concern as to how Tom accomplishes any of his actions just that he does them. A user journey in a way could be represented as a story board, which would be a great way to investigate or hypothesis various situations as well as understand the real world context in which Tom would use the BlackJack stars app.

Whereas a User flow is concerned with Tom's micro interactions within the application:

1. Tom Launches the BlackJack stars app
2. Tom Selects the new game option from the splash menu
3. Tom Is sat at a virtual table with 4 other players mid deck
4. Tom Joins the game
5. Tom Is dealt in on the next hand, 
6. Tom Gets an ace and a jack
7. Tom Stands
8. Tom waits for the other players to finish
9. Tom wins 

the user flow is far more detailed it is less concerned with the context that Tom is in and more so with the interactions Tom has with the app, we still do not discuss buttons and labels but more so actions to try and understand the user flow so that we could use this knowledge to support our design.

in short a User Journey is high level and could be represented as a Story board, whereas a User flow is concerned with the interactions the user has within the application to accomplish a particular goal, and could be represented as a flowchart initially and later as low-fidelity screens.

Customer journeys

Customer journey maps also referred to a user journey maps are a visual representation of the steps and experiences which a customer traverses while interacting with a product or service. It provides a holistic representation of the customer's experience: 

• Lifecycle: the stages which the user passes through when traversing the journey 
• Situations & Activities: are moments without a specific task, which influence a decision:
• Needs: What the user/customer is aiming to accomplish
• Touch points: Interaction points (web, phone, etc) between the user and the product or service.
• Interactions: specific actions or tasks that the user performs at each stage
• Emotions: how they feel throughout the interactions
• Pains: Challenges or issues the user may face during their journey.
• Gains: Benefits or moments of "delight" 

Lifecycle

These are the high level stage which the user moves through, these are generally unique to each context, they can however be broken down into the following three most basic steps:

• Before: Awareness, Research
• During: Comparison, purchase, use
• After: Retention

These are just some examples, these lifecycle stages will vary from client to client and project to project, but in essence will generally fall into the Before, During and after groupings.

Situations & Activities

Situations & activities are outside of the product or service you are mapping, they are contextual specific actions or incidents that the user interacts with which influence the user, this could be something like a word of mouth conversation, or reading a review.

The important thing to note, is that these are outside your direct control, these "situations & activities" are influenced by reputation more than anything else.

Needs

The needs simply refer to what the user/customer wants, what they want to learn, what they want to accomplish, what they want to buy, this is the aim of the particular stage.

Emotions

The emotions deal with how the person "feels" at each stage of their journey, this could be sad, happy, frustrated, disappointed, ecstatic, this range can be as wide as the range of human emotions; however you may just want to narrow it down to 3 to 5 emotions.

Touch points

Touch points are the physical entry points to your system, how is the user/customer interacting with your service.

Interaction

Are the physical actions which your customer does,

Pains

The pain points are the aspects of the customer journey which failed to meet the customers expectation, these should be vied not as failures, but as opportunities for the team to improve the customer journey and hence, increase sales, decrease churn, leading to higher profits

Gains

These are points within the customer journey which proved to be "Delightful" things which the client enjoyed, these should preserved and used as insight into the user's expectations

The take away

The user journey represents the user's experience across various stages of their engagement with the product or service. The purpose of creating a user journey map is to gain a better understanding of the user's experience in order to identify opportunities for improvement. 

The above is entirely contrived, the stages (columns), and the aspects (rows) may vary a little or drastically, the important thing before constructing a Customer journey map is to ensure that you are capturing the right aspects at the right stages. Also bare in mind that different customers will most likely leverage different journeys, it is very likely that you may have a different journey per persona.

Personas

Personas are a representation of the various target end user segments. When designing solutions, it's very natural to to fall into the trap of designing for oneself. The persona is meant to act as a reminder of who you're designing the solution for.

Personas are fictional characters which represent key types of the target user groups, these segments or user groups are discovered through research. This research would ideally be supported by data analytics, or it could be through direct observation if data is unavailable or potentially not reliable, and of course you can always fall back on indirect observation.

Regardless of research methodology, for a persona to be valuable, it must be data driven. If a persona is not supported by data, then it is at best a waste of time, and at worst a dangerous artefact which could lead your design team astray.

Though the actual persona is a fictitious representation of a user group, nothing about the persona is fictitious. Each persona is an amalgamation of factual data which represents that particular user segment. I bold factual data, because there is a trend for personas to be filled with fictitious bullshit; unless a segments golfing hobby has some relevance to the design challenge at hand and can be backed by data, it does not belong in a persona. (this is not to say that insights cannot be gathered from such an observation, however the observation is not an insight)

All data within a persona must be informative, this data should help designers, now and in the future solve their design challenges: creating a persona such as "Dave is a base jumper" or "Paul enjoys knitting" are of little value to the designer, instead the researcher should phrase these as insights into the personas such as "Dave is a risk taker" or "Paul is a homebody"; again these statements are an amalgamation of hopefully hundreds of real users:

• Sally enjoys street racing
• Frank is a base jumper
• Mike loves racing motorcycles
• Kelly spends her evening training MMA

These could be amalgamated to Dave the Persona as "Dave is an adrenaline junkie, who loves taking risks and needs exciting stimulation ."

One way to the persona

To create value added, data driven personas, the following is a completely valid and my preferred way of persona creation.

1. Identify Figure out who your target adience is, who could potentially gain from your solution, product, service, etc. understand the segments, leverage data, insights, observations to identify these user segments.
2. Define what you want to learn about your segments:
• Demographics: what data represents this person
• Goals: what does this person want to accomplish
• Motivations: what drives this person to accomplish their goal
• Behaviours: how do they act before, during, and after they pursue their goals
• Context: what is the environment around them, how does it help or hinder?
3. Interview: conduct the actual interviews to collect the data needed about your users. each persona should ideally have 100s of interviewees, if your user base is 10 people, then just interview them all and don't bother with personas. 
4. Correlate your findings. Logically group the data collected, then generate your personas from those grouping. remember you may not have a one to one segment to persona mapping, some segments may have several personas.
5. Iterate: just as your user's change, your personas will evolve, constantly interviewing and revising your personas are a good way to ensure that they will provide value long term.

Characteristics of personas

• Based on data: they are not a guess, user types identified through UX research.
• Embody the user: their goals, traits, behaviours, and the context that can influence how and if the solution will be used.  
• Represent distinct classes of users: Projects will have various types of users, from passive to power users to administrators, to interested parties, and so on. Personas should represent these variants or segments.

Elements of a Persona

• Demographics: general information about the user
• Age: how old they are, this can be generational.
• Occupation: what is their role 
• Location: where in the world are they (culture, language, village vs town vs city )
• Life Stage: marital status, family status, career status
• Technological literacy: High/Med/Low
  
  
• Goals & Motivators: things that drive the user to use the system or may act as barriers
• want to socialize for a social application
• want to meet romantic interest for dating app
• want to track fitness for fitness enthusiast 
• doesn't want to waste time for game
• doesn't like sharing personal information for social application
• doesn't care about fitness for couch potato
  
  
• Behaviours: routines or Behaviours that create opportunities or barriers for use of application
• working 9 to 5; can't watch live sporting events
• lives in country side with low bandwidth: preventing streaming of video
• uses public transit for travel: enables use of transit app
  
  
• Context: Living and working environment and other aspects of physical and social context that may be relevant to technology use.
• Lives in big city with lots of takeout options: opportunity for helping users find their preference
• Has physical handicap: help users find accessible places to go and things to do
• Dietary constraints: help users find a place to eat.

thus you'll have different values for each section of a persona; the question to ask yourself when deciding what goes into the persona is "will this information help me?" does the information tell me something valuable about the persona, a way to identify the user, understand what will drive them to use the solution or pull them away from it. Understanding the obstacles is just as important as the motivators. There is no hard and fast rule on what elements make up a persona, it's your persona, whatever you deem as informative and beneficial should be part of the persona, the above are simply common base elements, if they makes sense for you keep them, if not take them out and if you need other elements, add them.

Benefits of a Persona

• Summarize research data into the target audience
• Mental shortcut for design considerations 
• will persona A be capable of doing this
• would persona B want to do this
• facilitate discussion on who the target users are
• ensure that designers and stakeholder are on the same page as to who the system is for.
• Easy to understand for non designers
• Prevent designers from designing for themselves.
• Prevent the "Elastic user" fallacy
• Create concrete bounds to prevent design creep  

Personas should

• Personas are used as a constant reminder:
• "this is who I'm designing for, will this work for them?"
• Personas should feel like real people
• Personas should focus on commonalities and not idiosyncratic characteristics,
• Personas should embody you're average types, don't worry about the outliers focus on the "average Joes" of your solution.

UX Research

The 3 basic methods of research are:

• Ask:
• Interviews: Conversations with stakeholders to understand aspects of their experiences 
• Surveys: Questions distributed to large groups of users to elicit attitudes, behaviors and characteristics   
• Focus Groups:
• Diary Studies:
• Experience Sampling:
• Observe:
• Ethnographic Observations: Watching people engage in activities to understand how they go about them
• User Testing: Watching people perform specific tasks to see if a system supports them
• Usage analytics: Analyzing large scale traces of system usage to understand patterns of use
• Video analysis:
• Social media mining:
• Inspect:
• Guideline based:Compare a system design against best practices to see how it holds up
• Walkthroughs: step through an interactive sequence using the users-eye-view to find potential breakdowns
• Comparative analysis: compare to existing or similar designs to identify strengths and weaknesses 

we often combine the different research methods to get a more robust set of data the question is when to use which type of method

• Ask: 
• when observation isn't an option, tasks are infrequent, private or too long to watch
• Values or motivations behind actions are important
• we use surveys when we need input from large numbers of users and we need definite answers 
• Observe
• when asking will lead to misinformation (memory, tacit knowledge)
• process & communication, users won't cover every detail when explaining their process.
• analytics when we need large quantities of data
• Inspect
• We have something to inspect, ie doing an as is assessment
• interacting with users is too expensive or difficult

Often times you'll use a combination of the different UX research methods.