From branded moments to a connected system
Spotify’s design systems team has long operated with a clear mission: make it easy for product teams to build cohesive experiences. But for Design Manager Juli Sombat, the real shift came when the team stopped thinking in terms of individual platforms and started thinking in terms of the entire product ecosystem.
The catalyst was a familiar one—fragmentation. As Spotify grew across web, mobile, desktop, and beyond, teams were solving similar problems in slightly different ways. Components existed in silos, and while each feature might have felt polished on its own, the cumulative experience across surfaces started to feel less coherent. Sombat’s team recognized that real cohesion couldn't be achieved by designing for each platform separately; it required a system that could serve all of them at once.
A single source with room to adapt
The team redesigned its approach around a core principle: one shared source of truth for components, with built-in flexibility for platform-specific behavior. Instead of duplicating logic for Android, iOS, and web, the system defines components once and allows each platform to handle the details where it matters—like gesture support or navigation patterns.
That's not to say every component is identical everywhere. There are intentional variations. But the underlying system, the tokens, the accessibility considerations, and the interaction patterns are all shared. The goal is that a user moving from the mobile app to the desktop app to the web player feels like they're in the same product, not a collection of related products.
Design systems as a product
Sombat emphasizes that the design systems team operates less like an internal services group and more like a product team—with its own backlog, roadmap, and users. The "users" are Spotify's own designers and engineers, and the system is the interface they work with daily.
This product mindset changes how decisions get made. Requests are prioritized based on impact across the portfolio, not just on whichever team asks the loudest. Contributions from product teams are welcomed, but governance stays central so that the whole system doesn't drift off in conflicting directions. It's a deliberate effort to balance velocity and coherence at scale.
<Aside><p>"A design system isn't about enabling speed for individual teams at the cost of cohesion; it's about ensuring that we can be fast together."</p></Aside>
Lessons for teams starting the journey
For teams building their own systems, Sombat offers a few practical takeaways. First, start with outcomes rather than components—ask what kind of consistency you actually need before you start designing buttons. Second, treat platform differences as features, not bugs; a system that forces everything into the same mold will fight against the strengths of each platform. Finally, invest in relationships; a design system only works when the people building with it understand it and feel ownership over it.
The underlying message is that a design system isn't a deliverable—it's a discipline. For Spotify, that discipline is about making sure that no matter where you listen, the experience still sounds like Spotify.
Designing for Every Screen
When Spotify's leadership set out in 2019 to make audio available on any device, the design team faced a challenge that went far beyond a simple responsive layout. The target was 45 unique platforms and over 2,000 device types across 200 brands. A listener might start a playlist on a living-room TV, continue in the car, and finish on a work computer. The goal was to make that experience feel like one continuous thread, not a series of disconnected apps.
The team's focus became defining what makes something inherently "Spotify," regardless of the medium. The design system, Encore, is the tool for that job, and its evolution from a loose collection of assets to a unified system offers a useful case study in how to structure a cross-platform design practice.
Two Systems Become One
When Encore launched in 2019, it was split into two distinct segments. Encore Consumer Mobile was a vast, flexible catalog for mobile experiences, while Encore Web served a broad range of web products. Design tokens governed foundational choices like color and type, but the two subsystems were largely independent. The button component, for instance, looked and behaved differently on each.
By 2022, that flexibility had become a burden. Product teams wanted more refined components out of the box, and the absence of commonality meant reinventing interaction patterns for each surface. The team assembled a specialized group responsible for reusable components for Encore Mobile, positioning it as a bridge between the core foundation and the more specialized Encore Consumer Mobile layer. Instead of treating web and mobile as separate concerns, they began developing cross-platform components from the start, with platform parity as a first-class requirement rather than an afterthought.
The Component Outline
Designing for multiple platforms at once requires a different process than designing for one. The production pipeline was the same—research and design leading into development—but the research phase changed. The shift was away from designing only for web or only for mobile and toward a synchronized effort.
The work begins with everyone in the room. Teams from iOS, Android, and Web each audit a component to understand what's truly unique to their surface. Desktop offers more real estate; TV demands consideration of viewing distance; Watch requires tight information density. Each representative diagrams those specifics, and then the group shares context on naming conventions, accessibility requirements, and platform limitations. The output is a component's outline: a shared document capturing the anatomy, glossary of terms, and supported variants that lays the foundation for detailed design.
A concrete example is the unassuming button. Early in Encore's life, buttons varied wildly across platforms, using different size frameworks, padding, interactions, and increments in the type scale. Cross-platform collaboration produced a unified hierarchy—primary, secondary, and tertiary—and a size framework and naming structure that persists today. Team members implemented this with variables, generated and updated via the REST API when changes hit the source code of truth.
This middle path between total independence and rigid consistency is rare. Many design systems are platform-agnostic, applying a single pattern everywhere. Others, like IBM's Carbon, optimize for one primary platform (in that case, the web) and treat other surfaces as less critical. A system built on parity, where all platforms are first-class citizens, was the model Spotify aimed for.
The Benefits of a Shared Core
The pursuit of cohesion surfaces several concrete advantages beyond the philosophical ideal of unity:
- Cohesion: A common foundation guarantees a shared Spotify essence; nuances exist but the core experience doesn't fracture.
- Efficiency: Platform teams start from a working baseline and customize for unique requirements rather than breaking new ground each time.
- Scalability: Updating a global pattern, like a new brand color or interaction guideline, ripples outward from the cross-platform core to all subsystems.
What Gets Harder
Managing multiple platforms in tandem creates its own set of complications.
Project complexity grows. There are more requirements and limitations to track. Encore's job is to absorb that painful coordination on behalf of product teams. The practical mitigation is giving each component a single project lead, who pulls in engineering and design partners with the relevant platform expertise.
Dependencies multiply. Release schedules, roadmaps, and timing rarely align across teams, making coordination difficult. Limiting the count of active projects and emphasizing proactive internal communication keeps those issues manageable.
Those problems are real but minor compared with the user-facing clarity the approach delivers.
Cross-Functional, Not Just Cross-Platform
A system that spans platforms is only half the equation; it must also span internal functions. Spotify's process treats cross-functional collaboration as intentional, not inevitable. Regular sync-ups, structured brainstorming, and feedback loops replaced siloed work with cross-team conversations. Moving from the question of what to build to how to talk about it, teams align naming and anatomy together, making those discussions central to the design's evolution.
The result is a feedback loop: The seamless experience is not just the product of consistent design, but of countless hours of teamwork where each discipline respects the others' constraints. Unity in design and diversity in thought was the operating principle.
Unity is invaluable. The open question for other teams is what is non-negotiable in your own design. Defining that list of non-negotiables yields consistency and pushes creative boundaries. For Encore, that means an expansion of cross-platform components is on the roadmap, as is building out the contribution process to make its lessons available to a wider audience.
