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.