Where strategy becomes something customers use.

Deliverables

1. Service blueprint setFront stage, back stage, and support layers for each priority journey
2. Orchestration & decisioning specSignals in, decision logic, action out, with the guardrails
3. Next-best-action libraryThe actions, their triggers, their eligibility, and their measures
4. Operational runbookExceptions, escalations, degradation modes, and who holds each one

Outcomes it answers to

• Every blueprint layer names a system, a team, and a policy owner
• Context survives the handoff, verified in QA rather than assumed
• Each next-best-action has an eligibility rule and a measured effect

Use it when

• The design is agreed but nobody has specified what makes it happen
• Channels each hold their own version of the customer
• Proactive service is an ambition with no decision logic behind it

Deliverables

1. Content inventory & auditEverything you have, scored keep, merge, rewrite, or retire
2. IA & navigation modelThe structure, the labels, and the tree-test scores behind them
3. Task flows & state mapsEvery path through the journey, including the ones that fail
4. Annotated wireframe setScreen by screen, with behavior, rules, and content requirements

Outcomes it answers to

• Labels are validated by tree testing rather than by internal preference
• Every flow has its failure and empty states designed, not deferred
• Engineering estimates from the wireframes without a second discovery

Use it when

• Navigation has grown a level every time a team needed a home for something
• Search is how people navigate because the structure failed
• A build is about to start from a visual design with no flow behind it

Deliverables

1. Interaction design setEvery screen and state in the priority flows, designed and annotated
2. UI design system applicationComponents, tokens, and patterns applied consistently across the product
3. Specification & handoff packBehaviors, rules, breakpoints, and edge cases written for engineering
4. Design QA reportWhat shipped versus what was designed, with the deltas triaged

Outcomes it answers to

• Every flow ships with its error, empty, and loading states designed
• Design QA runs before release and the deltas are closed
• New patterns enter the design system rather than staying local

Use it when

• A product is being built with no design owner and it shows
• Each squad has invented its own version of the same pattern
• The design is beautiful in the file and wrong in the build

Deliverables

1. Working prototypeClickable or coded, at the fidelity the decision requires
2. Validation findingsWhat people did against the criteria, round by round
3. Iterated designThe version that survived testing, with the changes traced to evidence
4. Build-readiness noteWhat is proven, what is stubbed, and what engineering still has to solve

Outcomes it answers to

• The prototype answers the question it was scoped for, and stops there
• Design changes between rounds are traceable to what a user did
• Engineering knows exactly what was faked before they estimate

Use it when

• A large build is about to be committed on a static design
• The experience depends on behavior that cannot be judged from a screen
• Stakeholders need to use the thing before they will fund it

Deliverables

1. Test plan & task scenariosWhat we ask people to do, and what counts as success before we watch
2. Findings with evidence clipsWhat people did, ranked by severity, with the moment on tape
3. Benchmark baselineThe numbers this experience scores today, repeatable next release
4. Prioritized fix listIssues written as backlog items with an owner and a size

Outcomes it answers to

• Success criteria were set before the first session, not fitted afterward
• Every severe finding leaves with an owner and a release
• The baseline is re-run after the change and the movement is reported

Use it when

• A launch decision rests on whether people can complete the task
• Two teams disagree about a design and both cite the customer
• You need a defensible before-and-after for a redesign

Deliverables

1. Baseline & redesign caseWhere it stands today and what the rebuild is expected to move
2. Restructured IA & content planThe new structure, the migration map, and the retirement list
3. Full redesign & specificationEvery template and state, specified for build
4. Release & measurement planSequence, rollback, and the numbers reported after each phase

Outcomes it answers to

• The baseline was taken before the first change shipped
• Content was rewritten rather than migrated unchanged
• Each release phase reports movement, and the fix list is closed

Use it when

• The platform is being replaced and the experience will be rebuilt regardless
• The current experience is the reason contact volume exists
• A rebrand or acquisition is forcing the work anyway

Deliverables

1. Foundations & token setThe primitives, named and versioned, ready for design and code
2. Component libraryComponents with variants, states, usage rules, and accessibility notes
3. Contribution & governance modelHow a pattern enters, changes, or leaves the system
4. Adoption plan & scorecardMigration order, owners, and the on-system percentage over time

Outcomes it answers to

• Design and code reference the same tokens, verified in the build
• New work is on-system by default and exceptions are logged
• Adoption is measured rather than assumed from the launch announcement

Use it when

• Three squads shipped three versions of the same component this quarter
• A rebrand would mean touching every screen by hand
• Accessibility is fixed per screen instead of once, in the component

Deliverables

1. Voice & tone systemHow the brand sounds, with the hard moments written out as examples
2. Interface content libraryThe reusable strings, patterns, and rules the product writes from
3. Conversation design setAgent turns, repair paths, escalation language, and what it never says
4. Content standards & governanceReadability bar, approval path, and the review cycle

Outcomes it answers to

• The failure moments are written before the happy path is celebrated
• Product teams reuse the library instead of inventing strings
• Readability is measured against a stated bar, including in regulated content

Use it when

• The interface is well designed and the words undo it
• An AI agent is about to speak to customers in nobody’s voice
• Legal and brand have been rewriting each other for a year

Deliverables

1. Conformance auditEvery issue against a success criterion, with severity and location
2. Assistive technology findingsWhat actually happens with a screen reader, on tape
3. Remediation planFixes routed to components, templates, and content, in priority order
4. Standards & evidence packAcceptance criteria, statement, and the record that supports it

Outcomes it answers to

• Fixes land in components, so the same defect cannot recur per screen
• Assistive technology testing is run by people who use it, not simulated
• Acceptance criteria block release, rather than being noted as debt

Use it when

• A complaint, a procurement requirement, or a regulation has arrived
• Accessibility is tested at the end and fails at the end
• A public-sector or enterprise buyer is asking for the evidence

Deliverables

1. Design operating modelIntake, prioritization, staffing, and the cadence that runs it
2. Tooling & repository architectureWhere things live, how they are named, and who maintains them
3. Quality bar & critique practiceWhat good looks like here, and how it gets reviewed
4. Capability & handover planRoles, hiring profiles, onboarding, and the exit criteria

Outcomes it answers to

• Intake is visible and prioritized rather than negotiated privately
• Critique is run to a stated bar, with decisions recorded
• Internal designers run the practice without us by the agreed date

Use it when

• Design is a queue and nobody knows what it is working on
• Good designers are producing inconsistent work because there is no bar
• You need capacity now and capability later