The four contexts of service design
•
9 gefällt mir•1,995 views
Presentation given at Service Design 2011 about four important contexts that need to be established to design a service.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie The four contexts of service design
Ähnlich wie The four contexts of service design (20)
Mehr von Darren Menachemson
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
The four contexts of service design
- 1. THE FOUR CONTEXTS OF SERVICE DESIGN Darren Menachemson | @thoughtpod What you need to do before you design the detail of a service, and how you can go about doing it.
- 2. We need services to work for people. Desired outcome: healthy mum and baby
- 3. THE FOUR CONTEXTS OF SERVICE DESIGN The business context The strategic context The user context The capability context Who are we developing the service for? Service as an experience What are we changing? Service as an architecture Why are we doing what we’re doing? Service as a strategy What skills do we need to do it? Service as a design challenge
- 4. STAGES IN THE SERVICE DESIGN The service concept The strategy The detail
- 5. THE EARLY STAGES: A SERVICE BLUEPRINT Strategic intent User context UI detail of risk eventuating Integrated program view Interaction flow Changed outcome Architectural shifts
- 6. A SERVICE AS A STRATEGY Strategic shifts Broader trends
- 7. CREATING THE STRATEGIC CONTEXT Online transaction: Create new web-based services Authentication: Put PIN in the post Offline transaction: Develop paper forms Enhanced support: Set up more call centre helplines Make low-cost online channels more desirable to encourage customer migration and uptake Mobile apps/browsing Reduce/reuse/recycle Zero wait
- 9. A SERVICE AS AN EXPERIENCE Users User Journey Interactions Service Service
- 10. LEARNING THE USER CONTEXT
- 11. LEARNING THE USER CONTEXT Contextual enquiry Interviews Design focus groups Research reviews
- 12. A SERVICE AS AN ARCHITECTURE BUSINESS CONTEXT Interactions Channels Roles Processes Information systems/tools Information Legislation Sociocultural norms and beliefs
- 13. A SERVICE AS A DESIGN CHALLENGE Service Skills Knowledge Experience Role Authority Space
- 14. CREATING THE CAPABILITY CONTEXT DESIGN FACILITATOR USER RESEARCHER UX ARCHITECT INFO DESIGNER ACTIVITIES SKILLS DELIVERY
- 15. CREATING THE CAPABILITY CONTEXT Project Manager Business Lead Subject Matter Expert Business Analyst Data Architect Developer Solution Architect Design Facilitator UX Architect User Researcher Information designer
- 16. AN INTEGRATED, HOLISTIC VIEW User User Journey Service interactions Strategic direction Design capability Channels Roles Processes Information systems Information Legislation Societal/cultural norms
- 19. SERVICE BLUEPRINT: ENRICHED STORY Finds out about a new service Calls to register Call centre rep conducts POI Discuss circumstances to determine eligibility. Registration. Week later, receives confirmation letter and welcome pack. Scaffolds the architecture
- 20. SERVICE BLUEPRINT: ENRICHED STORY Week later, John checks his email, and finds a message from the agency. He opens it and [etc etc] Email A visual and textual narrative
- 21. SERVICE BLUEPRINT: ENRICHED STORY Identifies the change Week later, John checks his email, and finds a message from the agency. He opens it and [etc etc] Email, rather than paper-based correspondence decreases the registration turnaround time and reduces mailout/printing costs. Email
- 22. SERVICE BLUEPRINT: ENRICHED STORY Week later, John checks his email, and finds a message from the agency. He opens it and finds it contains an appointment time, which updates his online calendar [etc] Email, rather than paper-based correspondence decreases the registration turnaround time and reduces mailout/printing costs. Email Auto email facility – generates emails based on case note. Calendar – updated based on authenticated link-click. Previous scenes in the story Shows the key enabling architectural assets
- 23. SERVICE BLUEPRINT: ENRICHED STORY
- 24. Service Blueprinting is a team sport. It is fuelled by the four contexts. Once it’s done, it becomes the single songsheet for design. It changes a lot. Yes, powerpoint. SERVICE BLUEPRINT: YOU SHOULD KNOW…
- 25. IT STARTS (AND FINISHES UP) WITH THE USER
- 26. Questions? THANKS :) Darren Menachemson | @thoughtpod
Hinweis der Redaktion
- The word service represents a very complex idea. A service is intangible, but it can be made up of a mixture of intangble and tanginble things. It gives a benefit to someone. It happens over a period of time, and may involve one interaction, or many interactions.
- A service forms part of an organisation’s strategic direction A service exists in a broader user context. A service’s user experience emerges from its architectural context A service is designed and redesigned by a service design capability Getting these four things right before diving in to the detail of the service design can be the difference between success and failure.
- tail
- The real world is so complex, we like to pretend that it isn’t. So instead of engaging with all of that complexity until we are fluent in it, we are often inclined to imagine a simpler, more structured and logical world, populated by people who, by and large are just like us. I can sit in a room, and imagine that I’m a pregnant mother. I can sit in a room and imagine that I’m a small business owner. I can sit in a room and imagine that I am an art appreciator looking to auction an oil painting. And once I’ve done that, I can design a service that will be absolutely suitable for any pregnant mother who is a 30-40 year old male service designer with a working professional knowledge of the Australian health system. The only person who truly understands what a small business owner goes through is someone who, A, owns something, where that something is, B, a business, that is C, small. But it is possible to understand a small business owner enough that you can put that insight to work designing a service for them. The best way to do this is to actually talk to them, or even better, to watch how they do what they do and learn through sharing their experience for a while. I remember once, many years ago, when the web was new and links were still comic sans buttons with five point bevels and drop shadows. I was doing an intranet redesign for an organisation that did many interesting things, one fo them being sending senior engineers aboard ships to check that they were safe. Knowing the right procedures to use was of critical importance to the safety both of the engineer and the ship itself, and the intranet was the primary source of procedural information. Whenever I’m working on a project like this, I like to think about why it’s important. On this project, I had visions of explosions, of ships sinking, of survivors clambering onto the remains of wooden cargo crates to avoid being eaten by massive great white sharks that were not only hungry, but pissed off. I decided that the team would need to do some contextual enquiries, right upfront, before we got into the details of a solution. For those of you who have never done contextual enquiries, here are a few key facts about them. Firstly, they are observational – you actually go out into the field, and watch the people you are wanting to learn about. I’ve encountered two philosophies about contextual enquiry. The first one says that you should be objective, and watch without participating. You should encourage the user to do, not tell, and to be as narrative as possible, describing what is happening, why, and what they think and feel about it all. You should be inquisitive, and ask about things and processes, especially where something unexpected seems to be playing an important role – like scribble on a post-it, or a quick telephone call to support a decision-making process. The second one takes mostly the same approach, but instead of purely observing, you almost apprentice yourself to the user, and get them to show you the ropes, so you can have a first-hand experience to supplement your inquiry. I’ve personally used both forms.
- A service forms part of an organisation’s strategic direction A service exists in a broader user context. A service’s user experience emerges from its architectural context A service is designed and redesigned by a service design capability Getting these four things right before diving in to the detail of the service design can be the difference between success and failure.