peterbamuhigire Service Design Proposal Strategy
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- The assignment involves customer, citizen, staff, patient, beneficiary, or partner experience.
- The proposal needs journey maps, service blueprints, touchpoint redesign, co-creation, prototyping, or implementation evidence.
- A website, software, AI, support, or digital transformation project must be framed as an end-to-end service, not only a technology build.
- The client needs better adoption, service quality, complaint handling, queue reduction, fulfilment, onboarding, or case resolution.
Domain Method
- Define the service outcome: what will improve for the user, frontline team, management, and institution.
- Map actors and influence: users, staff, managers, partners, regulators, vendors, and hidden back-office functions.
- Analyse the current journey across touchpoints, channels, waits, handoffs, emotions, pain points, failures, and workarounds.
- Blueprint the service: frontstage actions, backstage processes, systems, data, policies, evidence, and support responsibilities.
- Co-create options with users and staff, then prototype the riskiest service moments before recommending full implementation.
- Translate the design into implementation: operating model, roles, training, content, systems, measures, governance, and improvement cadence.
- State acceptance criteria: reduced waits, fewer handoffs, clearer communication, lower error rates, higher completion, better resolution, or stronger trust.
Quality Standards
- The proposal must show how service insight turns into deliverables and implementation decisions.
- Journey maps and blueprints must support action; do not include them as decorative research outputs.
- Co-creation must include the people who deliver the service, not only senior stakeholders.
- Digital components must be tied to human support, operational readiness, and measurable service outcomes.
Existing Deliverables
- Service design methodology section.
- Journey mapping and blueprint work packages.
- Co-creation workshop plan.
- Service implementation and measurement language.
Do Not Use When
- Do not use this skill when a neighbouring specialist named in the description owns the primary decision; route there first and use this skill only as a supporting layer.
- Do not use it to invent buyer facts, evidence, legal positions, statutory rules, delivery capacity, or current external claims.
Inputs
| Artefact | Source/provider | Required? | Missing-input behaviour |
|---|---|---|---|
| service mandate, stakeholder groups, evidence, channels, constraints, and implementation authority | Buyer, ToR, approved project record, accountable owner, or verified evidence source | Yes | Stop the affected decision, name the missing source, and return only a qualified outline or assumption register. |
Outputs
| Artefact | Consumer | Acceptance condition |
|---|---|---|
| service-design method, blueprint outputs, and implementation gates | Service owner, evaluator, and delivery team | Claims trace to supplied evidence; assumptions, owners, exclusions, decisions, and observable acceptance tests are explicit. |
Evidence Produced
| Evidence | Consumer | Acceptance condition |
|---|---|---|
| Decision and source trace for the output | Reviewer and release owner | Each load-bearing choice identifies its source, rationale, accountable owner, and any unassessed check. |
Capability Contract
Default to read-only for analysis, critique, discovery, and review. Minimum capability is access to the supplied artefacts and permission to inspect or calculate relevant evidence. Edit only the requested working copy. Do not publish, send, spend, change production systems, certify compliance, make a statutory claim, or approve a commercial concession without explicit authority.
Degraded Mode
If required files, interviews, finance doctrine, search evidence, calculation tools, network access, or specialist review are unavailable, return the narrowest useful qualified result. Mark unavailable checks as not assessed, separate facts from assumptions, and state what is needed to resume. An unassessed gate is never a pass.
Decision Rules
| Choice | Action | Failure/risk avoided |
|---|---|---|
| Research, co-design, prototype, or implement | Choose the next activity from evidence maturity and decision risk. | Producing journey maps with no operational change path. |
| Evidence conflicts or authority is absent | Stop the affected recommendation, record the conflict, and seek the named owner’s decision. | Invented facts or unauthorised commitments. |
| Evidence and approval are complete | Proceed within scope and retain the decision trace. | Irreproducible approval or scope drift. |
Workflow
- Confirm the consumer, decision, neighbouring-skill route, authority, and required inputs; stop if the primary route or accountable owner is unknown.
- Inspect supplied evidence and record facts, assumptions, conflicts, and unavailable checks; stop on a load-bearing contradiction.
- Apply the domain method and decision rules, preserving the repository’s proposal voice and specialist constraints.
- Draft the contracted output with observable acceptance conditions and an evidence trace.
- Review alignment with scope, work plan, team, pricing, risk, and dependent proposal sections; recover by revising the affected choice and rerunning the check.
- Run the critical-analysis and anti-slop gates; block release on unsupported claims, failed safety or finance gates, or an F slop grade.
Quality Standards
- Every load-bearing claim is verified or explicitly qualified, and the output distinguishes fact, assumption, recommendation, and commitment.
- Scope, method, work plan, staffing, pricing, risks, dependencies, and acceptance conditions remain mutually consistent.
- The output preserves domain constraints, names accountable owners, covers failure paths, and blocks unsupported or unauthorised promises.
- British English and the repository’s East African professional tone are used unless the buyer requires another standard.
- The critical-analysis and anti-slop gates pass before release, with no unassessed check represented as passed.
Anti-Patterns
- Inventing a buyer fact or proof point. Fix: cite the supplied source or mark the statement as an assumption requiring confirmation.
- Treating an unavailable check as passed. Fix: mark it not assessed and name the evidence needed to resume.
- Copying a neighbouring skill’s method without routing. Fix: use the specialist for the primary decision and retain only the supporting layer here.
- Writing acceptance as “satisfactory” or “appropriate”. Fix: state an observable measure, evidence record, and decision owner.
- Adding premium or technical claims without delivery capacity. Fix: reconcile the claim with named people, time, budget, dependencies, and authority.
Worked Example
A permit service has long hand-offs. Research affected users and staff, map backstage ownership, prototype the revised hand-off, and define an operational acceptance gate.
References
- service-design-methodology-module - proposal-ready service design phases, artefacts, and acceptance criteria.
- proposal-storytelling-and-evaluator-journey - evaluator journey and narrative logic.
- stakeholder-engagement - stakeholder mapping and consultation planning.
- change-management - adoption, readiness, resistance, and implementation support.