CASE STUDY / DESIGN OPERATING MODEL / ORGANIZATIONAL DESIGN / TEAM TOPOLOGY
From urgent requests to value-aligned design workstreams
How I created a design operating model that transformed fragmented requests into
coordinated streams of work, and made team structure, staffing, and investment easier to
align with the business.
ORGANIZATION
Scotiabank Global Banking & Markets · National Bank Independent Network
30+ product designers, researchers, and UX engineers, embedded across derivatives and
wealth platform teams
TIMELINE
2017 — Present · introduced at Scotiabank, matured at National Bank
01 / THE OPPORTUNITY
"Urgent" had become a substitute for prioritization.
The design team was operating in an environment where nearly every request arrived as
urgent. Each request was valid. Together, however, they created a fragmented system of
work. Designers moved between strategic questions, feature definition, production
support, and post-release issues without a shared way to distinguish them. Everything
entered the same queue, competed for the same people, and appeared to have the same
priority.
ONE QUEUE, EVERYTHING URGENT
STAKEHOLDER
URGENT
A prototype for an upcoming meeting
PRODUCT TEAM
URGENT
Designs for its next sprint
ENGINEERING
URGENT
Specifications, accessibility guidance, missing component states
RELEASE TEAM
URGENT
Help with onboarding, communications, customer feedback
THE RESULT WAS PREDICTABLE
01
Strategic work was repeatedly displaced by immediate delivery requests.
02
Designers were engaged at inconsistent points in the product lifecycle.
03
Research, feature design, production support, and release learning competed for the
same capacity.
04
Staffing decisions were based on request volume rather than business value.
05
Teams could see what design was producing, but not always what outcome the work
supported.
The team did not simply need a better backlog. It needed a clearer operating model.
02 / REFRAMING THE PROBLEM
The requests were fundamentally different types of work.
The initial temptation was to improve intake: a request form, priority labels, a central
triage meeting. Those changes might have made the queue more orderly, but they would not
have addressed the underlying issue. A request to determine product direction is not the
same as refining a feature entering development. Accessibility implementation is not the
same as understanding why customers struggle after release. Treating them as one
workflow obscured their different purposes, collaborators, timelines, and definitions of
success.
THE TEMPTATION: BETTER INTAKE
Create a request form
Add priority labels
Establish a central triage meeting
I REFRAMED THE CHALLENGE AROUND A MORE USEFUL QUESTION
How might we organize design around the value it creates throughout the product
lifecycle?
This shifted the conversation from managing design requests to structuring design as a
business capability.
03 / MAPPING DESIGN TO THE PRODUCT LIFECYCLE
Four value streams, each tied to a business decision.
I mapped the design activities taking place across the organization and grouped them
according to the decision each activity helped the business make. Instead of operating
beside the business, design could now complement the way the business set direction,
developed products, assured quality, and learned from customers.
THE ORGANIZATION'S PLANNING AND DELIVERY SYSTEM
PRODUCT ROADMAP
DEVELOPMENT BACKLOG
BUILDS & SPRINT DEMOS
RELEASES
DESIGN VALUE STREAMS
01
SOLUTION DESIGN
Are we solving the right problem?
02
FEATURE DESIGN
Have we identified the right solution?
03
UX ENGINEERING
Are we building the solution correctly?
04
CUSTOMER EXPERIENCE DESIGN
Did the solution create the intended value?
04 / THE FOUR WORKSTREAMS
Each stream has its own purpose, collaborators, output, and validation question.
01
SOLUTION DESIGN
Designing the right thing
Solution Design supports decisions about product direction before teams commit
significant delivery capacity. It brings together research, business goals, customer
needs, technical constraints, and stakeholder perspectives to establish a shared
success hypothesis.
TYPICAL ACTIVITIES
Clarifying initiative goals
Auditing the current experience
Understanding customer and stakeholder needs
Assessing the competitive environment
Evaluating technical capabilities
Identifying pain points and opportunities
Defining product goals and experience principles
Exploring and testing potential product directions
THE OUTPUT
A validated product vision supported by stakeholder alignment, customer
evidence, technical understanding, and an initial delivery strategy.
BUSINESS CONNECTION
Informs the product roadmap. Helps leaders decide where to invest, what outcomes
to pursue, and which assumptions to validate before funding detailed work.
PRIMARY VALIDATION QUESTION
Are we aligned on the problem, the desired outcome, and the direction most likely to
connect them?
02
FEATURE DESIGN
Designing the thing right
Once product direction is established, Feature Design turns that direction into usable
solutions that can enter development. It works ahead of engineering delivery,
exploring workflows and testing options before they become expensive to change.
TYPICAL ACTIVITIES
Auditing related features and workflows
Conducting contextual inquiry
Gathering customer and stakeholder feedback
Exploring interaction and visual-design alternatives
Defining information architecture and access-control behaviour
Applying accessibility and content requirements
Extending the design system
Prototyping and testing proposed solutions
Preparing specifications for delivery
THE OUTPUT
A validated solution direction for each feature or release.
BUSINESS CONNECTION
Feeds the development backlog. Reduces ambiguity before implementation and gives
product and engineering better evidence for planning, sequencing, and
estimation.
PRIMARY VALIDATION QUESTION
Does the proposed solution address the problem in a way customers can understand and
use?
03
UX ENGINEERING
Building it right
UX Engineering connects design intent with production quality. It focuses on the
architecture, components, responsive behaviour, accessibility, localization,
analytics, and validation needed to ensure the implemented experience matches the
intended solution.
TYPICAL ACTIVITIES
Establishing design tokens
Defining component behaviour and states
Extending the component library
Creating responsive and localized variants
Supporting design implementation
Defining accessibility requirements
Reviewing builds during delivery
Testing usability and interaction quality
Validating analytics and access-control behaviour
THE OUTPUT
Validated engineering quality: a solution built robustly enough to support real
use, different scenarios, and ongoing change.
BUSINESS CONNECTION
Works alongside delivery-track sprints, builds, quality assurance, and sprint
demonstrations. Reduces the gap between an approved design and the customer's
actual experience.
PRIMARY VALIDATION QUESTION
Has the solution been implemented in a robust, accessible, and reusable way?
04
CUSTOMER EXPERIENCE DESIGN
Confirming that value was delivered
A successful release is not the end of design work. It is the beginning of learning
from real behaviour. Customer Experience Design examines the full experience around
adoption, onboarding, support, communications, and ongoing use.
TYPICAL ACTIVITIES
Analysing customer touchpoints
Identifying customer-facing teams and responsibilities
Segmenting audiences and early adopters
Planning onboarding and support
Preparing release messaging
Running beta or UAT programs
Gathering feedback from customers and internal teams
Evaluating analytics and product behaviour
Identifying opportunities for future releases
THE OUTPUT
Validated value delivery: evidence that the released solution created the
intended change and insight into how it should evolve.
BUSINESS CONNECTION
Connects releases with customer success, support, adoption, and product
learning. Findings feed the next cycle of product direction and feature
discovery.
PRIMARY VALIDATION QUESTION
Did the release create the intended outcome for customers and the business?
05 / A BETTER WAY TO HANDLE URGENT REQUESTS
Urgency became specific.
The new model did not eliminate urgent work. It gave the organization a way to
understand and route it. Instead of asking only how quickly design could complete
something, the team could first identify the kind of decision involved. Teams could see
what kind of work was being interrupted, which outcome was at risk, and which
capabilities were required to respond.
IF THE REQUEST INVOLVES… → IT ENTERS
The problem or business outcome is unclear
SOLUTION DESIGN
The problem is understood but the experience is unresolved
FEATURE DESIGN
The solution is defined but implementation quality is at risk
UX ENGINEERING
The product has been released but adoption or value is uncertain
CUSTOMER EXPERIENCE DESIGN
LATE REQUESTS STOPPED DISGUISING EARLIER FAILURES
A usability issue discovered during development
→ incomplete feature validation
A release struggling with adoption
→ a gap in customer-experience planning or product direction
06 / STRUCTURING THE TEAM AROUND VALUE
Once the work was visible, topology could be deliberate.
With the work visible as four value streams, team topology and staffing could be
discussed more deliberately. Each capability needed different strengths, sat at a
different point in the lifecycle, and could be embedded, shared, or organized as an
enabling capability.
01
STRATEGIC
PRODUCT-DIRECTION CAPABILITY
Senior product designers, researchers, strategists, and product leaders focused on
ambiguous, high-impact initiatives before they entered the roadmap.
STRENGTHS REQUIRED
Systems thinking · research · facilitation · business alignment · concept validation
02
EMBEDDED
EMBEDDED DISCOVERY CAPABILITY
Product designers working with product and engineering teams ahead of delivery,
maintaining a validated stream of feature work rather than reacting inside
implementation sprints.
Design technologists, systems designers, accessibility specialists, and front-end
partners supporting multiple product teams as an enabling capability.
WHAT IT CONNECTED
Reduced duplicated implementation work · improved quality across the product
ecosystem
04
CROSS-TEAM
CUSTOMER-EXPERIENCE CAPABILITY
Service design, research, analytics, product, customer-success, and support partners
examining the end-to-end experience before and after release.
WHAT IT CONNECTED
Adoption · support · trust · longer-term customer value
07 / STAFFING FROM DEMAND, NOT HABIT
Gaps became visible, not just busyness.
The model made staffing conversations more concrete. Staffing could reflect the
organization's actual portfolio, product maturity, and flow of work. If every designer
was occupied with delivery support, the organization could see that product-direction
and customer-learning capacity were absent, not merely that the team was busy.
INSTEAD OF ASKING
How many designers do we need?
LEADERS COULD ASK
How much product-direction work is expected?
How many discovery streams must remain ahead of delivery?
Where are implementation quality and accessibility most at risk?
How many releases require coordinated onboarding and learning?
Which capabilities should be embedded in product teams?
Which capabilities should operate across multiple teams?
Where are handoffs creating delays or quality loss?
08 / CREATING CONTINUITY ACROSS THE STREAMS
Four streams, one connected system.
Research, assumptions, decisions, and measures of success could move forward with the
work rather than being rediscovered at every stage. This continuity helped reduce the
familiar gap between strategy and execution. Teams could understand not only what they
were building, but why the direction had been selected and how success would be
evaluated.
WHAT EACH STREAM VALIDATES → WHAT IT INFORMS
A VALIDATED PRODUCT VISION
informs the roadmap
VALIDATED FEATURE DIRECTIONS
inform the development backlog
VALIDATED IMPLEMENTATION
supports reliable builds and demonstrations
VALIDATED CUSTOMER VALUE
informs subsequent product decisions
CUSTOMER LEARNING FEEDS THE NEXT CYCLE OF PRODUCT DIRECTION
09 / WHAT CHANGED
From a single queue to a portfolio of value streams.
The operating model created a shared language for discussing design work across the
organization. Design was no longer represented as a single queue of screens, prototypes,
and production requests. It became a portfolio of complementary value streams with
different purposes, collaborators, outputs, and validation points.
01
Clearer routing and prioritization of incoming work
04
More intentional alignment between design and business planning
07
More meaningful measures of design effectiveness
02
Better separation of strategic, discovery, delivery, and release activities
05
Greater visibility into missing capabilities and staffing needs
03
Earlier involvement of design in product decisions
06
Stronger continuity from product vision to customer outcomes
At Scotiabank Global Banking & Markets, the model moved UX from a service function
into a core integrated discipline for the derivatives platform modernization, with the
design system formalized as a mandatory methodology across a 60+ person delivery
organization. At National Bank Independent Network, it underpinned a standing research
program, a usability testing practice, and analytics instrumentation to measure each
release, and supported the case for $31M in platform investment over four years.
10 / MY LEADERSHIP CONTRIBUTION
I made the complete design system of work visible.
The work required more than documenting a process. I had to connect activities that had
previously been treated independently, define the purpose and output of each stream, and
show how design could integrate with the organization's existing roadmaps, backlogs,
development cycles, and releases. In effect, the operating model turned design from a
service responding to demand into a system contributing throughout the product
lifecycle.
THE MODEL GAVE LEADERS A BASIS FOR DECISIONS ABOUT
01
Where design should participate
02
Which capabilities each stage required
03
How work should move between teams
04
Where validation needed to occur
05
How specialist and embedded roles could work together
06
Where additional staffing or investment would create the most value
11 / WHAT I LEARNED
Urgent work is often a symptom.
Five lessons carried forward from the work, each one a shift in how design work is
understood and organized.
01
Urgent work is often a symptom
A constant stream of urgent requests can indicate that important design questions are
being answered too late. Improving intake helps, but the greater opportunity is to
move the right decisions earlier.
02
Different design work needs different operating conditions
Strategic discovery, feature design, implementation support, and release learning
cannot be managed effectively as identical backlog items. They require different
skills, collaborators, timelines, and validation methods.
03
Team topology should follow value
An organizational chart should reflect how value moves through the business. Mapping
the work first makes it easier to decide which roles should be embedded, shared, or
organized as enabling capabilities.
04
Validation changes the definition of done
Design is not complete when a screen is approved. Each stream needs an appropriate
definition of success: a validated direction, a validated solution, validated
implementation quality, or validated customer value.
05
A model creates leverage when others can use it
The framework became valuable when product, engineering, and business partners could
use it to classify work, discuss priorities, and identify capability gaps without
relying on design-specific language.
12 / CLOSING
A better way for design and the business to work together.
The original problem looked like a backlog full of urgent design requests. The deeper
problem was that the organization lacked a shared model for understanding the different
ways design creates value. By separating the work into four connected streams, we
created a clearer relationship between design, product strategy, delivery, and customer
outcomes. That clarity made it possible to streamline the work, structure the team
around value, and make more deliberate decisions about staffing and investment.
The result was not simply a better design process. It was a better way for design and
the business to work together.