Organizational infrastructure for delivery at scale across two brands. A unified Design System serving two brands, 11 designers, and 15 squads positioned not as a visual toolkit, but as organizational capital that reduced marginal delivery cost and made execution at scale structurally predictable.
The initiative operated across 11 designers and 15 squads, serving a financial and retail ecosystem spanning App, Store and PDV, Web, WhatsApp, and Backoffice. Neither Midway nor Riachuelo had unified design infrastructure. Each squad maintained its own component library. Design and engineering operated from different sources of truth. Inconsistency accumulated at every delivery cycle as rework, misalignment, and lost time to market.
The Design System was the structural response to an organizational risk not a craft investment. Its return was measured in headcount equivalent, delivery throughput, and code time reduction. Built, governed, and adopted as infrastructure not tooling.
Fragmentation at the component level is a symptom of a deeper organizational failure: design and engineering operating as parallel systems rather than an integrated function. At Midway and Riachuelo, this manifested across every dimension of delivery with compounding cost at each layer.
The case for a Design System is economic, not aesthetic. Fragmented infrastructure generates costs that accumulate invisibly across every sprint: rework, misalignment, delayed time to market, and the human capital required to compensate for systemic inefficiency.
"Every component rebuilt is a cost that does not appear on any invoice. It compounds across 15 squads, every two weeks, across multiple years."
Economic framing · Design System · 2023These costs do not plateau. As squad count grows and channel surface expands, fragmented infrastructure becomes progressively more expensive to maintain. The Design System was not an investment in quality. It was a risk mitigation decision.
Elevated delivery cycles driven by component rebuilding and design and engineering realignment on every sprint. Competitive window shrinking with each avoidable delay.
Organizations compensate for systemic inefficiency by adding headcount. Without shared infrastructure, growth required proportional team expansion an avoidable capital allocation.
Redundant code bases across channels increased maintenance burden, elevated regression risk, and created technical surface without proportional value.
Inconsistent interfaces across channels elevated contact rate. Users encountering different patterns across the same product generated avoidable support volume and eroded confidence.
The strategic decision was a reframing of the function's mandate. Rather than managing a backlog of component requests, I structured a formal internal RFP process, establishing the Design System as an organizational initiative with executive sponsorship, shared ownership across product, engineering and design, and a measurable business case. This shifted governance from reactive to architectural.
Formalized the investment case with estimated saving, capacity gain, and risk reduction modeled before any design work began. Secured executive sponsorship from the Director of Financial Products by framing the system as a capital efficiency decision not a craft initiative.
Structured the system to serve both the fintech and retail brands from a shared foundation. Token architecture enabled brand differentiation at the surface while the structural layer remained unified. One system, two expressions.
Established a weekly Design System committee with representation from design, engineering, and product. Created formal RACI documentation. Set mandatory adoption metrics per squad tracked on the public roadmap. Governance was institutionalized, not negotiated sprint by sprint.
The Design System was not a Figma library. It was a four-layer organizational infrastructure connecting design decisions to engineering output, governed by formal process, and measured by economic outcome. Each layer was sequenced with the adoption curve in mind: foundation first, then code integration, then governance, then scale.
All metrics are masked and based on internal measurement models; figures reflect early adoption or projected full adoption scenarios.
Implementing a governance model into an organization that had operated without one generates structural resistance. The conflicts below were organizational, not interpersonal. Each required a decision that prioritized long term system health over short term convenience. Each was made explicitly and documented.
Product managers and squad leads framed DS adoption requirements as bureaucratic overhead that slowed squad velocity. The argument was consistently that "we don't have time to wait for the system," using sprint urgency as justification for continuing local component creation.
Held the governance requirement. The counter-argument was made in economic terms: the cost of one sprint's delay to adopt a DS component is smaller than the compounding cost of maintaining a divergent component across two years and 15 squads. The adoption threshold was not negotiated down. Exceptions required documented justification reviewed by the DS Committee.
Early DS governance was centralized by necessity: standards were new, adoption was partial, and quality variance was high. As the system matured, squads expected greater autonomy. The transition created a governance ambiguity window that individual squads attempted to exploit by reintroducing local standards.
Designed the federated model explicitly rather than allowing it to emerge by default. Contribution rights were earned through demonstrated adoption compliance. Squads with consistent DS adherence gained contribution privileges; those with variance remained in a governed consumption model. Federation was a capability status, not a default entitlement.
As the DS function grew in organizational visibility, pressure emerged to assign DS designers to product management responsibilities within the squads they served: backlog ownership, stakeholder management, sprint facilitation. The rationale was context. The effect was designers performing dual roles at reduced quality in both.
Formally declined and documented the boundary in RACI. DS designers were responsible for system quality, contribution governance, and squad enablement not product ownership. The boundary was enforced as a capacity protection decision with direct impact on DS delivery quality. Clarity of role enabled higher output in both functions.
The most durable outcome of the Design System was not the component library. It was the organizational behavior change it enforced. A system with governance produces a different decision culture than one without.
The Design System built at Midway is a foundation, not a destination. The 2026 trajectory connects infrastructure maturity to the next phase of organizational growth.
The component to code integration via AI represents the first layer of an AI augmented delivery model. At full maturity, the Design System becomes the constraint layer for AI assisted design and engineering, compressing delivery cycles further without proportional headcount increase. The infrastructure built today is the precondition for AI leverage tomorrow.
Full adoption across all 15 squads and both brands unlocks the full saving curve modeled at project initiation. At that threshold, the Design System moves from a governance project to an organizational capability embedded in how the company ships product, not a parallel process managed by the UX function.
The Design System is the foundation for a broader organizational claim: that UX is not a support function but a structural capability that determines the organization's capacity to grow and to operate efficiently at scale. The transition is complete when the system outlives the individuals who built it and accelerates the work of those who inherit it.
The following materials are available on request. They have been redacted or abstracted here to protect confidential operational data.