CASE STUDY / PLATFORM STRATEGY / UX ARCHITECTURE / OPERATING MODEL
Designing a modular platform: from siloed products to one unified experience
Feature teams were shipping well inside their own domains while the product as a whole
fragmented. I led the design of a platform model that let teams stay autonomous while
collectively building one coherent product.
ROLE
Program Lead · Principal Designer — platform strategy, UX architecture, design system,
and operating model
SCOPE
Identity & access · design system · modular frontends · platform UX & IA ·
reusable capabilities · visual roadmap
TEAMS
Multiple feature teams with mixed frontend stacks, plus a platform team
CONTEXT
Multi-team digital ecosystem serving client, transaction, reporting, and
administration workflows
01 / OVERVIEW
One product, built by many autonomous teams.
As our digital ecosystem grew, individual feature teams had become increasingly
effective at delivering within their own domains. But teams owned separate applications,
workflows, technology decisions, and user experiences, and those organizational
boundaries were becoming visible to customers. Users navigated between disconnected
experiences, similar capabilities were repeatedly rebuilt, and teams solved
platform-level problems independently.
The challenge was not simply to create a more consistent interface. We needed a platform
strategy that allowed teams to remain autonomous while collectively building one
coherent product — a platform where teams could build independently, integrate
predictably, and reuse capabilities by default.
I LED THE DESIGN OF A PLATFORM MODEL COMBINING
01
Centralized identity and access management
02
A shared design system
03
A modular frontend architecture
04
A platform-wide UX and information architecture
05
Reusable platform capabilities
06
Independent feature modules
07
A visual architecture and roadmap connecting the target experience to
development workstreams
02 / THE CHALLENGE
Three structural problems, not a styling problem.
The organization had multiple development streams responsible for different business
capabilities. Each was effective on its own. Together, they produced a product that made
sense from the perspective of the teams building it, but not necessarily from the
perspective of the customer using it.
01
We were shipping the organization chart
Each team naturally optimized the experience around the capability it owned. Over
time, the product architecture began reflecting internal ownership boundaries rather
than how users actually worked.
WHAT USERS ENCOUNTERED
Different navigation models
Inconsistent interaction patterns
Duplicated workflows
Separate entry points
Inconsistent terminology
Repeated authentication and authorization
Different approaches to common platform capabilities
02
Reuse happened too late
Teams frequently discovered that another team had already built something similar
only after implementation had begun. Reuse was primarily happening at the
UI-component level rather than at the capability level. A button could be shared.
But could an entire account selector, search experience, client profile, document
viewer, permissions interface, or workflow module be reused?
THE ARCHITECTURE NEEDED TO MAKE PROGRESSIVELY LARGER LEVELS OF REUSE POSSIBLE
DESIGN TOKENS
UI COMPONENTS
PATTERNS
PLATFORM CAPABILITIES
COMPLETE MODULES
03
Standardization was competing with team autonomy
A traditional monolithic frontend could produce consistency, but it would create a
bottleneck. Multiple teams needed to deliver concurrently, and different areas of
the organization had different technology constraints. The platform therefore needed
to support a seemingly contradictory set of goals.
Create one seamless product without requiring one team, one codebase, or even one
frontend technology.
03 / THE STRATEGY
One platform, composed of independently owned capabilities.
We reframed the product from a collection of applications into a platform composed of
independently owned capabilities. The strategy separated the system into four
interconnected layers. Each answered a different question: what every module can depend
on, how experiences look and behave, how teams ship independently, and what the whole
should become for the user.
01
PLATFORM FOUNDATION
Capabilities every module could depend on rather than recreate. These established the
contract between individual modules and the broader platform.
Teams still consumed shared tokens, specifications, behaviour, accessibility
requirements, and interaction contracts
03
MODULAR FRONTEND ARCHITECTURE
The application was decomposed into independently deployable modules, assembled inside
a common platform shell. Teams chose appropriate technologies while conforming to
platform contracts.
TEAM OWNERSHIP
Product capability → UX and interaction design → frontend module → supporting APIs
and services → deployment
PRINCIPLE
The platform controlled the experience boundaries. Teams controlled the
implementation within those boundaries.
04
UX ARCHITECTURE
A representation of what the platform should become from the user's perspective:
journeys, objects, capabilities, modules, and navigation relationships, independent of
org structure.
STARTING QUESTION
Not "what does each team need to build?" but "what does the user need the platform
to enable?"
BECAME
A shared model of the product, a visual roadmap, and a coordination mechanism for
decentralized development
THE PLATFORM CONTROLLED THE EXPERIENCE BOUNDARIES. TEAMS CONTROLLED THE IMPLEMENTATION
WITHIN THEM.
04 / THE UX ARCHITECTURE
Design the platform around what users need it to enable.
Technology alone would not solve the fragmentation problem. We needed a representation
of what the platform should become from the user's perspective. I created a platform UX
architecture mapping the major user journeys, objects, capabilities, modules, and
navigation relationships across the product — a shared model independent of the
organizational structure responsible for implementing it.
PLATFORM EXPERIENCE MAP
Platform
Home
Work requiring attention
Notifications
Recent activity
Clients
Search
Client profile
Accounts
Documents
Activity
Transactions
Trading
Transfers
Requests
Reporting
Cross-cutting reporting surface
Administration
Users
Roles
Permissions
Configuration
INSTEAD OF BEGINNING WITH
What does each team need to build?
WE STARTED WITH
What does the user need the platform to enable?
The hierarchy became a shared model of the product. It was independent of which team
implemented which branch, so navigation could follow user mental models rather than
ownership lines.
CREATING THE VISUAL ROADMAP
A roadmap that showed where each initiative landed in the target experience.
Instead of a roadmap of feature names, each major experience was connected through a
single traceable chain. It gave product, design, architecture, and engineering one
reference point, and turned the UX architecture from a design artifact into a
coordination mechanism for decentralized development.
USER JOURNEY
PLATFORM CAPABILITY
MODULE
COMPONENT
OWNING TEAM
DELIVERY INITIATIVE
TEAMS COULD SEE NOT ONLY WHAT THEY WERE RESPONSIBLE FOR BUILDING, BUT ALSO
01
Where their work appeared in the overall experience
02
Which other modules it interacted with
03
Which platform capabilities it depended upon
04
Which components already existed
05
Which components should become reusable
06
What future experiences needed to consume their work
05 / DESIGNING FOR REUSE AT MULTIPLE LEVELS
The highest-value reuse was never the button.
One of the most important architectural decisions was recognizing that reuse exists at
different levels. Instead of Team A building an account experience inside its
application and Team B building another version, the account experience could become a
reusable platform module composed into multiple contexts.
05
MODULES
Complete business capabilities that can be surfaced in multiple contexts
The highest-value reuse came not from sharing more buttons, but from designing
business capabilities so they could be composed into multiple experiences.
06 / ACCESS ARCHITECTURE
Centralize access without centralizing development.
Access management was particularly important because modular development could otherwise
reproduce authorization logic throughout the ecosystem. The platform determined the
user's context and capabilities. Modules consumed that context rather than independently
inventing access models.
IDENTITY
ROLE
PERMISSION
ENTITLEMENT
RESOURCE
A MODULE COULD EFFECTIVELY ASK
Can this user perform this action against this resource?
rather than owning the entire process for determining the answer.
CONSISTENT GOVERNANCE
Teams built independently while security and governance stayed consistent across
every module.
ACCESS-AWARE EXPERIENCE
Navigation, actions, modules, and functionality could be presented based on the
capabilities available to the user.
07 / CHANGING THE TEAM MODEL
Teams kept ownership. They owned capabilities, not destinations.
The architecture also required a change in how teams thought about ownership. The
distinction was subtle but important: teams still had ownership, but they owned
capabilities within a platform rather than isolated destinations within a portfolio of
applications. That allowed organizational boundaries to disappear from the customer
experience.
PREVIOUSLY
TEAM A
APPLICATION A
TEAM B
APPLICATION B
TEAM C
APPLICATION C
THE CUSTOMER EXPERIENCE BECAME
Application A | Application B | Application C
WE SHIFTED TOWARD
PLATFORM
CAPABILITY A
TEAM A
CAPABILITY B
TEAM B
CAPABILITY C
TEAM C
CAPABILITY D
PLATFORM TEAM
THE CUSTOMER EXPERIENCE BECAME
One platform composed of capabilities
08 / GOVERNANCE WITHOUT A BOTTLENECK
Governance through contracts, not approvals.
A platform architecture can easily replace distributed inconsistency with centralized
bureaucracy. We deliberately avoided requiring a central team to approve every product
decision. Governance happened through contracts and reusable infrastructure; within
those constraints, teams retained autonomy over their domains.
TEAMS WERE GIVEN CLEAR STANDARDS FOR
Module registration
Navigation
Access management
Design-system usage
Accessibility
Analytics
Responsive behaviour
Interoperability
Shared state
Platform events
THE OPERATING PRINCIPLE
Centralize the rules of interoperability.
Decentralize the implementation of capabilities.
09 / THE RESULT
The unit of thinking changed from applications and teams to users, capabilities, and
modules.
INSTEAD OF ASKING
Which application owns this?
TEAMS COULD ASK
Is this a platform capability that already exists?
Should this capability be reusable?
Where does it belong in the user's journey?
Which team should own its implementation?
What contracts must it satisfy to participate in the platform?
01
INDEPENDENT DELIVERY WITHOUT FRAGMENTED EXPERIENCES
Teams could develop, test, deploy, and evolve modules independently while
participating in a common application experience.
02
A PLATFORM THAT STOPPED EXPOSING THE ORGANIZATION CHART
Navigation and workflows could follow user mental models and journeys rather than
internal team boundaries. The customer experienced one platform composed of
capabilities, not a collection of departmental applications.
03
REUSE BECAME ARCHITECTURAL RATHER THAN OPPORTUNISTIC
The organization could reuse progressively larger building blocks: tokens → components
→ patterns → capabilities → modules. Teams no longer rebuilt common functionality
simply because it appeared inside a different workflow.
[ADD VERIFIED METRICS — e.g. release cadence per team, duplicated capabilities retired,
time-to-integrate a new module, accessibility conformance]
10 / THE BROADER LESSON
A platform is not created by adopting micro-frontends or publishing a component
library.
Those are enabling technologies. A successful platform requires alignment across six
architectures — each answering a different question about the same product. Together
they created a model in which teams could move independently without pulling the product
in different directions.
EXPERIENCE ARCHITECTURE
Defines what the product should feel like to the user.
DESIGN SYSTEM
Defines how experiences should behave and appear.
PLATFORM ARCHITECTURE
Defines how independently developed capabilities participate in the ecosystem.
ACCESS ARCHITECTURE
Defines who can discover and use those capabilities.
MODULE ARCHITECTURE
Defines how capabilities can be independently owned, deployed, and reused.
OPERATING MODEL
Defines how autonomous teams collectively evolve the platform.
THE PLATFORM
provided the shared rules, foundations, and destination.
FEATURE TEAMS
provided the specialized capabilities and velocity.
THE UX ARCHITECTURE
connected the two — giving dozens of individual development decisions a common
direction.