LEADERSHIP / PLAYBOOK 01 / STRATEGY · EXPERIENCE ARCHITECTURE · OPERATING MODEL

Aligning design to business value

A playbook for connecting product vision, customer experience and delivery execution. Design creates the most value when it is connected to the mechanisms through which the business succeeds.

USE WHEN

Design is disconnected from business priorities, or delivery is disconnected from the intended customer experience

HORIZON

12–24 month product direction, delivered through quarterly hypotheses

WHO IT IS FOR

Design, product and engineering leaders working across multiple teams on one platform

CORE ARTIFACTS

Value Driver Map · Visual Roadmap · UX Architecture · Hypothesis Brief · Measurement Plan

THE CORE CHAIN

Each link must be explicit.

I use this playbook to translate business objectives into a coherent experience strategy, a credible product direction and an operating model that allows multiple teams to deliver toward the same customer outcome. When one link is missing, design becomes disconnected from business priorities or delivery becomes disconnected from the intended customer experience.

01

Business strategy

02

Value drivers

03

Customer behaviours

04

Experience principles

05

Product hypotheses

06

Delivery streams

07

Evidence

08

Investment decisions

01 / VALUE DRIVERS

Identify how the business intends to create value.

The first step is to understand what must become true for the business to succeed. Design should not begin with screens, feature requests or a backlog. It should begin with the organization's value drivers, and the result should be a short value thesis, not an inventory of goals.

VALUE DRIVER

STRATEGIC QUESTION

POTENTIAL DESIGN CONTRIBUTION

Competitive advantage

Why should customers choose this product instead of an alternative?

Create differentiated workflows, capabilities or service experiences that are difficult to replicate.

Brand expression

What should customers consistently feel and understand when interacting with the business?

Translate the brand promise into interaction patterns, language, service behaviours and product quality.

Growth

What must persuade more customers to begin using the product?

Improve acquisition paths, first-use experiences, activation and time to value.

Adoption

What behaviours indicate that customers are receiving meaningful value?

Make valuable capabilities understandable, accessible and easy to incorporate into regular work.

Engagement

What should give customers a reason to return?

Design useful recurring workflows, feedback loops, progress indicators and relevant recommendations.

Retention

What causes customers to stay or leave?

Address persistent friction, increase reliability and ensure the product continues to support evolving needs.

Expansion and upsell

What additional value could customers receive from the business?

Reveal relevant capabilities at the right moment and demonstrate the incremental value of upgrading.

Operational efficiency

Where is complexity increasing the cost of serving customers?

Simplify workflows, automate routine work and improve the experience of internal service teams.

Platform scale

What must the product support as the business grows?

Establish reusable architecture, navigation, patterns and operating requirements across products and teams.

Risk reduction

Which assumptions could cause the initiative to fail?

Test the riskiest assumptions before committing significant development capacity.

OUTPUT / VALUE THESIS

One short statement, not a list of goals. Example:

“If we make it easier for customers to understand, adopt and expand their use of the platform, the business can improve conversion, engagement and account growth while reducing the cost and risk of delivering fragmented experiences.”

02 / CUSTOMER BEHAVIOUR

Connect business value to customer behaviour.

A business objective is not yet a design objective. It must be translated into a customer behaviour that design can influence and the organization can observe. This prevents a metric such as “increase engagement” from becoming an abstract mandate. It identifies whose behaviour must change, why it should change and what design must make easier.

FOR EVERY BUSINESS OBJECTIVE, DEFINE

01

The customer segment.

02

The customer problem or desired progress.

03

The behaviour that would demonstrate value.

04

The experience change expected to produce that behaviour.

05

The business result connected to the behaviour.

06

The evidence that will confirm or challenge the hypothesis.

VALUE HYPOTHESIS TEMPLATE

We believe that helping [customer segment] accomplish [important job or outcome] through [experience change] will increase [target behaviour], contributing to [business result].

We will evaluate this by measuring [leading indicators], [business outcome] and [guardrail measures].

EXAMPLE

We believe that helping new advisory firms configure their workspace through a guided onboarding experience will reduce uncertainty and shorten time to first value. This should increase activation, adoption of core workflows and the likelihood that firms expand their use of the platform.

We will evaluate this through onboarding completion, time to first account, adoption of core workflows, support volume, satisfaction and subsequent feature activation.

03 / PRODUCT VISION

Establish a compelling medium-term product vision.

Teams need a view beyond the next feature or release. Without one, each team optimizes its assigned area while the overall experience becomes fragmented. I use a Visual Roadmap: a realistic, interactive representation of how the product could work over a 12 to 24 month horizon. Unlike a roadmap made of project names and dates, it shows what the future will feel like to a customer, so executives, customers, product managers, designers and engineers can react to the same representation of the future.

THE VISUAL ROADMAP COMBINES

The product vision.

Priority customer journeys.

Platform navigation and workspace structure.

Existing capabilities.

Planned improvements.

New product hypotheses.

Design-system components and patterns.

Technical and operational constraints.

Progressive release states.

Measurement points.

WHAT IT IS FOR

Communicating a credible product direction.

Aligning teams around a common experience.

Connecting near-term work to longer-term value.

Testing whether individual initiatives form a coherent product.

Exploring product and platform dependencies.

Supporting investment and prioritization decisions.

Giving teams context without prematurely fixing every implementation detail.

WHAT IT IS NOT

A promise that every represented feature will be built.

A substitute for discovery.

A detailed delivery specification.

A polished concept designed only to persuade executives.

A reason to ignore evidence gathered during implementation.

The roadmap should remain a living model. As evidence changes the product strategy, the future experience should change with it.

04 / UX ARCHITECTURE

Define how the product fits together as a system.

The Visual Roadmap establishes the direction. UX architecture defines how the product fits together as a system. This is especially important when multiple teams build different parts of one platform. Without a shared architecture, each team may deliver a reasonable local solution while producing an incoherent overall experience.

A

Platform navigation

How customers move through the platform and how it grows without constant restructuring.

How customers move among products, workspaces and major functions.

Which destinations are global and which belong to a specific workspace.

How context is maintained when users move between modules.

How navigation adapts to permissions, customer segments and product entitlements.

How new capabilities can be added without continually restructuring the platform.

B

Workspace model

Workspaces organize the product around meaningful customer contexts rather than the internal structure of the company. Each establishes a clear context, purpose and set of available actions. A workspace might represent:

A customer account.

A portfolio.

A project.

A team.

A business process.

An operational responsibility.

A stage within a customer journey.

C

End-to-end workflows

Key workflows are designed across team and product boundaries so the customer's experience is evaluated as a whole rather than screen by screen. For each workflow, document:

Customer intent.

Entry points.

Required information.

Major decisions.

Handoffs between people or systems.

System states.

Exceptions and recovery paths.

Completion criteria.

Opportunities for guidance or automation.

Measurement events.

D

Experience patterns

Components solve recurring interface problems. Patterns solve recurring customer and business problems, giving independently operating teams a starting point for solving similar problems in similar ways.

Search and discovery.

Onboarding and setup.

Configuration.

Review and approval.

Complex data entry.

Comparison and decision-making.

Notifications and status.

Exceptions and error recovery.

Permissions and access.

Upgrade and expansion.

Help and guidance.

05 / PLATFORM REQUIREMENTS

Define the conditions the platform must support.

A strong product vision must be grounded in the contexts in which the business needs to operate. These conditions become functional and non-functional platform requirements. They should be treated as product strategy, not technical cleanup: they determine which markets, customers and operating models the business can support.

FUNCTIONAL REQUIREMENTS

What customers, partners and internal teams must be able to accomplish. Each connects to a customer job, a business capability and a measurable result.

Create and manage accounts.

Configure products or services.

Complete transactions.

Review and approve work.

Collaborate across roles.

Integrate partner-developed capabilities.

Control permissions and entitlements.

Access support and guidance.

Evaluate activity and performance.

Discover and activate additional services.

NON-FUNCTIONAL REQUIREMENTS

The conditions under which those capabilities must operate successfully.

Accessibility and regulatory compliance.

Multilingual content and localization.

Performance and responsiveness.

Browser and device support.

Security and privacy.

Reliability and recoverability.

Analytics and observability.

White-labeling and brand configuration.

Role-based access and permissions.

Feature bundling and entitlements.

Partner extensibility.

Multiple customer operating models.

Content governance.

Support and service operations.

06 / PRODUCT BETS

Turn the vision into a portfolio of hypotheses.

The vision provides direction, but delivery should proceed through testable hypotheses. Break the future experience into a portfolio of product bets, each with a clearly defined customer and business problem, evidence that it matters, a proposed change, the expected outcome, the most important assumptions, an evaluation plan, a decision that will be made using the evidence, and a responsible product, design and engineering owner. This turns a roadmap from a list of commitments into a sequence of informed investments.

Hypothesis brief

ONE PER PRODUCT BET · OWNED BY PRODUCT, DESIGN AND ENGINEERING

01

Business objective

What result is the organization trying to produce?

02

Customer problem

What is preventing the customer from receiving value?

03

Proposed change

What product, service or experience change might address the problem?

04

Assumptions

What must be true for the proposed change to work?

05

Leading indicators

Which behaviours will change before the business result becomes visible?

06

Outcome measure

Which business result should ultimately change?

07

Guardrails

What must not become worse as a result?

08

Evaluation point

When will the team review the evidence?

09

Design work often arrives as a collection of urgent requests. This keeps designers busy but makes staffing, prioritization and impact difficult to manage. A more scalable model organizes design into four connected streams. They are not sequential departments; they are connected areas of responsibility that may operate concurrently, and the topology and staffing of the design organization can be based on the work required within each stream rather than on the volume of incoming requests.

STREAM

PURPOSE

TYPICAL WORK

PRIMARY EVIDENCE

Product direction

Determine what should be built and why

Strategy, customer research, journey analysis, Visual Roadmap, product concepts

Problem importance, strategic alignment and investment confidence

Feature discovery

Determine how priority problems should be solved

Workflow design, prototyping, usability testing and delivery planning

Usability, usefulness, feasibility and customer intent

UX engineering

Ensure the solution is implemented coherently and efficiently

Architecture, components, patterns, accessibility, design QA and analytics instrumentation

Quality, consistency, reuse, performance and delivery efficiency

Customer-value validation

Determine whether the released experience produced the intended result

Alpha and beta programs, onboarding, behavioural analytics and customer feedback

Adoption, engagement, retention, expansion and satisfaction

09 / TEAM TOPOLOGY

Align team topology to the product architecture.

The design organization should reflect how customer value flows through the product. The exact structure will vary. What matters is that ownership exists for both local product delivery and the coherence of the overall customer experience.

Product-area designers

Embedded with product and engineering teams, responsible for specific customer problems, workflows and outcomes.

Experience architecture

Responsible for the platform navigation model, cross-product journeys, workspace structure and consistency across team boundaries.

Design systems and UX engineering

Responsible for reusable components, patterns, implementation guidance, accessibility, design-system code and contribution processes.

Research and measurement

Responsible for discovery programs, customer panels, usability testing, product analytics and evaluation methods.

Customer-experience design

Responsible for onboarding, support, communication, service transitions and the experience surrounding the product.

10 / GOVERNANCE

Establish governance without creating a bottleneck.

Governance should increase decision quality and delivery speed. It should not require every design decision to pass through a central authority. A small set of forums, each with a clear purpose and cadence, is paired with explicit decision rights.

FORUM

PURPOSE

CADENCE

Business and experience review

Confirm value drivers, outcomes and major investment decisions

Quarterly

Visual Roadmap review

Align product areas around the future experience and major dependencies

Monthly or quarterly

Experience architecture review

Resolve navigation, workflow and cross-product decisions

Biweekly

Design-system contribution review

Evaluate new components and patterns for reuse

Weekly or biweekly

Product evidence review

Examine research, experiments and product metrics

Monthly

Release-value review

Determine whether released work created the intended result

After major releases

Design quality review

Coach teams and raise the craft standard

Weekly

DECISION RIGHTS SHOULD BE EXPLICIT

Executives

own business priorities and investment decisions.

Product leaders

own product outcomes and sequencing.

Design leaders

own experience strategy, quality and coherence.

Engineering leaders

own technical quality, resilience and feasibility.

Embedded teams

own evidence-based execution within those boundaries.

Platform and system leaders

own standards that affect multiple teams.

11 / MEASUREMENT

Measure the complete value chain.

No single metric demonstrates that design is effective. A balanced measurement model connects customer experience, product behaviour, business outcomes and delivery performance. Metrics should be established before delivery begins: if instrumentation is added after release, the team may be unable to answer the question that justified the investment.

CUSTOMER EXPERIENCE

Task success

Time on task

Error and recovery rates

Time to first value

Customer effort

Satisfaction and confidence

Accessibility success

Qualitative feedback

PRODUCT BEHAVIOUR

Activation

Feature adoption

Frequency of use

Depth of engagement

Completion of critical workflows

Retention

Use across products or modules

Return behaviour

BUSINESS OUTCOMES

Acquisition

Conversion

Revenue

Account or subscription growth

Upsell and cross-sell

Retention and churn

Cost to serve

Support demand

Customer lifetime value

DELIVERY EFFECTIVENESS

Time from hypothesis to evidence

Time from approved direction to release

Rework caused by unclear requirements

Design-system adoption

Reuse of patterns and components

Defect and accessibility escape rates

Teams aligned around shared workflows

Initiatives with defined success measures

12 / OPERATING CADENCE

Use a practical operating cadence.

The playbook runs on a rhythm that connects strategy to each delivery cycle. Strategy and organization are revisited slowly; the roadmap and portfolio quarterly; evidence monthly; and validation, prototyping and QA inside every delivery cycle.

ANNUALLY OR SEMI-ANNUALLY

Reset direction

Revisit business strategy and value drivers.

Update the experience vision and platform principles.

Identify major capability and architecture gaps.

Review the design organization and team topology.

QUARTERLY

Reprioritize the portfolio

Refresh the Visual Roadmap.

Prioritize the portfolio of product hypotheses.

Confirm outcome measures and investment levels.

Review cross-team dependencies.

MONTHLY

Review the evidence

Review customer research and product data.

Evaluate platform and experience-architecture decisions.

Review design-system adoption and emerging pattern needs.

Assess progress against customer and business outcomes.

EVERY DELIVERY CYCLE

Ship and learn

Validate the problem.

Prototype the proposed direction.

Test the riskiest assumptions.

Define implementation and measurement requirements.

Conduct design and accessibility QA.

Review released outcomes.

CORE TOOLS

A small set of connected artifacts.

The playbook is supported by a small set of artifacts. Each one makes a link in the chain explicit, and each one is shared across the teams that depend on it.

Value Driver Map

Shows how the business intends to win and where design can influence that outcome.

Customer Journey and Workflow Maps

Show how customers experience value across teams, products and channels.

Visual Roadmap

Makes the medium-term product direction tangible and gives teams a shared model of the future.

UX Architecture

Defines navigation, workspaces, cross-product workflows, system states and platform relationships.

Design System and Pattern Library

Turns repeated experience decisions into reusable guidance and implementation assets.

Hypothesis Brief

Connects each initiative to a customer problem, expected behaviour, business result and evaluation decision.

Measurement Plan

Defines events, baselines, targets, guardrails and review dates before implementation.

Decision Log

Records important strategic, architectural and experience decisions, including the evidence and assumptions behind them.

Outcome Dashboard

Combines customer, product, business and delivery measures to show whether the portfolio is creating value.

SIGNS THE MODEL IS WORKING

How to tell the playbook is producing value.

None of these depend on a single metric. Together they show that design is connected to how the business creates value, that teams can work independently without fragmenting the experience, and that evidence is changing decisions.

Teams can explain how their work supports a business driver.

Customers encounter similar patterns across products and channels.

The brand is recognizable through product behaviour, not only visual styling.

Roadmap discussions focus on outcomes and evidence rather than feature volume.

Multiple teams can work independently without fragmenting the experience.

Design-system adoption reduces repeated design and development effort.

Important assumptions are tested before large investments are made.

Product analytics are defined as part of the design.

Research changes priorities and delivery decisions.

Releases are evaluated against the outcomes that justified them.

Staffing decisions reflect enduring value streams rather than the latest urgent request.

CLOSING PRINCIPLE

Align design with the way the business creates value.

The goal is not to align design with every request made by the business. It is to align design with the way the business creates value. A compelling vision gives teams direction. UX architecture ensures their work forms a coherent experience. Functional and non-functional requirements make the vision operationally credible. Hypotheses and evaluation points reduce delivery risk. Design systems and governance allow quality to scale.

Together, these practices turn design from a production service into an organizational capability for making better product investments and delivering more valuable customer outcomes.

NEXT / PLAYBOOK 02

Build a design-led product operating model

All leadership playbooks

Discuss aligning design to business value

Start a conversation