These are some notes I put together for my team last year. They are based off of a few books I was reading at the time and when I can remember those, I’ll post them for reference. We never made use of these due to reasons other than want and need, but others made find them useful.

These are just notes. Feel free to fill in any gaps as needed or ask questions if you have any.

Creating a User Experience Strategy

Goal:
An experience strategy is a guide for verticals / projects to be referred back to and updated as the vertical and/or project matures. It is a way to maintain focus on the end goal, providing the user with an experience, and is to be shared with and used by everyone on the team. For our purposes, they would likely live in confluences and our bullets would be numbered so we can refer to a specific portion of it when needed. Personas and journey maps as well as other UX artifacts (research before release / usability tests after the fact) would be parts of the experience strategy.

Reasoning:
A strong plan will guide decisions about how the business executes, maintains, and manages experiences to create value for the customers and the business. These should be invested in and managed as well as cultivated and nurtured. A strong experience strategy not only makes it clear what to do, but also what NOT to do.

Start with:
An expression of the experience you hope customers will have. A statement.

Build up:
Bulleted list of experience requirements (not ui / developer requirements, not tasks / goals – it’s all about the EXPERIENCE)
focus on:
user behavior, motivations, context, meaning
usefulness / desirableness
how does it help the user accomplish what they want to get done
how is it (or can be) different / innovative

Big questions:
What do people want to accomplish?
How does this activity fit into their lives?
How can we help deliver on those desires?

Craft:
Hypothesis based on
personas – which are project based, but stem from our basic set
research – which is project based, but builds on all other research – must be actionable and durable
previous testing – which can come from anywhere, but should help craft project based
experience
best practices
analytics

Test:
Against user stories
Against designs
Against prototypes
With Users / Analytics

Iterate and Evolve:
Take all previous information, build on it, then start over if needed.

Strategy should bring clarity and should act as a sign post to show the company where ewe are going and what we need to do to get there.

Consider making it visual when possible.

Leveling Information – so we all start out with the same definitions.

Behaviors:
activities in which people engage

Motivations:
drive and shape behaviors
– understanding the basic drives that lead people to do certain things in certain contexts

Contexts:
help provide meaning to the motivations
learn by doing

Meaning:
worthwhile? important? necessary? required? needed? changes based on context and motivation

Consider:
A user’s experience emerges from:
Motivations
Expectations
Perceptions
Abilities
Flow
Culture

Perception is preceded by sensation and followed by cognition if bottom up, if bottom down – then knowledge influences everything (Gestalt).

Ability – consider memory, it includes sensory (get attention), working and encoding (requires heavy attention), long-term and retention (storage). Recall falls off dramatically after 1 day – this is an issue for users who do not / would not / don’t need to / shouldn’t have to – interact with us or a particular tool / experience on a daily basis. Always something to consider. Reduce memory load / ability requirement whenever possible.

Flow – form follows function. Affordance means there is no need to learn. Avoid multi-usability (modes).

Form hypothesis – test hypothesis whenever possible early and then test again with analytics later. (See my pyramid)

Users / Personas in terms of behaviors, motivations, context and meaning:
Who? – are they
What? – do they need, want, use, are they trying to accomplish and is there a better way to do it
Why? – do they need it, want it, use it, like it, dislike it
Where? – do they need it, want it, use it, expect to find it / access it
How? – do they need it, want it, use it, does it fit into their workflow

Complexity:
Theories should be as simple as possible, but no simpler.
Acknowledge and embrace the complexity
Look for differentiators here – avoid parity, novelty, and trying to “be the best” at everything – just boil it down to the essentials, and then go a step further into the murky and complex chaos of the user until you come out on the other side with something that resonates with the users behaviors and motivations while considering the context and meaning