Compelling Experience Framework

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.

Service Design Frameworks

• 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

• typologies는 고차원에서 유저를 분류한 것. 실제 유저 경험의 변수를 이해하거나 디자인할 때 . 전반적인 레벨에서 유저 경험 정보를 제공하는 반면
• Persona는 실제 라이프에 typologies를 적용한 것. 
• 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
• 2*2 메트릭스 그려 놓고...

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….성공적인 해결적인 해결안은