LEADERSHIP / PLAYBOOK 05 / ORGANIZATIONAL CHANGE · EXPERIENCE DIRECTION · ADOPTION
Leading change through experience direction
A playbook for design-led organizational change. Design's influence extends beyond
defining interfaces. By translating strategy into a visible future experience, design can
show teams what they are collectively trying to create, identify the organizational
capabilities required to deliver it, and make the consequences of fragmented decisions
tangible.
USE WHEN
The change concerns how an organization understands customers, sets product direction,
integrates work across functions, or delivers a coherent digital experience
HORIZON
A 90-day starting plan, then five waves of adoption from legitimacy to
institutionalization
WHO IT IS FOR
Design leaders sponsored to lead change, with product, engineering, business, risk and
people leaders retaining their own accountability
CORE ARTIFACTS
Change hypothesis · Case for change · Future-state experience · Coalition map ·
Minimum viable change · Adoption ladder · Change scorecard
THE CHANGE MODEL
Improve the operating model through the work teams already deliver.
The objective is not to introduce a transformation program alongside product delivery.
It is to improve the operating model through the work teams are already responsible for
delivering. Design leads the experience direction and the change-design work; business,
product, engineering, risk and people leaders retain accountability for their respective
decisions.
01
Customer evidence
02
Shared case for change
03
Future-state experience
04
Cross-functional coalition
05
Sequenced adoption
06
Measured results
01 / WHEN DESIGN LEADS
Determine when design should lead.
Design should not attempt to lead every transformation alone. Organizational
restructuring, financial change, regulatory programs, enterprise technology
modernization, and workforce strategy require accountable leaders from those domains. In
those situations, design can lead the experience direction and change-design work while
business, product, engineering, risk, or people leaders retain accountability for their
respective decisions.
WELL POSITIONED TO LEAD WHEN THE CHANGE CONCERNS
A fragmented customer journey spanning several departments.
A product portfolio lacking a coherent experience direction.
A shift from project delivery to persistent value streams.
Earlier customer discovery and validation.
A shared UX architecture or platform navigation model.
Adoption of a design system and reusable patterns.
AND WHEN IT CONCERNS
Better collaboration between product, design, and engineering.
Accessibility, content, or design-quality governance.
Product activation, adoption, and engagement.
Using future-state prototypes to guide platform modernization.
Introducing AI-enabled experiences with appropriate trust and controls.
DESIGN SHOULD NOT LEAD ALONE
Organizational restructuring.
Financial change.
Regulatory programs.
Enterprise technology modernization.
Workforce strategy.
Here design leads the experience direction and change-design work while the accountable domain leader owns the decision.
02 / DIAGNOSIS
Diagnose the system before proposing the change.
Change efforts often begin with a preferred solution: introduce a new process, create a
design system, reorganize teams, or add another review. Begin instead by observing how
work currently moves through the organization, using interviews, workflow observation,
project retrospectives, artifact reviews, customer research, delivery data, and
product-quality measures.
INVESTIGATE
How priorities are established.
When design, engineering, and customer evidence enter decisions.
Where work waits or is repeatedly revised.
Which decisions are unclear or continually reopened.
Where teams create incompatible solutions.
Which customer problems span organizational boundaries.
How quality is evaluated.
What happens after release.
Which incentives reinforce the current behaviour.
Where employees have already developed effective workarounds.
SEPARATE SYMPTOMS FROM CAUSES
VISIBLE SYMPTOM
POSSIBLE SYSTEMIC CAUSE
Design is involved late
Planning treats design as production rather than product direction
Teams repeatedly redesign common workflows
No shared UX architecture, ownership, or reusable system
Stakeholders continually change requirements
Outcomes and decision rights were never established
Products are inconsistent
Teams are rewarded for local delivery rather than portfolio coherence
Research does not affect decisions
Evidence arrives after commitments or lacks an accountable decision
Quality problems are found before release
Design review occurs in design files rather than working software
Features have low adoption
Delivery is measured, but activation and customer value are not
Teams resist a new practice
The practice adds work without removing an existing burden
THE RESULT SHOULD BE A CHANGE HYPOTHESIS
We believe changing this organizational behaviour for these teams will improve this
customer, business, or delivery outcome. We will begin with this limited intervention
and evaluate it using these measures.
03 / CASE FOR CHANGE
Build a shared case for change.
A persuasive case for change connects the customer experience with business performance
and the reality of how teams work. Design can assemble the evidence, but the case should
be developed with product, engineering, business, operations, and customer-facing
partners. People are more likely to support a change when their knowledge and
constraints are reflected in its definition.
01 / CUSTOMER CONSEQUENCE
Show how the current model affects customers.
Disconnected journeys.
Repeated information.
Inconsistent terminology.
Slow service.
Unclear decisions.
Preventable errors.
Low adoption.
Unequal accessibility.
Loss of trust.
Direct customer evidence makes the problem difficult to dismiss as a matter of design preference.
02 / BUSINESS CONSEQUENCE
Connect the experience problem to business performance.
Revenue or retention.
Conversion and activation.
Operating cost.
Support volume.
Delivery speed.
Rework and duplicated investment.
Regulatory or reputational risk.
Competitive differentiation.
03 / SYSTEMIC CAUSE
Explain what produces the current result.
Which planning practices, incentives, capabilities, organizational boundaries, or
decision rights produce the current result.
04 / CREDIBLE FUTURE
Show what will be observably different.
Show what will be observably different for customers and teams. Avoid relying on
abstract language such as “become customer-centric” or “improve collaboration.”
05 / ACHIEVABLE FIRST MOVE
Identify a bounded intervention.
A bounded intervention that can demonstrate value without requiring the whole
organization to change at once.
04 / VISIBLE FUTURE
Make the future visible.
The most important contribution design can make to a change initiative is turning an
abstract strategy into something people can see, discuss, test, and improve. These
artifacts serve as boundary objects: each function can see how its work contributes to
the same outcome, and disagreements surface while decisions are still inexpensive to
change. The future-state experience should be directional rather than falsely precise.
Future-state experience
A prototype, storyboard, or journey narrative showing how the client or end-user
experience should work.
Visual Roadmap
A medium-term view connecting near-term initiatives with the intended evolution of
the customer experience.
Current and future-state journey
A comparison showing which customer and organizational behaviours must change.
Service blueprint
A view of the people, processes, systems, policies, and backstage capabilities
required to support the experience.
UX architecture
A shared model for navigation, workspaces, roles, objects, workflows, integrations,
and reusable experience patterns.
Capability map
A description of the product, technology, data, operational, and organizational
capabilities required to reach the future state.
Experience principles
A small set of decision-making principles that explain how the brand and strategy
should appear through product behaviour.
05 / COALITION
Build a coalition with complementary authority.
Design rarely controls the budget, roadmap, technology, operations, and incentives
required for organizational change. It therefore needs a coalition whose members possess
different forms of authority. Skeptics often understand constraints the initial
coalition has missed: involve credible challengers early enough to affect the approach,
and investigate resistance rather than categorizing it as a personality problem.
COALITION ROLE
CONTRIBUTION
Executive sponsor
Establishes legitimacy, protects capacity, and resolves structural obstacles
Design change lead
Creates the experience direction, facilitates alignment, and guides adoption
Product leader
Connects the change to priorities, investment, and product outcomes
Engineering leader
Shapes feasibility, architecture, delivery practices, and technical adoption
Business or operations leader
Ensures the change works within real operating conditions
Data partner
Establishes baselines, instrumentation, and outcome measures
Customer-facing teams
Contribute market evidence and support customer adoption
Risk and control partners
Define necessary legal, privacy, security, or regulatory boundaries
People leader
Supports changes to roles, skills, performance expectations, and development
Practitioner champions
Test the new practices and make them credible to peers
Clients and end users
Validate whether the change improves the experience
ALIGN AROUND DECISIONS
Each alliance should be tied to a real decision.
What outcome matters?
What will change?
Who owns the change?
Which constraints must be respected?
What evidence would justify broader adoption?
What existing work or process will be removed?
General support is less valuable than explicit commitment to a decision, resource, or behaviour.
06 / OBSERVABLE BEHAVIOURS
Define the behaviours that must change.
A change initiative becomes actionable when it identifies observable behaviours.
“Improve product discovery” is too broad. New practices fail when they are added to
existing processes without removing redundant meetings, documents, approvals, or
handoffs.
FOR EXAMPLE, DESIRED BEHAVIOURS MIGHT INCLUDE
Product, design, and engineering frame initiatives together.
Business goals are restated as customer and product outcomes.
Teams identify risky assumptions before committing to delivery.
Representative customers evaluate the direction.
Engineering assesses feasibility before detailed design.
Roadmap decisions reference evidence and expected results.
Instrumentation is defined before development is complete.
Post-release evidence changes the next investment decision.
FOR EACH BEHAVIOUR, DEFINE
01
Who must perform it.
02
When it should occur.
03
What replaces the current behaviour.
04
The artifact, tool, or forum that supports it.
05
The skill or authority required.
06
How adoption will be observed.
07
What the organization must stop doing.
07 / SEQUENCED ADOPTION
Sequence change through live delivery.
Teams should not have to stop delivering in order to adopt a new operating model. The
model should be introduced through active, strategically relevant work, in five waves.
By the last wave, the change no longer depends on the original initiative or change
leader.
WAVE 1
Establish legitimacy
Document the customer and business problem.
Secure an accountable sponsor.
Build the initial coalition.
Establish a baseline.
Create the future-state direction.
Select a suitable pilot.
WAVE 2
Demonstrate the practice
Apply a limited set of new behaviours to one important initiative or value
stream.
The pilot needs a meaningful customer problem, leadership attention, a willing
cross-functional team, manageable dependencies, enough uncertainty to
demonstrate value, and results observable within a useful timeframe.
Avoid a trivial initiative that proves nothing or a critical program with no
tolerance for learning.
WAVE 3
Make the practice repeatable
Convert pilot lessons into templates, facilitation guides, examples, reusable
patterns, decision rights, quality criteria, training, measurement, and tool
support.
The repeatable method should be simpler than the pilot because unnecessary steps
will have been removed.
WAVE 4
Expand across value streams
Introduce the practice to additional teams, supported by coaching and
practitioner champions.
Adapt it to different risk levels rather than insisting on identical execution.
WAVE 5
Institutionalize
Embed the change into portfolio planning, funding, role expectations, hiring and
onboarding, product-development practices, design and engineering systems,
performance management, leadership reviews, and product metrics.
At this point, the change no longer depends on the original initiative or change
leader.
08 / MINIMUM VIABLE CHANGE
Use a minimum viable change.
A minimum viable change is the smallest modification to the operating model that can
produce meaningful evidence. It reduces disruption while creating enough evidence to
earn further investment.
IT INCLUDES
One clearly defined behaviour.
One accountable owner.
One active initiative.
One supporting tool or practice.
One observable outcome.
One feedback and improvement cycle.
EXAMPLE / DISCOVERY-PRACTICE PILOT
Problem
Requirements are committed before customer and technical risks are understood
New behaviour
Product, design, and engineering frame the initiative together before roadmap
commitment
Supporting practice
Initiative brief and assumption-mapping workshop
Pilot
One upcoming high-value feature
Evidence
Risks identified, decisions changed, rework avoided, time to direction
Next decision
Refine, expand, or stop the practice
09 / PROTECT DELIVERY
Protect delivery during adoption.
Change requires capacity. Pretending otherwise transfers the cost to evenings, quality,
or delivery commitments. The new operating model should eventually reduce coordination
and rework, not permanently increase them.
LEADERSHIP SHOULD EXPLICITLY DECIDE
Which team will pilot the change.
How much capacity is required.
Which existing activity will be reduced or removed.
Which delivery commitments remain fixed.
Which deadlines or scopes can change.
What support the pilot team will receive.
How long the pilot will run.
How issues will be escalated.
REPLACE RATHER THAN ADD
A status meeting
A decision review
A long requirements document
A shared initiative brief
Repeated local design work
A reusable pattern
Late approval
Earlier specialist participation
A large handoff
Continuous design-engineering review
Speculative reporting
Product instrumentation
10 / ADOPTION EXPERIENCE
Design the adoption experience.
The new practice is itself an experience. Its users are the employees, leaders, and
partners expected to adopt it. Attendance at training is not evidence that behaviour has
changed.
RESEARCH THEIR NEEDS
What are they trying to accomplish?
Which existing practices already work?
What do they fear losing?
Where will the new practice create effort?
Which incentives conflict with it?
What knowledge or authority is missing?
What would make the new approach easier than the old one?
THEN PROVIDE
Clear reasons for the change.
Role-specific examples.
Simple templates.
Facilitated first use.
Coaching and office hours.
Ready access to specialists.
Exemplars from real work.
Communities of practice.
Feedback channels.
Visible evidence of results.
USE AN ADOPTION LADDER · MEASURE ADOPTION AS A PROGRESSION
01
Awareness
People understand the reason for the change.
02
Trial
A team uses the practice with support.
03
Repeat use
The team chooses it again.
04
Routine
The practice becomes part of normal delivery.
05
Ownership
Practitioners improve and teach it.
06
Institutionalization
Structures and incentives reinforce it.
11 / RESISTANCE
Diagnose and respond to resistance.
Change leaders should not confuse compliance with commitment. Sustainable adoption
occurs when the new practice helps teams succeed and the surrounding system supports it.
TYPE OF RESISTANCE
LIKELY CAUSE
LEADERSHIP RESPONSE
Evidence-based
The case is incomplete or the approach will not work in context
Revisit the evidence and adapt the change
Capacity-based
Teams cannot absorb new work without missing commitments
Reduce scope, sequence differently, or protect capacity
Capability-based
People lack the knowledge or confidence to perform the new behaviour
Provide coaching, examples, pairing, and practice
Incentive-based
Existing targets reward the old behaviour
Change measures, funding, or leadership expectations
Authority-based
Decision rights are unclear or threatened
Clarify ownership and escalation
Identity-based
People believe the change devalues their expertise
Involve them in shaping the future role
Trust-based
Previous transformations did not deliver
Begin with a credible pilot and transparent evidence
Structural
Technology, policy, or team boundaries prevent adoption
Address the constraint before demanding compliance
12 / DECISION RIGHTS
Establish decision rights for the change.
The change leader coordinates the system but should not absorb accountability that
belongs to other functions.
DECISION
ACCOUNTABLE OWNER
Business reason and expected outcome
Executive or business sponsor
Future customer-experience direction
Design leader
Product-priority implications
Product leader
Technical and architectural implications
Engineering leader
New practice and adoption approach
Change lead with participating functional leaders
Risk, legal, privacy, or compliance acceptance
Relevant control owner
Pilot scope and delivery commitments
Product-design-engineering leadership
Broader rollout
Sponsor and affected functional leaders
Local implementation within guardrails
Value-stream team
Exceptions
Owner of the affected decision domain
Continuation, revision, or termination
Sponsor informed by outcome evidence
13 / MEASUREMENT
Measure outcomes, adoption, and organizational health.
A balanced change scorecard should cover four areas. The purpose of measurement is to
decide whether to continue, revise, expand, or stop, not to demonstrate that the
original change proposal was correct.
CUSTOMER & BUSINESS RESULTS
Task success and customer effort
Activation and adoption
Satisfaction and trust
Revenue, retention, or operational improvement
Reduction in customer-facing inconsistency
Progress toward the strategic value driver
DELIVERY EFFECTIVENESS
Time to make important decisions
Time from opportunity to evidence
Rework after development begins
Dependency delays
Defects found before and after release
Delivery commitments affected by the change
PRACTICE ADOPTION
Teams trying the new behaviour
Teams using it repeatedly
Decisions influenced by the practice
Use of shared patterns or artifacts
Teams teaching or improving the method
Exceptions and reasons for them
ORGANIZATIONAL HEALTH
Role and decision clarity
Cross-functional trust
Perceived usefulness of the new practice
Sustainable workload
Availability of coaching and support
Leadership participation
Ability to challenge and improve the model
14 / CHANGE CADENCE
Establish a practical change cadence.
Decision logs and evidence summaries should be maintained continuously. Status reporting
should be automated or asynchronous wherever possible.
CADENCE
PURPOSE
Weekly during a pilot
Resolve obstacles and capture learning without interrupting delivery
Biweekly
Review the quality of the new behaviour through real work
Monthly
Assess outcomes, adoption, capacity, and cross-functional dependencies
Quarterly
Decide whether to expand, modify, or stop the change
Semi-annually
Review whether structures, roles, incentives, and investment support the model
IMPLEMENTATION
A 90-day starting plan.
Understand the system and align a coalition; pilot the minimum viable change through
live delivery; then refine what worked, remove unnecessary process, and make an explicit
expand, revise, or stop decision.
DAYS 1–30
Understand and align
Diagnose the current system.
Establish customer and business consequences.
Identify systemic causes.
Create the change hypothesis.
Secure an accountable sponsor.
Build the initial coalition.
Establish baseline measures.
Create an initial future-state experience.
DAYS 31–60
Pilot through delivery
Select a suitable initiative.
Define the minimum viable change.
Clarify roles and decision rights.
Support the team through its first use.
Document obstacles and adaptations.
Protect the team's delivery capacity.
Gather evidence from customers and practitioners.
DAYS 61–90
Refine and expand
Compare results with the baseline.
Remove unnecessary process.
Convert lessons into reusable guidance.
Develop practitioner champions.
Select additional value streams.
Integrate the practice into planning and quality reviews.
Make an explicit expand, revise, or stop decision.
WHAT SUCCESS LOOKS LIKE
Design-led change is working when:
Design's role is not to make change look compelling. Its deeper contribution is to make
change understandable, testable, adoptable, and accountable to the people it is intended
to serve.
The organization shares a customer- and business-based reason for change.
The future experience is visible and credible.
Product, engineering, business, and operational leaders share ownership.
Desired behaviours are specific and observable.
New practices are tested through real delivery.
Teams receive capacity, coaching, and practical tools.
Existing processes are removed as new ones are introduced.
Adoption progresses from compliance to practitioner ownership.
Customer, delivery, and organizational results improve.
The new model no longer depends on the person who initiated it.
BACK TO / PLAYBOOK 01
Align design to business value
Start from the beginning
Discuss leading design-led change
Start a conversation