good-services-service-design

# End-to-end service design Define the service by the outcome a person needs, not the provider's org chart or one screen. Use Good Services as a practitioner framework for finding problems and improvements, not as a legal standard, automatic certification, or measured proof that an untested design works. ## Choose the useful scope Read the supplied brief, research, analytics, frontline accounts, policies, and operational constraints. Identify the user outcome, start trigger, done condition, user groups, channels, and pain point. Use existing answers rather than always repeating an intake questionnaire. State missing assumptions and proceed with the portion the evidence supports; ask only where an unresolved fact blocks a sound recommendation. A quick review needs the most consequential findings and next evidence, not every artefact. A cross-team redesign may need a definition, journey, blueprint, backlog, service standard, and validation plan. A workshop request needs a facilitation plan and unfilled templates, not invented workshop consensus. Adapt the outputs to the request; do not treat a full seven-part packet as mandatory. ## Follow the user's whole journey Use the [service definition](references/templates/service-definition-canvas.md), [service map](references/templates/service-map.md), and [blueprint](references/templates/service-blueprint.md) when they clarify the task. Map discovery, eligibility, preparation, decisions, transactions, waiting, support, completion, changes, cancellation, and aftercare where applicable. Include failed and alternative routes, not only the happy path. Show user-visible actions and information separately from staff, systems, policies, and handoffs. Record evidence at each step, whose experience it represents, and where coverage is missing. Do not invent user emotions, volumes, abandonment causes, staff capacity, or cross-team ownership. A stakeholder assumption is not observed user research; a drop-off metric does not by itself establish why people left or whether they achieved the outcome elsewhere. ## Review the principles with evidence Read [the principles](references/15-principles.md) as prompts for findability, purpose, expectations, completion, familiarity, prior knowledge, organisational handoffs, effort, consistency, dead ends, inclusion, incentives, change, decisions, and human assistance. Keep the intended user outcome and actual affected groups visible rather than averaging away exclusion. Use [the local scorecard](references/templates/principles-scorecard.md) only when scoring improves the decision. It distinguishes evidenced failure/partial/sound performance from **unverified** and **out of scope**. Do not award a number merely because a template has an empty cell. A narrowly scoped 2 is not proof the whole service works for everyone, and scores are not an interval scale to sum into a universal quality percentage. This package's 0–2 rubric is an internal shorthand. Lou Downe's published Good Services Scale uses 0–4; don't present the local worksheet as that official scale or convert between them without the actual definitions. For formal use of the published scale, consult the author's current material. ## Improve the service, not the score Prioritise demonstrated user harm, outcome failure, frequency, exclusion, operational risk, and effort. Separate confirmed causes from hypotheses. Put each proposed fix against evidence, an owner when known, dependencies, acceptance criteria, and the observation that would establish improvement. Use the [backlog](references/templates/improvement-backlog.md) and [service standard](references/templates/service-standard.md) as needed. Minimise unnecessary burden, not clicks at any cost. A pause, confirmation, appeal, or human conversation can protect understanding and agency. Do not hide cancellation, push people into self-service, or optimise call deflection while making support harder to obtain. Explain what happens after a refusal or error, including feasible alternatives and escalation; do not invent eligibility or appeal rights. Accessibility and inclusion require actual testing with relevant needs and channels. A visual audit cannot prove equal access. Check current applicable requirements, privacy, and safeguards; don't relabel a practitioner principle as legal advice. Evaluate the burden shifted onto staff, carers, partner organisations, or users who lack documents, connectivity, language fluency, time, or confidence. ## Validate and report Define a small test or pilot for the riskiest assumptions, with observable user outcomes, operational measures, and guardrails. Distinguish prototype intentions from observed results. Describe sampling, channel coverage, time window, and unresolved limits. Don't claim a workshop, survey, usability test, or production pilot happened when it was only proposed. Return the decision-useful map/findings/patch or plan, with evidence and specific next verification. For a workshop, use the existing [agenda](references/workshop-agenda.md), adapting roles, duration, and participation needs to the actual request. No stakeholder agreement or assigned ownership is implied until it is established. Sources reviewed 2026-09-13: [author's principles](https://good.services/) and [author's scale explanation](https://loudowne.com/). Detailed local templates are this package's adaptations, not a new official standard. Metadata follows the [Agent Skills specification](https://agentskills.io/specification).