Overview
From the two perspectives of customer experience and service operations, organize the problem into a service concept, architecture, touchpoints, and a validation plan. Applies to full design, workshop preparation, and partial improvement of existing solutions.
If the need is only a persona, customer journey map, or ecosystem map / service blueprint, use the respective available customer-persona-framer、customer-journey-mapper or ecosystem-map-and-blueprint. When a full service design requires these tools, they can be used together without stopping the rest of the work.
Input Contract
From the requirements and existing materials, identify the service problem, audience, context, and pain points, then organize the operational goals, constraints, touchpoints, stakeholders, and specified format.
Judge whether the data is sufficient by whether it is enough to define this problem and scope, not by the number of fields. When information that would change the design direction is missing, confirm first. When reasonable progress is possible, produce a draft first, mark necessary assumptions and items to be confirmed, and avoid treating speculation as observation results.
Workflow
1. Confirm scope and required methods
Reuse existing and applicable data and outcomes. Full design covers the following stages; partial modification addresses the relevant stages and checks the affected handovers and validation.
- When the problem is vague, or when the service design positioning needs to be clarified or the overall process planned, read Principles and process。
- When a research, synthesis, ideation, or evaluation method needs to be selected, read Methods and tools, and select according to data gaps and stages.
- When organizing deliverables, read Output templates, using the full set for full design and the relevant parts for partial modification.
2. Complete the design by stage
| Stage | Required outcomes |
|---|---|
| Problem and context | Current state, pain points, service audience, constraints, and design goals, distinguishing data basis from assumptions |
| Stakeholders and needs | Review the needs, roles, and conflicts of customers, frontline staff, back office, and partners |
| Service concept and architecture | What value is provided to whom, service promise, main stages, handover methods, and required resources |
| Touchpoints and operations | Map customer actions, front stage, back stage, support processes, and service evidence by service stage, explaining responsible roles and handovers |
| Prototype and validation | Prototype form, assumptions to validate, test participants, methods, observed metrics, success signals, and next steps |
Understand the problem before ideating, and compare solutions by customer value, feasibility, and operational support. When a concept already exists, start from the problems that need correction, and do not redo unrelated stages.
3. Check completeness and verifiability
Check relevant roles, activities, handovers, and service evidence stage by stage. List insufficient data as items to be confirmed, and explain the reasons for items that truly do not apply. Completeness cannot be judged only by filling in one item per field.
The validation plan must explain what results, when observed, support the solution, and what to adjust if they do not support it. Success signals are set according to goals and existing data; when comparison data is lacking, arrange observation first, and do not arbitrarily fill in performance numbers.
Output Contract
By default, deliver in Traditional Chinese Markdown for Taiwan. Full design includes a service summary and outcomes for each stage; partial modification delivers the modified content, the rationale for judgments, and the affected related parts. When the user specifies a presentation or classroom assignment format, adjust the presentation according to the purpose while retaining the necessary information within this scope.
The template retains service_design_brief Field names for each stage are for fixed formats; general replies may use natural Chinese headings. When proposing a research or validation plan, clearly distinguish between what is planned to be executed and results already obtained.
Quality Rules
- For touchpoints, write the actual interaction and its service stage; do not merely list channel names.
- The backstage is the behind-the-scenes activity that supports frontstage delivery; support processes include other internal support and external systems, classified by activity.
- Service evidence is an observable physical or digital object, such as a space, interface, notification, document, uniform, or packaging.
- The methods selected must be able to address the data gaps in this case; do not substitute method names for analysis.