My most popular post is about customer experience maps – it gets about 50 hits a day (I’m blogging plankton in the scheme of things so 50 is a lot for me). I’m chuffed about that because maps and frameworks are just about my most favourite thing in design. They’re even a form of info design (which is my other favourite thing). And ever since I put up that post I’ve wanted to do this post about frameworks.
I love dealing with lots of information because I love coming up with frameworks to manage the volume. That magical moment when all the information fits like finally cracking the sky in a jigsaw. And then that wonderful feeling (provided you trust it) when you know you don’t have to return to the data because it’s been organised. For me this is the magic and wonder of synthesis.
NB: Don’t be frustrated if I use framework and model interchangeably in what follows – I’ve never determined a clear enough distinction and if someone calls their framework a model (like Doblin) I’ll call it a model.
What’s a framework
Frameworks are a means of structuring thinking and research findings into a format that is meaningful to the desired change; they offer deeper understanding and turn abstract information into meaningful categories and relationships. It’s best captured in a quote from Conifer Research where they called “[frameworks and models] scaffolding when we build Experience Maps”.
A well-known experience framework is the Doblin Group Compelling Experience Model. It helps envision the different facets of generic experience a customer goes through when engaging with a service. I’ve teamed it here with John Maeda’s definitions:
A framework for frameworks
Experience Maps and Service Blueprints are forms of frameworks so when I was working on developing the techniques I needed a way of describing how you organised existing and created information before you could map it. I developed this framework (the purpose of which is to contextualise):
When frameworks become a map
Frameworks tend to be set in concrete in terms of content (i.e. once they’re developed they shouldn’t change. NB: this isn’t the case for maps). There may/should be many different frameworks to capture facets of information. At the user experience level:
- Frameworks model abstract experience to categorise and relate the information. The frameworks created during service design activity describe all the elements involved – separate and connected. For example, when I was involved in a piece of work understanding how small business used information we developed frameworks on how customers used information versus how the business created it (business produced ‘guides’ ‘letters’ ‘forms’, customers used them as ‘reference’ ‘memory joggers’ ‘proof of status’) user typologies, sources of information, interaction frameworks, delivery mechanisms. This synthesised knowledge gave us the parameters for developing experience maps
- When we’re mapping, ‘user experience’ is what happens. The map itself takes a specific case and works it through, helping explain how all the elements – separate and connected – contribute to the customer experience.
Frameworks become a map when you want to plot a journey and the map helps you ‘see’ service as a whole; the map humanises meaning from the abstracted frameworks.
Framework Hall of Fame
I’d like to thank these frameworks for helping me sleep through the night when panic set in about how the hell I was going to articulate experience, helping me work more quickly, and most of all, for helping making meaning of mass.
- Experience Framework (DSR Group (via Leslie Tergas)
A way of breaking down user experience. I have never been able to come up with a better definition of experience in relation to service design than this framework.
- What users THINK (Cognitive Domain)
- motivations, folklore, perceptions, beliefs, expectations, mental processes
- What users DO (Behavioural Domain)
- activities, processes, routines, patterns, interactions, relationships
- What users USE (Material Domain)
- products, services, brands, environments, messages, systems
- Typologies
Typologies describe different types of users at a high-level – they are a springboard for understanding and designing for the variables of real user experience. Typologies and personas are closely aligned; the typology provides user experience information at an overview level; Persona’s take that information and bring the typologies to life. Typology example
- Who the user is in relation to the business need and intent
- What they do
- Their expectations
- Points of Delight (Opportunities, things the service/experience should maintain)
- Points of Pain (Barriers, Challenges)
The following frameworks I relied on heavily in capability development
- Activity descriptions
- Overview (high level description of what happening during the activity)
- How it happens in practice (instructional level description)
- Who are the people involved
- What outputs are generated
- Where are you at the end of the activity
- Technique descriptions
- What it is
- When it’s useful
- What you do
- Who’s involved
- What you need
- Operating Model
- What we do (our purpose)
- How we’re organised (our functional structure)
- Who’s involved (staff, process partners, business areas)
- How we do what we do (management practice, information flow, capability infrastructure)
- What’s important (values and behaviours)
- Innovation (as change creation framework)
- Known knowns – optimizing the system/service
- Known unknowns – improving to evolving the system/service
- Unknown unknowns – inventing to transforming the system/service
And just to show designers aren’t anti Business Analysis, this helped me engage with my BA colleague on many an occasion.
- Business Analysis Problem Definition
- The Problem of….
- Affects….
- The impact of which is…
- A successful solution would be….