About the role
Lead Service Designer
Translating Insight into Implemented Service Architecture
Design Thinking Unit · role charter, KRAs & blueprint implementation · goals reviewed quarterly
1. Where This Role Sits
The Design Thinking unit runs as a chain. The research teams complete the quantitative, qualitative and secondary work and hand over a synthesised insight set. Product, engineering and operations build and run. The Lead Service Designer owns the stretch in between — and, unlike a delivery designer, owns it all the way through: translating insight into touchpoints, blueprints and service architecture, then driving those blueprints into live service and proving they perform.
The Lead is accountable for what gets built from insight and whether it actually goes live — not for finding the insight, and not for stopping at a deck.
Research Teams
Quant · qual · secondary, synthesised into an insight set → Lead Service Design
Translates insight → blueprint → live service, and tracks that it works → Product · Eng · Ops
Builds and runs the service
2. Mandate
Convert the synthesised insight set into build-ready service architecture and carry it into live, performing service. Each Key Result Area is tracked by a single countable outcome — one number that says how much architecture the Lead produced from insight, took live, and proved. Goals are reviewed once a quarter; there is no weekly or monthly scoring.
3. Methodological Foundation
Two disciplines set the bar for the role. The Lead is the person in the unit who guarantees both are upheld on every piece of work.
Human-centred design discipline
• Three-lens test. Every architecture decision sits in the overlap of desirability (people), feasibility (technical) and viability (business). The Lead guards that overlap.
• Inspiration → ideation → implementation. The Lead is accountable for carrying work through the implementation phase — the phase most teams skip — not stopping at ideation.
• “How Might We” reframing. Insights are turned into design challenges before anything is architected, to keep the solution space open.
• Build to think. Touchpoints are prototyped and tested before they are committed to a blueprint; a bias toward action over analysis, and learning from what fails early.
• Co-creation. Frontstage and backstage owners are designed with, not at — they help shape the lanes they will run.
Service-design rigour
• Full blueprint anatomy. Customer actions, frontstage actions, backstage actions and support processes — plus physical evidence and emotion where they matter — never a journey map masquerading as a blueprint.
• The three lines, enforced. Line of interaction (customer ↔ frontstage), line of visibility (frontstage ↔ backstage), and line of internal interaction (backstage ↔ support). No orphan moment crosses a line without support.
• Journey first, blueprint second. The journey map is the customer truth that the blueprint operationalises behind the scenes; the two stay in sync.
• Heuristic-clean touchpoints. Digital moments are reviewed against Nielsen's usability heuristics — visibility of system status, match to the real world, consistency, error prevention.
• Evidence-based, end to end. Every blueprint moment is traceable to research and instrumented with a metric, so nothing in the service is unsupported by either insight or data.
4. Key Result Areas — One Outcome Each
Six KRAs, weighted by contribution to the quarterly score. Each is tracked by exactly one number; every number is an insight-derived output. The IDEO/NN/g lens each area enforces is named in its description.
4.1 Insight-Driven Touchpoint Design (12%)
Designs the customer-facing moments along the line of interaction, each carrying a research insight and reviewed against Nielsen's usability heuristics.
Tracked outcome: Number of insight-driven touchpoints designed on blueprints
Counted as: each touchpoint is traceable to a synthesised insight and heuristic-reviewed.
4.2 Service Blueprinting (18%)
Builds the full NN/g blueprint — customer actions, frontstage, backstage and support processes — across the three service lines.
Tracked outcome: Number of complete service blueprints developed from insights
Counted as: complete only when all lanes and the lines of interaction, visibility and internal interaction are present.
4.3 Service Architecture (15%)
Develops the system architecture that makes a blueprint buildable, holding IDEO's desirability–feasibility–viability balance.
Tracked outcome: Number of service architectures developed from insights
Counted as: one per distinct architecture that passes the three-lens test.
4.4 Blueprint Implementation (25%)
Carries blueprints through IDEO's implementation phase — operationalising every lane with named owners until the service is live.
Tracked outcome: Number of service blueprints taken live into service
Counted as: live only when frontstage moments are backed by working backstage and support processes (line integrity intact).
4.5 Implementation Tracking & Service Health (18%)
Instruments each live moment with a metric tied to the insight it serves, and tracks whether the service performs as designed.
Tracked outcome: Number of live blueprint moments instrumented and tracked against intent
Counted as: a moment counts once it carries a live metric compared to its insight-driven target.
4.6 Standards & Reusable Patterns (12%)
Sets the unit's blueprint standard, grows the library of reusable service patterns, and mentors the team.
Tracked outcome: Number of reusable service patterns adopted across the unit
Counted as: a pattern counts when reused in another team's blueprint.
5. Implementation & Tracking of Service Blueprints
A blueprint has no value until it is live and performing. This is the part of the role that separates a Lead from a designer who hands off a diagram: the Lead owns the path from a finished blueprint to a running service, and the evidence that it works.
Implementation states
Every element of a blueprint moves through five states. A blueprint is only “implemented” once all of its elements reach the last two.
Designed → Owner assigned → In build → Live → Validated
Blueprint implementation tracker
For each blueprint the Lead maintains a tracker keyed to the NN/g lanes. Each lane's elements get a named owner and a state; nothing is “live” while a lane below it is still in build.
Blueprint lane What is implemented Owner State (example)
Customer actions The journey moments the service must serve Journey owner Live / Validated
Frontstage actions Visible staff and interface moments above the line of interaction Channel owner In build / Live
Backstage actions Invisible staff/system actions below the line of visibility Ops / product owner In build
Support processes Internal systems and third parties below the line of internal interaction Platform / vendor owner Owner assigned
Physical evidence Props and artefacts the customer encounters at each moment Design owner Designed
Line-integrity gates
A blueprint cannot be marked live until all three NN/g lines hold. These are the Lead's go-live gates:
• Line of interaction — every customer-facing moment exists and is reachable.
• Line of visibility — every frontstage action is supported by the intended backstage action; no orphan moments.
• Line of internal interaction — backstage actions are wired to the support processes and third-party systems they depend on.
Tracking that it works
Once live, each moment carries a metric tied to the insight it was meant to serve — for example, the drop-off or friction the insight surfaced. Quarterly, the Lead reviews actual against intended and re-opens any moment that underperforms, looping it back through the states. This closes IDEO's iterate loop: a blueprint is not “done” at go-live, only when it is validated against intent.
Definition of done: all lanes live, the three lines intact, every moment instrumented with an insight-linked metric, and the service validated against the original intent.
6. Tracked-Outcome Scorecard
One row per Key Result Area, one number per row, reviewed every quarter. This is the whole tracker — what the Lead reports back.
Key Result Area The one number tracked What qualifies as a count
Insight-Driven Touchpoint Design Insight-driven touchpoints designed on blueprints Traceable to an insight; heuristic-reviewed
Service Blueprinting Complete service blueprints developed from insights All lanes and all three lines present
Service Architecture Service architectures developed from insights Passes the desirability–feasibility–viability test
Blueprint Implementation Service blueprints taken live into service Frontstage backed by backstage & support; lines intact
Implementation Tracking & Service Health Live blueprint moments tracked against intent Carries a live metric vs its insight-driven target
Standards & Reusable Patterns Reusable service patterns adopted across the unit Reused in another team's blueprint
How it rolls up: each count is multiplied by its KRA weight and summed to the quarterly score. Because every number is an insight-derived output — and implementation counts only when the service is live and proven — the scorecard reads as a straight tally of working service produced from research.
7. Lead Scope & Team Allocation
What makes this a Lead role, beyond personal output:
• Owns the unit's blueprint standard — the final reviewer of whether work is implementation-ready.
• Accountable for service health across the portfolio, not just blueprints produced — the buck for “did it go live and work” stops here.
• The senior point of influence with product, engineering, operations and business owners who run the lanes.
• Mentors service designers and grows the reusable-pattern library so the team translates and implements faster over time.
How the Lead allocates work
Work is assigned across the team by conversion complexity — clarity of the incoming insight, number of systems and touchpoints, depth below the line of visibility, and compliance stakes:
• Ambiguous, multi-system or regulated blueprints → the Lead leads or pairs closely; juniors support to build craft.
• Clear, scoped blueprints in a known area → a service designer owns end-to-end; an associate stretches into part of it.
• Implementation-heavy work with many lane owners → kept senior, because line-integrity and stakeholder orchestration carry the risk.
This page is fully interactive when JavaScript is enabled. Please enable JavaScript to apply or browse related roles.
