Service Design Playbook

What it is

A visual diagram showing the people, teams, or organizations that influence—or are influenced by—a service, and how they relate to each other.

Why use it

• Clarifies who matters and why.
• Identifies decision-makers, influencers, blockers, and supporters.
• Helps you prioritize whose needs to address in research and design.

When to use it

At the start of a project (Discover phase)—especially during scoping or early research and stakeholder alignment.

How to do it

• List stakeholders: include customers, staff, partners, regulators, etc.
• Place them around the service at the center—proximity indicates influence.
• Draw lines or arrows to show relationships or flows of influence.
• Label stakeholders (e.g., internal/external, primary/secondary, supportive/blocking).
• Review with your team or stakeholders to refine and validate.

Example output

A diagram centered on the service, surrounded by stakeholder icons or labels placed according to influence, with relational arrows connecting them.

References & Further Reading

• UXPressia: Stakeholder Mapping in UX Design
• Skylight: Service Design Framework – Stakeholder Mapping
• Luma Institute: Stakeholder Mapping
• Interaction Design: Map the Stakeholders
• Giordano ServDes 2018 (PDF)

What it is

A structured conversation with users (or potential users) to uncover their needs, goals, pain points, and real-world practices.

Why use it

• Builds empathy and understanding of the user's perspective.
• Reveals motivations, expectations, and challenges that are not visible in data.
• Provides rich stories and quotes that inform journey maps, personas, and design decisions.

When to use it

• Early in the Discover phase to explore user needs and experiences.
• Before creating personas, journey maps, or defining requirements.

How to do it

• Define goals: Be clear what you want to learn (behaviors, attitudes, experiences).
• Recruit participants: Select a diverse set of users or representatives of target groups.
• Prepare a guide: Write open-ended questions.
• Conduct interviews: Listen actively, probe deeper, avoid leading questions.
• Capture insights: Record (with consent), take notes, and extract quotes.
• Synthesize: Look for patterns, themes, and key pain points across participants.

Example Output

• Transcripts, notes, or video recordings.
• A set of key themes or insights.
• Stories and direct quotes to bring the user's voice into the project.

References & Further Reading

• NN/g – Practical guide on planning and conducting user interviews
• Interaction Design Foundation – Comprehensive overview with tips and best practices
• IDEO Design Kit – Interviewing for empathy

What it is

A moderated group discussion (usually 5–8 participants) that explores user perceptions, needs, or reactions to a topic, product, or service.

Why use it

• Surfaces shared attitudes and differing perspectives in one session.
• Efficient for gathering insights from multiple users at once.
• Useful for testing early concepts, messaging, or service ideas.

When to use it

• In the Discover phase to explore perceptions, needs, and expectations.
• In the Develop phase when validating early concepts with users.

How to do it

• Define your purpose: What do you want to learn (opinions, experiences, reactions)?
• Recruit participants: Aim for a diverse but relevant group (5–8 people per session).
• Prepare a discussion guide: Use open-ended questions, prompts, or scenarios.
• Moderate the session: Encourage everyone to speak, manage dominant voices, and probe deeper.
• Capture insights: Record (with consent), take notes, and look for group patterns.
• Analyze: Identify common themes, points of disagreement, and surprising insights.

Example Output

• A summary of key themes discussed in the session.
• Direct quotes that illustrate perceptions and attitudes.
• Comparison of differences between user segments.

References & Further Reading

• NN/g – Practical overview of when and how to use focus groups in UX
• Interaction Design Foundation – Focus Groups

What it is

A contextual inquiry is a field research method where you observe users in their natural environment while they perform real tasks, often combined with asking clarifying questions.

Why use it

• Reveals what users actually do versus what they say they do.
• Uncovers tacit knowledge, workarounds, and real-world constraints.
• Builds a deep understanding of context, workflows, and tools.

When to use it

• In the early Discover phase, when you want to see how services are really used.
• Especially useful for complex or professional environments (e.g., healthcare, aviation, banking, retail).

How to do it

• Define the focus: Decide which tasks or activities to observe.
• Gain access & consent: Arrange to shadow users in their real environment.
• Observe silently first: Watch how they perform tasks without interrupting.
• Ask clarifying questions: Use "think aloud" prompts ("What are you doing here?") after key steps.
• Take detailed notes: Capture actions, tools, workarounds, environment, quotes.
• Synthesize: Identify patterns, pain points, and opportunities grounded in real behavior.

Example Output

• Field notes and photos (with consent).
• A process flow or workflow diagram showing how tasks are really performed.
• Key insights (e.g., "Users often bypass system X by doing Y manually").

References & Further Reading

• NN/g – Contextual Inquiry and how it differs from interviews
• Interaction Design Foundation – Contextual Inquiry

What it is

Surveys and questionnaires are structured sets of questions used to collect data from a group of people. They are particularly useful for gathering quantitative insights (percentages, trends, frequencies) but can also include a few open‑ended qualitative questions.

Why use it

• Reach a large number of users quickly.
• Generate quantitative evidence to complement qualitative research.
• Identify broad trends, validate assumptions, and prioritize opportunities.

When to use it

• In the Discover phase, after initial interviews or observations, to validate findings at scale.
• Can also be used later (Define/Deliver) to measure satisfaction or track KPIs.

How to do it

• Clarify your goals – Decide what you want to learn (e.g., frequency of behaviors, satisfaction levels).
• Design the survey – Use clear, unbiased language. Favor short, simple questions. Mix multiple-choice, Likert scales, and a few open‑ended questions.
• Pilot test – Run with a small group to catch confusing questions.
• Distribute – Use online tools (Google Forms, Typeform, SurveyMonkey, Qualtrics) or embed in existing channels (emails, apps, websites).
• Collect responses – Aim for statistically meaningful sample sizes where possible.
• Analyze & report – Use descriptive statistics, charts, and cross‑tabulation. Summarize in plain language (e.g., "72% of users find onboarding confusing").

Example Output

• A dashboard or chart summarizing responses.
• A report showing top pain points, satisfaction scores, or feature preferences.
• Quantitative evidence that strengthens personas, journey maps, or business cases.

References & Further Reading

• Interaction Design Foundation – Surveys in UX Research

What it is

Data analytics in service design means using existing quantitative data (e.g., usage logs, web/app analytics, CRM data) to uncover patterns, trends, and anomalies in user behavior.

Why use it

• Shows what users actually do at scale (not just what they say).
• Identifies drop-offs, pain points, and high-value interactions.
• Provides a baseline for measuring improvements later.

When to use it

• In the Discover phase, alongside qualitative research, to see real-world behaviors.
• In the Deliver phase, to track service performance over time.

How to do it

• Define your questions – What do you want to know? (e.g., "Where do users drop off in the sign‑up process?").
• Gather available data – From sources like Google Analytics, Mixpanel, CRM systems, customer support logs, or transaction databases.
• Clean and structure – Remove irrelevant data, check for quality, and segment by user type.
• Analyze patterns – Look for peaks, drop-offs, correlations, and anomalies.
• Visualize – Use dashboards or charts to make insights clear.
• Translate into insights – Connect numbers back to user needs (e.g., "40% of new users abandon at step 2 due to unclear instructions").

Example Output

• Funnel charts showing where users drop off.
• Dashboards highlighting key metrics (conversion, usage frequency, churn).
• Data-backed insights (e.g., "Mobile users complete tasks 30% faster than desktop users").

References & Further Reading

No external references provided.

What it is

Diary studies are a longitudinal research method where participants self-record their activities, experiences, or feelings over a set period (days, weeks, or months). Entries can be text, photos, videos, or audio, often captured via apps or simple journals.

Why use it

• Reveals long-term behaviors and routines that one-off interviews or observations miss.
• Captures contextual, real-life experiences in the moment they happen.
• Uncovers fluctuating emotions, habits, and challenges in natural environments.

When to use it

• In the Discover phase, when you need to understand how experiences evolve over time.
• Especially useful for services involving daily routines, health, finance, or long customer journeys.

How to do it

• Define the scope – Decide what you want participants to record (e.g., "Log every time you use your banking app").
• Choose format & tool – Paper diary, mobile app, or online platform (e.g., dscout, Indeemo).
• Recruit participants – Select users who represent your target audience.
• Give clear instructions – Show examples of good entries and set expectations for frequency.
• Collect entries – Monitor participation, send reminders, and provide support.
• Analyze data – Look for recurring themes, behaviors, pain points, and emotional patterns.

Example Output

• A timeline of user activities and experiences.
• Rich quotes, photos, or videos that bring the user's daily context to life.
• Insights such as "Users feel most stressed at X moment of the day" or "Feature Y is only used late at night."

References & Web Links

• Nielsen Norman Group – Diary Studies in UX Research

What it is

Secondary (or desk) research involves reviewing and analyzing existing information — such as reports, market studies, analytics, competitor websites, and academic articles — rather than collecting new data.

Why use it

• Provides a fast, low-cost foundation of knowledge.
• Helps you understand industry trends, competitors, and existing insights before doing primary research.
• Prevents duplication of effort by building on what's already known.

When to use it

• At the very beginning of the Discover phase, before primary research.
• Useful when time or budget is limited.
• Can be revisited anytime for context or benchmarking.

How to do it

• Define scope – What do you need to know? (e.g., "current trends in online banking apps").
• Gather sources – Look at academic papers, government reports, white papers, competitor analysis, and internal company data.
• Evaluate credibility – Prioritize reliable, up-to-date sources.
• Synthesize findings – Summarize key insights, stats, and benchmarks in simple terms.
• Highlight gaps – Note what isn't covered and where primary research is needed.

Example Output

• A short report or slide deck summarizing key stats, market trends, and competitor comparisons.
• Evidence that helps shape research questions and hypotheses for primary research.

References & Web Links

• Nielsen Norman Group – Secondary Research in UX
• What is Desk Research? Definition & Useful Tools

What it is

Heuristic evaluation is an expert review method where usability specialists (or experienced designers) examine a product or service against a set of established heuristics (rules of thumb) to identify usability issues. The most common set is Nielsen's 10 Usability Heuristics.

Why use it

• Quick and cost-effective way to spot obvious usability problems.
• Does not require recruiting users.
• Helps prioritize areas to test further with real users.

When to use it

• In the Discover phase, before or alongside user research.
• Useful for benchmarking existing services before redesign.
• Can also be repeated in the Develop phase on prototypes.

How to do it

• Select heuristics – e.g., Nielsen's 10 Usability Heuristics (visibility, match with real world, consistency, error prevention, etc.).
• Gather experts – Ideally 3–5 evaluators with UX/service design knowledge.
• Review independently – Each expert explores the service, noting issues per heuristic.
• Consolidate findings – Combine notes into one list of issues.
• Rate severity – Classify problems as minor, moderate, or severe.
• Report – Share findings with evidence (screenshots, examples) and recommendations.

Example Output

• A report highlighting usability issues, categorized by heuristic and severity.
• Annotated screenshots showing problems and suggestions.
• A prioritized list of fixes to improve usability.

References & Web Links

• Nielsen Norman Group – How to Conduct a Heuristic Evaluation
• Nielsen Norman Group – 10 Usability Heuristics
• Interaction Design Foundation – Heuristic Evaluation

What it is

A Service Safari is a research method where designers or researchers use the service themselves (as if they were a customer) to directly experience it. It's sometimes called "mystery shopping" or "secret shopping."

Why use it

• Builds firsthand empathy with the user experience.
• Reveals hidden friction points and breakdowns in the service journey.
• Provides quick insights without recruiting participants.

When to use it

• In the Discover phase, before or alongside user interviews and observations.
• Useful when you need a quick baseline understanding of how a service works.

How to do it

• Plan scenarios – Define what you'll do (e.g., book a ticket, open an account, order food).
• Go through the service – Use it exactly as a real customer would, across all relevant channels (app, website, in-person, call center).
• Take notes & capture evidence – Document steps, touchpoints, emotions, and issues (screenshots, photos, quotes).
• Reflect & analyze – Summarize what worked well, what was frustrating, and where breakdowns occurred.
• Compare – If possible, benchmark against competitor services.

Example Output

• A short report describing the researcher's end-to-end experience.
• Annotated screenshots or photos highlighting friction points.
• A quick journey map showing where the service succeeds or fails.

References & Web Links

• Service Design Tools – Service Safari
• Nielsen Norman Group – Field Studies & Firsthand Experience

What it is

Card sorting is a user research method where participants group information items (written on cards or digital equivalents) into categories that make sense to them. It helps reveal how users mentally structure and label information.

Why use it

• Provides evidence for designing intuitive navigation and menus.
• Reduces the risk of confusing or irrelevant information structures.
• Helps validate or improve information architecture (IA).

When to use it

• In the Discover phase, to understand user mental models.
• In the Define phase, to validate draft IA and labeling decisions.

How to do it

• Select items – Choose the content, features, or topics you want participants to categorize (e.g., website pages, app features).
• Choose method:
  • Open sort – Users create their own categories.
  • Closed sort – Users group items into predefined categories.
  • Hybrid – Mix of both.
• Run the activity – Use physical cards (sticky notes, index cards) or online tools (OptimalSort, Miro, UXtweak).
• Observe & capture – Note where users agree, disagree, or struggle.
• Analyze patterns – Look for consistent groupings and naming preferences.
• Apply insights – Update IA, navigation menus, or content structure accordingly.

Example Output

• A dendrogram or similarity matrix showing how users grouped items.
• Recommended categories and labels aligned with user expectations.
• Evidence-backed structure for a website or app's information architecture.

References & Web Links

• Nielsen Norman Group – Card Sorting: A Definitive Guide
• Interaction Design Foundation – Card Sorting
• Optimal Workshop – OptimalSort Tool
• UXtweak – Card Sorting Tool

What it is

Personas are fictional but evidence-based profiles that represent key user types. Each persona summarizes the needs, behaviors, motivations, and pain points of a segment, making user research insights tangible and relatable.

Why use it

• Creates a shared understanding of who the service is for.
• Helps teams design with empathy, not assumptions.
• Keeps decision-making aligned to real user needs.

When to use it

• In the Define phase, after completing user research (interviews, surveys, diary studies).
• Before journey mapping, ideation, or prototyping, to ensure focus on the right users.

How to do it

• Analyze research data – Identify patterns and user segments from interviews, surveys, and observations.
• Define persona profiles – For each segment, create a 1-page summary with:
  • Name & photo (fictional, but relatable)
  • Demographics (age, role, location, etc.)
  • Goals and motivations
  • Needs and frustrations
  • Behaviors and habits
• Prioritize personas – Focus on the most critical 2–4 personas that represent the majority of user needs.
• Share and validate – Review with stakeholders, refine based on feedback.
• Use actively – Refer to personas when making design decisions, not just as documentation.

Example Output

• A 1-page persona sheet with a photo, short biography, key needs, pain points, and goals (e.g., "Fatima, 19, prospective student, goal: to find an affordable program; pain point: confusing admission requirements").

References & Web Links

• Nielsen Norman Group – Personas: Definition and Uses
• Interaction Design Foundation – Personas in UX Design
• This is Service Design Doing – Personas Method (2018 edition)

What it is

An empathy map is a visual framework used to capture and align what we know about a user's experience. It helps teams understand users by breaking down what they think, feel, say, and do, alongside their pains and gains.

Why use it

• Builds a shared, empathetic view of the user.
• Surfaces insights from research in a structured, human-centered way.
• Highlights gaps in knowledge that need further research.
• Prepares the ground for personas and journey maps.

When to use it

• In the Define phase, after research (interviews, diary studies, observations).
• In workshops with stakeholders to align understanding of the user.

How to do it

• Select a user segment – Focus on one persona or research participant group.
• Create the map – Divide into sections: Think, Feel, Say, Do, Pains, Gains.
• Populate with insights – Use quotes, observations, and evidence from research (not assumptions). Think: What's on their mind? Feel: Emotions and concerns. Say: What they express out loud. Do: Their actions and behaviors. Pains: Frustrations, barriers. Gains: Goals, desired outcomes.
• Synthesize as a group – Discuss patterns and prioritize the most critical insights.
• Use actively – Apply empathy maps to guide ideation and decision-making.

Example Output

• A filled-in empathy map canvas for a persona — e.g., a prospective student who thinks "I want the best program," feels anxious about costs, says "The website is confusing," does endless comparison searches, with pain = unclear requirements, and gain = confidence in her decision.

References & Web Links

• Nielsen Norman Group – Empathy Mapping: The First Step in Design Thinking
• Interaction Design Foundation – Empathy Maps
• This is Service Design Doing – Empathy Map Method (2018 edition)

What it is

A customer journey map (CJM) is a visual representation of the steps a user goes through when interacting with a service, across different channels and touchpoints. It includes actions, emotions, pain points, and opportunities.

Why use it

• Provides a holistic view of the user experience.
• Identifies pain points, gaps, and opportunities across touchpoints.
• Aligns teams around a shared understanding of the user journey.
• Helps prioritize improvements and innovations.

When to use it

• In the Define phase, after gathering insights from research.
• Before ideation and prototyping, to focus solutions on real pain points.
• Can also be used in the Deliver phase to measure improvements.

How to do it

• Define the scope – Choose which journey to map (e.g., onboarding, purchase, renewal).
• Identify stages – Break the journey into steps or phases (e.g., awareness → consideration → use → support).
• Add touchpoints – List where interactions happen (website, app, call center, physical location).
• Capture user perspective – Actions, thoughts, and emotions at each stage.
• Identify pains & gains – Highlight frustrations, gaps, and opportunities.
• Visualize – Use a clear, simple layout (timeline, rows, emotion line).
• Validate – Review with users and stakeholders to check accuracy.

Example Output

• A horizontal map showing stages of a prospective student's journey:
• Awareness: browsing university websites → feeling curious.
• Consideration: comparing programs → frustration with unclear fees.
• Application: filling forms → stressed about missing documents.
• Enrollment: relief when accepted.
• Includes emotions (highs/lows), touchpoints (website, phone, in-person), and opportunities ("Simplify application form").

References & Web Links

• Nielsen Norman Group – Journey Mapping 101
• Interaction Design Foundation – Customer Journey Maps
• Service Design Tools – Journey Map
• Miro – Customer Journey Map Template

What it is

An emotional journey map is a visual tool that focuses specifically on the emotions users experience across a service journey. It highlights emotional peaks (positive moments) and valleys (frustrations, anxieties) to better understand the human side of service interactions.

Why use it

• Surfaces emotional drivers of user behavior that standard journey maps may miss.
• Helps identify critical moments where emotions strongly influence satisfaction or decisions.
• Brings empathy into design conversations, beyond just processes and tasks.

When to use it

• In the Define phase, after research (interviews, diary studies, observations).
• As a complement to customer journey maps, to add the emotional dimension.
• Can also be revisited in the Deliver phase, to measure if improvements change emotions.

How to do it

• Select the journey – Choose a user journey already mapped (e.g., onboarding, checkout, hospital visit).
• Collect emotional data – Use quotes, diary entries, or observations to capture how users felt at each step.
• Plot the emotions – On a graph or line chart, mark highs (positive emotions) and lows (negative emotions) along the timeline.
• Annotate with evidence – Add user quotes or examples to explain emotional states.
• Identify insights – Spot critical "moments of truth" where emotions peak or crash.
• Prioritize improvements – Focus on turning low points into better experiences.

Example Output

• A graph layered over a journey map where emotions are plotted from high to low. Example: Onboarding: excitement (high) → confusion during sign-up (low) → relief after completion (high).
• Insights: "The biggest emotional dip occurs during step 2 due to unclear instructions."

References & Web Links

• Service Design Tools – Experience and Emotion Mapping
• Emotional Journey Mapping: What it is + How to Create it?

What it is

A service blueprint is a detailed diagram that shows how a service is delivered by connecting the user experience (frontstage) with the behind-the-scenes activities (backstage) and support processes. It extends a journey map by adding organizational layers.

Why use it

• Makes invisible parts of the service visible (staff roles, systems, processes).
• Reveals dependencies and bottlenecks that affect the user experience.
• Creates a shared view across departments, aligning business and user needs.
• Guides both design (what to improve) and implementation (how to deliver).

When to use it

• In the Define phase, after mapping the customer journey.
• When you need to connect user-facing experiences with organizational processes.
• During Deliver phase as a reference for implementation and governance.

How to do it

• Start with a journey – Identify the user steps (from a customer journey map).
• Add frontstage – Actions visible to the customer (e.g., website, staff interactions).
• Add backstage – Internal activities staff do that are invisible to customers.
• Add support processes – Systems, policies, partners enabling the service.
• Add evidence & channels – Artifacts users interact with (receipts, emails, screens).
• Analyze – Identify pain points, gaps, redundancies, or opportunities.
• Iterate – Update as the service evolves or during pilots.

Example Output

A layered blueprint with rows for customer actions, frontstage (visible employee or digital actions), backstage (invisible support work), support processes (IT, policy, vendors) and evidence (touchpoints such as receipts, screens, forms). Example: In an airline check‑in blueprint → Customer prints boarding pass → Agent validates documents (frontstage) → Data synced to airline system (backstage) → Airport security process enabled (support).

References & Web Links

• Nielsen Norman Group – Service Blueprints: Definition
• Service Design Tools – Blueprint
• Interaction Design Foundation – Service Blueprints
• This is Service Design Doing – Service Blueprinting Method (2018 edition)

What it is

An ecosystem map is a visual overview of all actors, stakeholders, systems, and relationships that make up a service environment. It helps teams understand the complexity of the wider ecosystem a service operates within.

Why use it

• Reveals dependencies and interactions between organizations, partners, and users.
• Shows influences beyond the direct service (e.g., regulators, competitors, policies).
• Helps identify opportunities, risks, and potential points of leverage.
• Provides a strategic perspective, complementing detailed tools like journey maps.

When to use it

• In the Define phase, after stakeholder mapping and research synthesis.
• Useful when designing services in complex, multi-actor environments (healthcare, finance, government, mobility).
• Also helpful in early Deliver phase, to align governance and partnerships.

How to do it

• List all actors – Include customers, staff, partners, suppliers, regulators, technology platforms, and external influencers.
• Map relationships – Show flows of value, information, or influence between them.
• Highlight roles – Identify who delivers, who regulates, who supports, who benefits.
• Layer context – Add external forces (e.g., laws, market shifts, cultural trends).
• Discuss with stakeholders – Use the map to spark conversations about interdependencies and blind spots.

Example Output

A visual diagram with the service at the center and surrounding circles or nodes representing primary users, frontline staff, partner organizations, regulators or government bodies and technology platforms. Arrows show flows of money, information, or influence, such as a hospital ecosystem with patients, doctors, insurers, regulators and pharma suppliers.

References & Web Links

• Service Design Tools – Ecosystem Map
• Interaction Design Foundation – Ecosystem Mapping
• This is Service Design Doing – Mapping Systems Method (2018 edition)

What it is

A process flow diagram is a step-by-step visual representation of how a service or task is carried out, usually using boxes and arrows. It shows the sequence of activities, decisions, and roles involved in delivering a service.

Why use it

• Makes service processes explicit and easy to follow.
• Helps identify bottlenecks, redundancies, or inefficiencies.
• Provides a bridge between user-centered maps (journeys, blueprints) and operational detail (process improvement).
• Useful for aligning service and business operations.

When to use it

• In the Define phase, to clarify how processes currently work ("as-is").
• Before or during Develop phase, to design improved ("to-be") processes.
• In Deliver phase, as documentation for implementation.

How to do it

• Define scope → Select the process to map (e.g., refund request, appointment booking).
• List steps → Break the process into sequential activities.
• Add decision points → Show where choices or conditions change the flow.
• Include roles → Note who (person, system, team) performs each step.
• Visualize → Use flowchart symbols (rectangles = steps, diamonds = decisions, arrows = sequence).
• Validate → Review with staff and stakeholders to confirm accuracy.

Example Output

A flow diagram for an online food order process: User selects items → Checkout → Payment → Order confirmed → Restaurant prepares → Delivery dispatched → Order received. Decision point: Payment success/failure. Insights: "High failure rate at payment step suggests need for more payment options."

What it is

A touchpoint matrix is a structured table or grid that lists all the points of interaction between users and a service, across different stages of the journey and channels.

Why use it

• Creates a complete inventory of where and how users engage with a service.
• Helps identify gaps, overlaps, or inconsistencies across channels.
• Provides a foundation for prioritizing improvements or designing omnichannel experiences.
• Bridges customer-facing view (journey maps) with organizational delivery.

When to use it

• In the Define phase, after research and journey mapping, to capture touchpoints systematically.
• During Develop phase, to evaluate which touchpoints to improve, remove, or redesign.

How to do it

• Define journey stages → Use stages from your journey map (e.g., Awareness, Onboarding, Use, Support).
• List channels → Online (app, website), offline (store, call center), physical (documents, signage).
• Populate the matrix → Fill in what interactions occur at each stage/channel.
• Analyze quality → For each touchpoint, note effectiveness, consistency, and user sentiment.
• Prioritize → Highlight critical touchpoints ("moments of truth") for redesign.

Example Output

A grid showing: Columns = journey stages (Awareness, Purchase, Use, Support). Rows = channels (Website, Mobile App, Store, Call Center, Email). Cells = interactions (e.g., "See ad on Instagram," "Receive order confirmation email," "Call support"). Insights: "Support touchpoints are fragmented across email, chat, and phone — causing confusion."

What it is

A transition journey map shows the steps, challenges, and support needed as users or organizations move from an existing ("as-is") state to a desired ("to-be") state. It focuses on the change process itself, not just the end state.

Why use it

• Helps anticipate friction points during change (e.g., resistance, confusion, learning needs).
• Aligns teams on what support is needed for a smooth transition.
• Useful for services undergoing digital transformation, migrations, or organizational change.
• Complements journey maps by showing not just what is, but how we get there.

When to use it

• In the Define phase, after mapping current and future journeys.
• During Develop phase, to design interventions that ease adoption.
• In Deliver phase, to guide rollout and change management.

How to do it (practically)

1. Define current vs. future state → Use existing journey maps or blueprints as start and end points.
2. Identify transition stages → Break down the change process (e.g., Awareness → Training → Adoption → Mastery).
3. Map user/organization experience → What happens at each stage? What are users thinking, feeling, doing?
4. Highlight barriers → Resistance, lack of skills, unclear communication.
5. Plan enablers → Training, support, incentives, communication strategies.
6. Visualize timeline → Show progression from current to future state, with interventions placed where needed.

Example Output

A transition journey for moving to a new digital banking app:

• Awareness: Users learn the old app will be replaced (emotion: anxiety).
• Training: Tutorials and help guides provided.
• Adoption: First-time logins with support chat available.
• Mastery: Users feel confident and comfortable.

Insights: "Biggest barrier is fear of losing transaction history — need to reassure with clear migration info."

What it is

An experience map is a broad, high-level visualization of human behavior across an entire experience, often spanning multiple services, brands, or channels. Unlike a customer journey map, which focuses on one service, an experience map looks at the bigger picture of a person's activities, context, and needs.

Why use it

• Provides a holistic view of user experiences that cross service or product boundaries.
• Helps uncover gaps between services where user needs aren't being met.
• Aligns organizations to think beyond their silo and consider the ecosystem of experiences.
• Inspires new opportunities for innovation at touchpoints outside the immediate service.

When to use it

• In the Define phase, after research synthesis, when you want to zoom out.
• Useful in early-stage innovation projects, where you need to understand the broader context of people's lives.

How to do it

• Choose the domain – Define the broader life situation to map (e.g., "a person moving to a new city" or "a family managing healthcare").
• Identify stages – Break the overall experience into broad phases (before, during, after).
• Map user activities – What people do, think, and feel across those stages.
• Add touchpoints – Note where different services, brands, or tools come into play.
• Layer insights – Add pain points, emotions, and opportunities across stages.
• Synthesize – Use the map to identify where your service fits — and where unmet needs exist.

Example Output

A large map that shows a person's moving-to-a-new-city journey: stages include planning, searching, moving, settling in, and community integration. Touchpoints might include real estate apps, movers, utilities, banks, schools, and local services. Insights might include "Stress peaks during utilities setup — opportunity for bundled services."

References & Web Links

• Interaction Design Foundation – Experience Maps
• This is Service Design Doing – Experience Mapping Method (2018 edition)

What it is

A system map is a visual representation of the interconnected elements that make up a complex system: actors, policies, platforms, technologies, processes, and external influences. It helps teams see the big picture of how different components interact.

Why use it

• Reveals interdependencies and feedback loops that shape the service environment.
• Makes hidden structures (like regulations, policies, or legacy systems) explicit.
• Helps identify leverage points for innovation and anticipate unintended consequences.
• Aligns stakeholders on complex challenges that span beyond one service.

When to use it

• In the Define phase, when synthesizing research in complex environments (healthcare, government, finance, mobility).
• Early in strategy work, to explore systemic barriers or opportunities.
• Useful in the Deliver phase for planning governance or policy changes.

How to do it

• Define the scope – Decide what system you're mapping (e.g., "public transport ecosystem").
• List components – Include stakeholders, platforms, processes, policies, and external factors.
• Draw relationships – Show flows of money, data, influence, or authority.
• Add layers – Highlight external forces (laws, economy, culture, technology trends).
• Look for patterns – Identify bottlenecks, reinforcing loops, or dependencies.
• Use collaboratively – Discuss with stakeholders to refine and validate the map.

Example Output

A diagram for digital healthcare showing patients, doctors, insurers, hospitals, regulators, and technology providers, with flows of data (patient records), money (insurance payments), and authority (regulations). Insights may include "Interoperability gap between hospital and insurer platforms creates delays in claims."

References & Web Links

• Service Design Tools – System Map
• This is Service Design Doing – Mapping Systems Method (2018 edition)

What it is

Usability testing (or journey validation) is a method where real users attempt to complete tasks with a prototype or service, while researchers observe and gather feedback. It validates whether designs are usable, intuitive, and effective in supporting user goals.

Why use it

• Identifies usability issues early before costly implementation.
• Provides direct evidence of whether solutions work for users.
• Ensures that prototypes and journeys align with real user behavior and expectations.
• Supports continuous iteration in agile/service design projects.

When to use it

• In the Develop phase, when you have prototypes, mockups, or pilot services.
• Can also be used in Deliver phase as part of post-launch evaluation.

How to do it (practically)

1. Define objectives → What do you want to test? (e.g., "Can users complete sign-up in under 2 minutes?").
2. Select participants → Recruit representative users for the service.
3. Design realistic tasks → Write task scenarios that mimic real-life goals (e.g., "Book a ticket for tomorrow at 5pm").
4. Run sessions → Ask participants to think aloud while attempting the tasks. Observe where they struggle, hesitate, or succeed.
5. Capture data → Record sessions (with consent), note errors, completion rates, and user comments.
6. Analyze and prioritize → Identify the most critical issues and refine the design.
7. Iterate and re-test → Incorporate fixes, then validate again.

Example Output

• A usability test report highlighting issues by severity.
• Metrics: task completion rates, time on task, error counts, satisfaction scores.
• Journey validation showing which touchpoints caused friction or confusion.

What it is

"How Might We" (HMW) sessions are structured brainstorming activities where teams reframe problems into design opportunities by turning insights or pain points into open-ended "How might we…" questions.

Why use it

• Shifts thinking from problems to possibilities.
• Encourages creativity without jumping straight to solutions.
• Aligns teams around a shared set of design challenges.
• Helps break down complex issues into smaller, solvable parts.

When to use it

• In the Develop phase, right after research synthesis (personas, journey maps, blueprints).
• Before ideation sessions, to frame challenges in a productive way.

How to do it (practically)

1. Gather insights → Review research findings and pain points.
2. Extract problems → Identify challenges users face (e.g., "Users abandon sign-up halfway through").
3. Reframe as HMW questions → Problem: "Users abandon sign-up." HMW: "How might we make the sign-up feel faster and easier?"
4. Generate multiple variations → Encourage many HMW questions per problem, ranging from broad to specific.
5. Prioritize → Select the most promising HMW questions to guide ideation.

Example Output

A set of sticky notes or a digital board with HMW questions, e.g.:

• "How might we reduce the number of steps in sign-up?"
• "How might we reassure users about security without overwhelming them?"
• "How might we make the process fun?"

What it is

Brainstorming or ideation sessions are collaborative workshops where teams generate a large number of ideas in a short period. They encourage structured creativity, focusing on quantity first and refinement later.

Why use it

• Unlocks creativity and encourages diverse perspectives.
• Moves teams from problem-space into solution-space.
• Helps identify unexpected, innovative directions.
• Builds team ownership by involving stakeholders in generating ideas.

When to use it

• In the Develop phase, after defining challenges (often framed as HMW questions).
• Before prototyping, to explore a broad range of solutions.

How to do it (practically)

1. Frame the challenge → Use HMW questions or specific problem statements.
2. Set rules → Encourage quantity, defer judgment, build on others' ideas, and welcome wild ideas.
3. Diverge first → Generate as many ideas as possible individually (silent brainstorming) and then as a group.
4. Use creativity techniques → E.g., SCAMPER (Substitute, Combine, Adapt…), "Worst Idea," role-storming, or sketch-storming.
5. Converge next → Cluster ideas into themes and vote/prioritize (dot-voting, impact-effort matrix).
6. Document outputs → Capture all ideas for future reference.

Example Output

• A whiteboard or digital board (Miro, MURAL) covered with sticky notes or sketches.
• A shortlist of prioritized concepts for prototyping.
• Idea clusters with labels (e.g., "Quick wins," "Blue-sky ideas," "Tech-heavy solutions").

What it is

Co-design workshops are collaborative sessions where designers, users, and stakeholders come together to jointly create ideas, concepts, or prototypes. They move design out of the studio and into the hands of those who will use and deliver the service.

Why use it

• Ensures solutions are grounded in real user needs.
• Builds ownership and buy-in from stakeholders early.
• Surfaces diverse perspectives, combining expertise from users, staff, and business.
• Helps uncover practical constraints and opportunities that designers might miss.

When to use it

• In the Develop phase, after defining challenges and generating initial ideas.
• Useful for refining and shaping concepts before prototyping.
• Can also be used in Deliver phase to align on implementation details.

How to do it (practically)

1. Define purpose → Are you generating, prioritizing, or refining concepts?
2. Recruit participants → Mix of users, frontline staff, managers, and experts.
3. Prepare activities → Sketching, storyboarding, Lego prototyping, role-playing, journey redesign.
4. Facilitate actively → Ensure equal participation, manage time, keep focus.
5. Document everything → Capture sketches, notes, photos, and discussions.
6. Synthesize outputs → Cluster ideas, identify themes, extract design directions.

Example Output

• Sketches, storyboards, or low-fi prototypes created collaboratively.
• Idea clusters showing user and stakeholder priorities.
• A clear shortlist of concepts ready for further prototyping and testing.

What it is

Storyboarding is a method of visual storytelling that uses sequential illustrations (like a comic strip) to show how a user experiences a service, product, or scenario over time.

Why use it

• Brings abstract concepts to life in a tangible and human way.
• Makes it easy for teams and stakeholders to imagine the user experience.
• Helps spot gaps, edge cases, or unrealistic assumptions before prototyping.
• Encourages empathy by showing the user's journey through their eyes.

When to use it

• In the Develop phase, to visualize ideas and explore how they might play out.
• Before prototyping, as a low-cost way to test narratives and scenarios.
• Also useful in co-design workshops, to make abstract ideas concrete.

How to do it (practically)

1. Define the scenario → Choose a moment, flow, or journey to illustrate.
2. Break into steps → Identify key moments or interactions (5–10 panels is typical).
3. Sketch simply → Use stick figures, icons, or digital tools — focus on clarity.
4. Add context → Include what the user is doing, thinking, and feeling in each step.
5. Share and refine → Use storyboards in workshops or reviews to gather feedback.

Example Output

• Panel 1: A parent realizes they need childcare → feels stressed.
• Panel 2: Searches online → finds confusing options.
• Panel 3: Discovers a clear service app → feels hopeful.
• Panel 4: Signs up easily → feels relieved.
• Panel 5: Child is matched with caregiver → feels happy and confident.

What it is

A concept walkthrough is a guided review of early ideas, mockups, or scenarios with users and stakeholders. The goal is to test assumptions quickly before investing in detailed prototypes or implementation.

Why use it

• Provides early validation of whether ideas make sense.
• Surfaces confusion, excitement, or resistance before costly development.
• Helps align stakeholders and users on the feasibility and value of concepts.
• Encourages iterative refinement based on real feedback.

When to use it

• In the Develop phase, after ideation but before building high-fidelity prototypes.
• Useful for narrowing down concepts from brainstorming and co-design workshops.

How to do it (practically)

1. Select concepts → Pick 2–4 early ideas (sketches, storyboards, wireframes, or simple mockups).
2. Prepare scenarios → Frame each concept in a short narrative.
3. Walk through with participants → Show one concept at a time.
4. Gather feedback → Ask what makes sense, what's confusing, and what to improve.
5. Compare and refine → Note which ideas resonate most and why.
6. Document insights → Capture quotes, reactions, and suggestions for next iterations.

Example Output

• Feedback notes grouped by concept (e.g., Concept A = "too complex," Concept B = "clear but missing features").
• Decision matrix showing which concepts to refine, combine, or drop.
• Evidence to support moving 1–2 ideas forward into prototyping.

What it is

Experience prototyping is a method where teams simulate parts of the service experience so users and stakeholders can interact with them as if they were real. Unlike technical prototypes, it focuses on the holistic experience (environment, interactions, emotions).

Why use it

• Makes abstract ideas tangible and testable.
• Reveals how users feel in real situations, not just what they say.
• Encourages stakeholders to step into the shoes of users.
• Allows for quick iteration without full-scale development.

When to use it

• In the Develop phase, once you have promising ideas that need testing.
• Useful for services involving environments, physical touchpoints, or multi-channel interactions (e.g., retail, healthcare, travel).

How to do it (practically)

1. Define what to simulate → Focus on key moments (e.g., ordering at a kiosk, waiting for a delivery, being onboarded).
2. Choose a medium → Role-play, paper mockups, props, digital click-through prototypes, or staged environments.
3. Recruit participants → Users, staff, or stakeholders who will interact with the prototype.
4. Run the simulation → Let participants experience the service and capture their behaviors, comments, and emotions.
5. Debrief → Ask participants what felt natural, confusing, or frustrating.
6. Iterate → Adjust the prototype and test again.

Example Output

• Notes, photos, or video recordings of users engaging in the simulation.
• A refined service concept based on observed reactions.
• Insights like: "Users felt uncomfortable scanning QR codes in public spaces" → leads to design adjustment.

What it is

Service prototyping is the practice of building and testing parts of a service (or the whole service) in a controlled, low-risk environment before full rollout. Unlike experience prototyping, which focuses on simulating the feel, service prototyping tests operational elements like roles, processes, policies, and touchpoints.

Why use it

• Validates whether the service concept works in real-world conditions.
• Reveals operational challenges (e.g., staff capacity, process bottlenecks).
• Helps test different delivery models before investing in full implementation.
• Reduces risk by piloting in a safe-to-fail environment.

When to use it

• In the Develop phase, once service concepts are refined.
• During Deliver phase, to pilot before scaling.
• Especially useful in services involving multiple teams, complex operations, or new technologies.

How to do it (practically)

1. Define the scope → Decide which elements to prototype (e.g., onboarding flow, support model, delivery process).
2. Design the prototype → Create a "light" version of the service (temporary team roles, simplified processes, mock environments).
3. Run the pilot → Test with real users and staff in a limited or safe setting.
4. Observe and capture → Document staff experiences, user reactions, and operational issues.
5. Refine iteratively → Adjust processes, roles, or touchpoints based on findings.
6. Scale up → Use lessons learned to shape the final service rollout.

Example Output

• A pilot test of a new hospital check-in process using temporary staff and paper tickets before implementing full digital kiosks.
• Insights: "Staff needed clearer escalation procedures; patients appreciated shorter wait times."
• A refined service blueprint with operational tweaks for final implementation.

What it is

Wizard of Oz testing is a prototyping method where users interact with what they believe is a functional service or system, but in reality, key functions are operated manually by humans behind the scenes.

Why use it

• Allows testing of tech-heavy or AI-enabled concepts without building the full technology.
• Provides early feedback on feasibility, desirability, and usability.
• Saves time and cost by validating ideas before investing in development.
• Helps uncover user expectations of system behavior.

When to use it

• In the Develop phase, to test early service concepts that rely on new or unproven technology.
• Useful before committing to AI, automation, or complex system development.

How to do it (practically)

1. Define the concept → Identify which function will be simulated (e.g., chatbot replies, automated recommendations, voice assistant).
2. Set up the illusion → Build a frontstage interface (mock app, website, kiosk) that looks real.
3. Manually operate backend → Have a human secretly perform the tasks (e.g., responding as the chatbot, processing requests).
4. Run user sessions → Let participants interact naturally, believing the system is automated.
5. Observe & capture → Track user behaviors, expectations, and reactions.
6. Debrief → Gather feedback on usefulness, clarity, and trustworthiness.
7. Refine → Use insights to design the real system or adjust concept.

Example Output

• Testing a "smart wardrobe assistant" app where recommendations are written manually by a researcher posing as AI.
• Insights: "Users expected personalized suggestions much faster — trust drops if replies take more than 10 seconds."
• Clear evidence on whether to invest in building the AI.

What it is

A service roadmap is a strategic planning tool that lays out the timeline for how a service will evolve over weeks, months, or years. It shows planned initiatives, improvements, and releases across different parts of the service.

Why use it

• Aligns teams and stakeholders on priorities and sequence of changes.
• Provides a long-term vision while breaking it down into actionable steps.
• Helps manage expectations by showing what will be delivered when.
• Links service design outcomes (journeys, blueprints) with execution and delivery plans.

When to use it

• In the Deliver phase, after concepts and prototypes have been validated.
• Useful for implementation planning, governance, and stakeholder alignment.
• Can also be updated continuously as part of service management.

How to do it (practically)

1. Define goals → Identify what the service needs to achieve (e.g., improve onboarding, expand to new markets).
2. Break into phases → Short-term (now/next), mid-term, long-term.
3. Map initiatives → Place projects, features, or improvements on the timeline.
4. Align dependencies → Show which initiatives depend on others (tech, policy, training).
5. Add ownership → Note which teams/departments are responsible.
6. Communicate clearly → Keep it visual and simple (not a detailed Gantt chart).

Example Output

A roadmap for a banking app service:

• Q1–Q2 → New onboarding flow, chatbot pilot.
• Q3–Q4 → Personal finance dashboard, enhanced security.
• Year 2 → Regional expansion, advanced AI personalization.

The roadmap highlights dependencies (e.g., AI personalization requires data platform upgrades first).

What it is

Service specifications are formal documentation that describes how a service should be delivered, including standards, roles, processes, policies, and requirements. They translate service design outputs (blueprints, journeys, roadmaps) into clear instructions for implementation and operation.

Why use it

• Ensures consistency and quality across teams and channels.
• Provides a single source of truth for how the service is supposed to work.
• Helps new staff or partners understand expectations and responsibilities.
• Reduces ambiguity during implementation by detailing exactly what needs to happen.

When to use it

• In the Deliver phase, before or during rollout.
• Useful in large, complex services where multiple teams or suppliers are involved.
• Can also be updated continuously as the service evolves.

How to do it (practically)

1. Define scope → Decide which part of the service needs specifications (whole service vs. individual process).
2. Detail service components → Document frontstage and backstage activities, roles, touchpoints, and support systems.
3. Include standards → Quality levels, timing (SLAs), compliance rules, accessibility standards, escalation paths.
4. Add supporting materials → Scripts, templates, training guides, visual mockups.
5. Review with stakeholders → Ensure agreement across business, technical, and operational teams.
6. Maintain as a living document → Update regularly as the service evolves.

Example Output

• A service manual describing how customer support should handle inquiries, including scripts, escalation rules, and system requirements.
• A standards document specifying design patterns for digital touchpoints, expected response times, and accessibility compliance (e.g., WCAG 2.1).

What it is

A change management roadmap is a structured plan that shows how a new or redesigned service will be embedded into an organization. It focuses on the people side of change — communication, training, adoption, and cultural alignment.

Why use it

• Ensures the new service is accepted and adopted by staff and users.
• Reduces resistance by making the change process clear and supportive.
• Aligns leaders, managers, and frontline employees on roles and expectations.
• Helps track progress and maintain momentum during transformation.

When to use it

• In the Deliver phase, alongside service rollout.
• Useful in large organizations, government, or regulated sectors where change impacts multiple teams.

How to do it (practically)

1. Define change goals → What's the desired outcome (e.g., "100% staff adoption of new platform in 6 months")?
2. Identify impacted groups → Who will be most affected? (frontline staff, managers, customers).
3. Plan activities → Communication campaigns, training programs, pilot groups, leadership alignment.
4. Create timeline → Short-term wins, mid-term milestones, long-term cultural shifts.
5. Assign responsibilities → Who owns communication, training, support?
6. Track adoption → Measure awareness, engagement, and usage through surveys or analytics.
7. Iterate → Adapt based on feedback and adoption rates.

Example Output

A roadmap for rolling out a new CRM system:

• Month 1–2: Awareness campaign, leadership briefings.
• Month 3–4: Training for pilot teams, support channels open.
• Month 5–6: Wider rollout, feedback loops.
• Month 7+: Full adoption, cultural embedding, ongoing optimization.

What it is

A governance framework is a structured model that defines how decisions are made, who is accountable, and how different teams or stakeholders coordinate in delivering and managing a service.

Why use it

• Provides clarity on roles, responsibilities, and authority.
• Reduces confusion and conflicts by defining decision-making flows.
• Ensures compliance with standards, regulations, and service quality expectations.
• Helps services remain sustainable and adaptable over time.

When to use it

• In the Deliver phase, before or during rollout of a new service.
• Useful for services that involve multiple teams, departments, or partners.
• Critical in regulated sectors where accountability and oversight are key.

How to do it (practically)

1. Define governance scope → What decisions need oversight? (strategy, funding, design standards, day-to-day operations).
2. Identify roles → Assign ownership (e.g., service owner, product manager, governance board, operational teams).
3. Map decision flows → Show how decisions move from frontline issues up to leadership.
4. Set accountability → Use frameworks like RACI (Responsible, Accountable, Consulted, Informed).
5. Document escalation paths → Define how issues and risks are raised and resolved.
6. Review regularly → Update governance as the service matures.

Example Output

A governance framework for a digital service:

• Service Owner → accountable for overall performance.
• Product Team → responsible for delivery and iteration.
• Governance Board → approves strategic changes and budgets.
• Escalation Flow → frontline staff → product manager → service owner → board.

What it is

A KPI (Key Performance Indicator) dashboard is a visual tool that tracks the most important metrics of a service in real-time. It consolidates data from different sources into one view for monitoring performance, quality, and impact.

Why use it

• Provides visibility and transparency into how the service is performing.
• Enables data-driven decision-making.
• Helps detect problems early (e.g., rising call volumes, system slowdowns).
• Keeps teams aligned on goals and progress.

When to use it

• In the Deliver phase, after service rollout.
• As an ongoing operational management tool.
• Can also be used during pilots to measure early performance.

How to do it (practically)

1. Define KPIs → Select the most relevant metrics (e.g., NPS, task completion rate, wait times, system uptime).
2. Choose data sources → CRM, analytics platforms, customer support logs, operational systems.
3. Select dashboard tool → Power BI, Tableau, Google Data Studio, Grafana, or custom-built solutions.
4. Design for clarity → Use simple visuals (charts, gauges, trend lines). Group metrics by theme (user satisfaction, efficiency, financials).
5. Automate updates → Connect to live data streams where possible.
6. Review and act → Regularly review dashboards and decide actions when thresholds aren't met.

Example Output

A service dashboard showing:

• User satisfaction: NPS = 52, CSAT = 84%.
• Operational metrics: Avg. wait time = 3 mins, uptime = 99.7%.
• Adoption metrics: 12k active users this month (+8% from last).

What it is

These are quantitative survey metrics used to measure user satisfaction and service quality:

• NPS (Net Promoter Score): Measures loyalty by asking, "How likely are you to recommend us?" (0–10 scale).
• CSAT (Customer Satisfaction): Measures short-term satisfaction with a specific interaction (e.g., "How satisfied were you with your support call?").
• CES (Customer Effort Score): Measures ease of use (e.g., "How easy was it to complete your task?").

Why use it

• Provides simple, trackable indicators of user experience.
• Allows benchmarking against industry standards.
• Highlights areas of improvement across journeys and touchpoints.
• Gives leadership clear, digestible metrics to monitor service health.

When to use it

• In the Deliver phase, once the service is live or piloting.
• As an ongoing measure to track performance and improvements.

How to do it (practically)

1. Select the right metric → NPS for overall loyalty, CSAT for specific touchpoints, CES for ease of task completion.
2. Embed into service flows → Place short surveys at the end of interactions (e.g., checkout, support chat, app feature).
3. Collect data continuously → Use digital tools (Survicate, Delighted, Qualtrics, Typeform).
4. Analyze results → Segment by customer type, journey stage, or channel.
5. Take action → Use feedback to address recurring pain points.
6. Track trends → Monitor over time to see if improvements increase scores.

Example Output

• NPS: 42 (strong loyalty, but detractors highlight support delays).
• CSAT: 78% satisfaction after onboarding.
• CES: 4.2/5 → "App makes payment process very easy."

What it is

SWOT analysis is a strategic evaluation tool that examines the internal and external factors influencing a service or organization:

• Strengths → Internal advantages.
• Weaknesses → Internal limitations.
• Opportunities → External trends to leverage.
• Threats → External risks to mitigate.

Why use it

• Provides a structured view of the service context before scaling or improving.
• Aligns teams on both internal capabilities and external market conditions.
• Supports decision-making by balancing optimism (opportunities) with realism (weaknesses, threats).

When to use it

• In the Deliver phase, during strategic planning, service rollout, or review.
• Also useful in earlier phases (Discover/Define) for competitor or market analysis.

How to do it (practically)

1. Assemble a cross-functional team → Include design, business, tech, and operations.
2. Draw a 2x2 grid → Label quadrants Strengths, Weaknesses, Opportunities, Threats.
3. Brainstorm inputs → Strengths: brand reputation, skilled staff, strong tech. Weaknesses: limited resources, long wait times. Opportunities: growing market, new technology. Threats: competitors, regulations, economic downturn.
4. Prioritize → Identify which factors are most critical.
5. Create actions → Turn weaknesses into improvements, threats into mitigations, strengths into differentiators, and opportunities into initiatives.

Example Output

For a digital healthcare service:

• Strengths: strong brand, secure platform.
• Weaknesses: limited multilingual support.
• Opportunities: rising telehealth adoption, AI-powered diagnostics.
• Threats: stricter regulations, new competitors entering market.

What it is

The Business Model Canvas (BMC) is a one-page strategic framework that describes how a service or business creates, delivers, and captures value. It breaks the model into 9 building blocks.

Why use it

• Provides a shared language for business and design teams.
• Aligns service design with business strategy and financial sustainability.
• Makes it easy to visualize trade-offs and opportunities.
• Useful for both new services and existing ones needing redesign.

When to use it

• In the Deliver phase, when preparing for rollout or scaling.
• Also helpful in early phases (Define/Develop) to test feasibility of concepts.

How to do it (practically)

1. Draw the canvas → Divide into 9 blocks: Customer Segments, Value Propositions, Channels, Customer Relationships, Revenue Streams, Key Resources, Key Activities, Key Partnerships, Cost Structure.
2. Fill collaboratively → Use post-its or digital tools (Miro, MURAL).
3. Focus on value proposition → Ensure user needs are clearly linked to business value.
4. Check balance → Are revenue streams sustainable? Do resources match activities?
5. Iterate → Adjust based on stakeholder feedback, prototypes, or pilots.

Example Output

For a subscription-based wellness app:

• Customer Segments → Young professionals, stressed employees.
• Value Propositions → Quick daily stress relief, guided meditation.
• Channels → Mobile app, employer programs.
• Customer Relationships → Automated onboarding, community support.
• Revenue Streams → Monthly subscriptions, B2B corporate packages.
• Key Resources → Content creators, app platform, analytics.
• Key Activities → Content production, app development, customer support.
• Key Partnerships → Employers, wellness influencers, payment providers.
• Cost Structure → Staff, tech infrastructure, marketing.

What it is

The Lean Canvas is a one-page business model framework adapted from the Business Model Canvas, designed for startups and innovation projects. It emphasizes problem-solution fit, risks, and early validation over detailed planning.

Why use it

• Helps teams focus on the riskiest assumptions first.
• Tailored for startups or new service initiatives that need to iterate quickly.
• Provides clarity on whether the idea has a viable path to traction.
• Easy to update as the service evolves.

When to use it

• In the Deliver phase, when preparing to launch or test a new service.
• Especially useful in early-stage ventures or pilot projects.

How to do it (practically)

1. Draw the canvas → Divide into 9 blocks: Problem, Customer Segments, Unique Value Proposition, Solution, Channels, Revenue Streams, Cost Structure, Key Metrics, Unfair Advantage.
2. Start with problem & customers → Clearly state top problems and target users.
3. Define solution → Outline how the service solves the problem.
4. Clarify value proposition → Why will users choose your service?
5. Map channels & metrics → How will you reach users and measure success?
6. Test assumptions → Validate quickly with prototypes, pilots, or MVPs.
7. Refine continuously → Update as you learn from experiments.

Example Output

For a meal-prep delivery startup:

• Problem → Busy professionals lack time to cook healthy meals.
• Customer Segments → Urban professionals, young families.
• Unique Value Proposition → Healthy meals, ready in 10 minutes, delivered weekly.
• Solution → Subscription meal kits.
• Channels → Website, app, social media ads.
• Revenue Streams → Monthly subscriptions.
• Cost Structure → Food sourcing, logistics, packaging.
• Key Metrics → Retention rate, churn, cost per acquisition.
• Unfair Advantage → Exclusive supplier partnerships.

What it is

The Value Proposition Canvas (VPC) is a strategic tool that zooms into two blocks of the Business Model Canvas: Customer Profile and Value Map. It helps ensure a service's offerings directly address user needs, pains, and desired gains.

Why use it

• Creates a clear link between what users need and what the service provides.
• Reduces the risk of building features or services that don't matter to customers.
• Aligns product/service teams around customer-centric value creation.

When to use it

• In the Deliver phase, before finalizing service features or go-to-market strategy.
• Useful earlier (Develop phase) for refining concepts before prototyping.
• Often used alongside Business Model Canvas or Lean Canvas.

How to do it (practically)

1. Draw the canvas → Two main sections: Customer Profile (Jobs, Pains, Gains) and Value Map (Products/Services, Pain Relievers, Gain Creators).
2. Fill Customer Profile → Use research insights to capture real user jobs, frustrations, and aspirations.
3. Fill Value Map → List offerings and how they reduce pains or create gains.
4. Match them → Draw explicit links between user needs and service benefits.
5. Refine → Adjust features, messaging, or priorities to maximize fit.

Example Output

For a digital fitness app:

• Customer Jobs → Stay fit with limited time.
• Pains → Expensive gyms, lack of motivation, boring routines.
• Gains → Affordable, fun, flexible workouts.
• Value Map → Service: On-demand fitness app. Pain Relievers: No gym needed, personalized routines. Gain Creators: Gamified challenges, community support.

→ Clear fit: Service directly addresses user pains (cost, motivation) and delivers desired gains (fun, flexibility).

What it is

Future backcasting is a strategic foresight method where teams first imagine a desired future state for a service or system, then work backwards to identify the steps needed to reach it. Unlike forecasting (which projects today forward), backcasting starts with the vision and designs the pathway to get there.

Why use it

• Encourages long-term, visionary thinking beyond current constraints.
• Helps organizations set bold goals and align strategies accordingly.
• Identifies the milestones and enablers needed for transformation.
• Useful for anticipating challenges and ensuring resilience.

When to use it

• In the Deliver phase, during strategy and long-term planning.
• Especially relevant for policy, sustainability, or digital transformation projects.
• Can also be applied in early discovery to inspire innovation.

How to do it (practically)

1. Define the vision → Imagine the desired future (e.g., "By 2030, all public services are fully accessible and digital-first").
2. Set the timeframe → Pick a horizon (5, 10, 20 years).
3. Work backwards → Identify key milestones that must be in place before the vision can be realized.
4. Identify enablers → Policies, technologies, partnerships, or cultural changes required.
5. Map the pathway → Translate milestones into a roadmap or phased plan.
6. Prioritize actions → Decide what must start now to make the future possible.

Example Output

For a carbon-neutral mobility service by 2040:

• Vision → All vehicles in the fleet are electric and powered by renewables.
• 2035 milestone → 80% of fleet converted, charging grid expanded.
• 2030 milestone → Major policy incentives, pilot cities fully electric.
• 2025 milestone → Early infrastructure investment and hybrid fleet.
• Actions now → Partnerships with charging providers, phased fleet upgrades.

What it is

The Impact-Effort Matrix is a simple prioritization tool that helps teams decide which service improvements or initiatives to focus on by mapping them according to their impact on users/business and the effort required to implement.

Why use it

• Provides a visual, quick way to prioritize competing ideas.
• Prevents teams from wasting energy on low-value, high-effort tasks.
• Creates alignment among stakeholders by making trade-offs explicit.
• Encourages a balanced portfolio of quick wins and strategic projects.

When to use it

• In the Deliver phase, when deciding which improvements to roll out first.
• After ideation, prototyping, or pilots, to choose which ideas to scale.

How to do it (practically)

1. List initiatives → Gather improvement ideas from research, testing, and workshops.
2. Define criteria → Impact: value for users, business outcomes, strategic fit. Effort: time, cost, complexity, resources needed.
3. Plot on 2x2 grid → High Impact / Low Effort → Quick Wins. High Impact / High Effort → Major Projects. Low Impact / Low Effort → Fill-ins. Low Impact / High Effort → Avoid.
4. Discuss and align → Get stakeholders to agree on placement.
5. Decide priorities → Focus first on quick wins and high-impact projects.

Example Output

For a retail banking service redesign:

• Quick Wins: Simplify online forms (high impact, low effort).
• Major Projects: Launch mobile loan application (high impact, high effort).
• Fill-ins: Redesign ATM interface colors (low impact, low effort).
• Avoid: Full branch renovation (low impact, high effort).

What it is

Cost-Benefit Analysis (CBA) is a decision-making tool that compares the expected costs of implementing a service improvement against the benefits it will deliver (financial, operational, or user experience gains).

Why use it

• Helps justify investments with a clear business case.
• Prioritizes initiatives that deliver the highest value for effort spent.
• Provides evidence to support leadership and funding decisions.
• Encourages a balance between desirability, feasibility, and viability.

When to use it

• In the Deliver phase, when evaluating which initiatives to fund and implement.
• Useful before pilots or large rollouts, especially in resource-constrained environments.

How to do it (practically)

1. List the initiative(s) → Define the service improvements or projects under consideration.
2. Estimate costs → Include development, training, infrastructure, staffing, and maintenance.
3. Estimate benefits → Quantify expected outcomes such as increased revenue, cost savings, efficiency gains, or improved satisfaction.
4. Convert to comparable units → Where possible, translate into financial terms (e.g., ROI, payback period).
5. Consider intangible benefits → Brand value, customer trust, employee satisfaction.
6. Compare and prioritize → Rank initiatives by benefit-to-cost ratio.
7. Decide and communicate → Present findings clearly to stakeholders for alignment.

Example Output

For a new customer self-service portal:

• Costs: $200K initial build + $50K/year maintenance.
• Benefits: $400K/year savings from reduced call center load + higher customer satisfaction.
• Result: Payback within 9 months, strong ROI → recommended to proceed.