Unified Twilio: designing how teams build together

Overview

As Twilio moved toward a unified platform, its design system needed to support consistent experiences across products. I helped deliver the first wave of reusable patterns and designed the contribution, review, and collaboration workflows that supported the system’s next phase.

One platform a big migration

Twilio had grown through acquisitions into a collection of products with different navigation structures, interaction models, and UX conventions. Bringing those products into a unified platform required shared approaches to the tasks users completed across them.

Engineering proposed building reusable patterns that captured complete user flows. This introduced a new layer above foundations and components: guidance for how elements worked together in experiences such as data tables, filtering, and multistep forms.

The question expanded from how an individual component should behave to how users should complete common tasks across the platform.

Working system

I partnered with the Principal Designer, who focused on executive alignment and high-level strategy across product organizations. My work focused on making that direction actionable.

I led operational work across roadmap planning, documentation strategy, Figma implementation, design reviews, QA, and collaboration with an external agency. I also worked directly with the core engineering team to develop the initial pattern library.

As the project evolved, my responsibility grew to include how teams proposed, refined, reviewed, and published contributions.

Pattern library

We embedded closely with engineering to deliver the first wave of platform patterns in under six months. The initial internal release included approximately 25 patterns, a Figma library, and shared documentation.

That release gave teams a common starting point for recurring platform experiences. It also exposed the next challenge: how to expand contributions while maintaining a coherent system.

Contribution structure

To accelerate delivery, engineers began creating patterns without consistent design involvement. As contributions expanded, quality, accessibility considerations, and opportunities for reuse became uneven across teams.

Reviewing every detail centrally would make the Design Systems team a bottleneck. Giving teams complete autonomy would allow patterns to diverge. I proposed a shared contribution model that made responsibilities explicit across Product Design, Engineering, Product Management, and Design Systems.

The workflow moved through five stages:

1. Pattern proposal: A feature designer brought forward a pattern grounded in a product need.
2. Cross-functional review: Design, Engineering, and Product Management reviewed the proposal.
3. Design Systems refinement: The DS team refined the contribution for consistency and reuse.
4. Documentation and QA: Documentation and quality checks prepared the pattern for publication.
5. Publication: The approved pattern became available through the shared platform.

This gave product teams a defined way to contribute while preserving the DS team’s responsibility for system quality.

The principle was straightforward: the Design Systems team should steward quality while enabling others to build.

Roadmap prioritization

After the initial release, Twilio partnered with an external agency to develop a new visual language, replacing the existing Paste design language.

This added a second organization to the work and introduced another planning challenge. While reviewing the agency’s early work, I noticed that component development was being prioritized independently of the platform’s existing patterns.

I proposed using those patterns to shape the component roadmap:

Existing patterns → required components → prioritized roadmap

Starting with patterns connected the work to concrete product needs. It gave us a basis for deciding which components to develop first and which existing work could inform the new system.

A collaboration system

To support another quarter of agency collaboration, I designed a delivery workflow covering roadmap prioritization, shared planning, Figma branches, review guidelines, feedback conventions, QA expectations, and asynchronous approvals.

The process followed a consistent sequence:

Roadmap → refinement → agency builds → DS review → iteration → approval → merge

I clarified where work happened, how feedback was recorded, which quality criteria needed to be met, and who approved changes.

Figma branches provided a shared structure for developing and reviewing contributions. Comment threads captured feedback and decisions, while QA expectations established what needed to be resolved before work could merge.

These practices made collaboration more predictable across the internal team and external partner.

Results

The project delivered both a pattern library and the processes needed to keep developing it:

• Approximately 25 initial platform patterns, delivered in under six months.
• A shared Figma library and documentation framework.
• A contribution model with defined cross-functional responsibilities.
• Repeatable design review and QA practices.
• An agency delivery workflow.
• A component prioritization approach grounded in existing patterns.

Together, these changes clarified how teams could contribute, how decisions were made, and how work moved toward publication. The system evolved from individually owned contributions and ad hoc reviews toward shared governance and a repeatable process.

What I learned

This project changed how I think about design systems. Reusable UI depends on the decisions and working relationships around it: who can contribute, how feedback is resolved, and how teams agree that something is ready.

My most consequential contribution was designing that operating model. It created a clearer path for product teams, engineers, and an external agency to build one system together.