Introduction
Overview of the Project
At Meta I led the redesign of a critical Build/Test/Deployment CICD tool called Conveyor, used by engineers to track Build and Release activity within the platform. The goal was to merge two fragmented workflows in Conveyor (Build and Ship); into a unified view to improve traceability, decision-making, and overall reliability. A secondary goal to supplement this effort towards de-fragmentation was to adapt the quick-fix "Hotfix" flow from existing in a CLI (Command Line interface) format to something more UI-centric.
At Meta I led the redesign of a critical Build/Test/Deployment CICD tool called Conveyor, used by engineers to track Build and Release activity within the platform. The goal was to merge two fragmented workflows in Conveyor (Build and Ship); into a unified view to improve traceability, decision-making, and overall reliability. A secondary goal to supplement this effort towards de-fragmentation was to adapt the quick-fix "Hotfix" flow from existing in a CLI (Command Line interface) format to something more UI-centric.
My Role
As the Product Designer embedded in Infra, I drove the UX strategy, scoped technical feasibility with engineers, mapped out complex system dependencies, and crafted scalable design solutions to handle edge cases.
As the Product Designer embedded in Infra, I drove the UX strategy, scoped technical feasibility with engineers, mapped out complex system dependencies, and crafted scalable design solutions to handle edge cases.
Background
Client and Product
Meta’s Infra organization manages the deployment of thousands of daily changes across services. Conveyor is an internal tool that helps engineers assess the safety of their changes in a continuous integration and deployment cycle; before pushing to production.
Meta’s Infra organization manages the deployment of thousands of daily changes across services. Conveyor is an internal tool that helps engineers assess the safety of their changes in a continuous integration and deployment cycle; before pushing to production.
Company Context
Meta’s scale and reliability goals require high levels of visibility into deployment activity. Conveyor is part of Meta’s broader investment in reducing engineering toil and avoiding regressions by improving continuous automation.
Meta’s scale and reliability goals require high levels of visibility into deployment activity. Conveyor is part of Meta’s broader investment in reducing engineering toil and avoiding regressions by improving continuous automation.
Problem Statement
User Problem
Engineers had to navigate two separate pages in the Conveyor tool (Build and Ship) to understand the full lifecycle of a change from creation to final deployment in Production. This made it difficult to reason about what had shipped, what was still "building", and how changes propagated across multiple pipelines.
Engineers had to navigate two separate pages in the Conveyor tool (Build and Ship) to understand the full lifecycle of a change from creation to final deployment in Production. This made it difficult to reason about what had shipped, what was still "building", and how changes propagated across multiple pipelines.
Current State of Things:
Challenge
While merging these views promised clarity, it surfaced several challenges:
Technical performance: the existing Build and Ship pages already took 60+ seconds to load.
Data model complexity: Builds may result in 0, 1, or multiple Releases.
UX Ambiguity: some Builds are reused, patched after the fact, or contained an emergency Hotfix; complicating how to sort and display them.
Process
Research
I partnered with PMs and Engineers to gather historical usage patterns, support tickets, and internal feedback. We reviewed logs, examined Build/Release ratios, and ran user interviews to understand how Engineers traced the Build-to-Release path in real workflows.
I partnered with PMs and Engineers to gather historical usage patterns, support tickets, and internal feedback. We reviewed logs, examined Build/Release ratios, and ran user interviews to understand how Engineers traced the Build-to-Release path in real workflows.
User Research conducted with 13 participants revealed:
“There’s little understanding in how the features are related to each other”
“Conveyor is one long process chopped into two parts: editing (Pre-Landing a change) and BTD flows (Post-Landing a change). Ideally it would be one long process: Editing to BTD.”
“Fragmented Experience: Different and/or separated features in separate sections can trigger a Release, but all of them lead to the same result - a Release.”
"..there's a disconnect between Build and Ship. If people are looking at Ship they’re like 'why hasn't anything shipped in a while' ".
A card sorting activity revealed an information architecture imbalance leading to fragmentation in the BTD flow.
Design Process
Exploration: Created wireframes to model different table structures, sort patterns, and interaction flows for the Build and Ship merge; and additional whiteboarding discovery on the Hotfix feature design.
Design Process
Deep-Dive for the Deployment journey: Documented two simplified workflows to understand user motivations and path of engagement.
Validation: Used internal critiques and stakeholder walkthroughs to test feasibility.
Iteration: Broke the proposed design into phased milestones to address performance blockers like load time.
Design Tools and Methodologies
Figma (wireframing, prototypes), Miro (mapping release pipelines and scenarios), Design Critique and Heuristic Evaluations, async Request-For-Comment reviews via internal chats, and alignment with Meta’s internal design library (XDS).
Figma (wireframing, prototypes), Miro (mapping release pipelines and scenarios), Design Critique and Heuristic Evaluations, async Request-For-Comment reviews via internal chats, and alignment with Meta’s internal design library (XDS).
Design Solution: Build and Ship merged
Proposed a unified Builds + Releases History Table that shows the end-to-end journey from code creation to Production.
Designed conditional logic to display Builds with no Releases, ongoing Builds, and legacy patching events like the Hotfix feature.
Recommended a phased Engineering approach where we address performance issues first and then create the merged interface.
Design Decisions
Chose to sort by Build creation time but flag new Releases using older Builds with priority indicators.
Modeled the table to group Build ID and Release ID in a single column header for clarity.
Prioritized de-risking: avoided shipping the merged view to prioritize fixing existing performance bottlenecks.
Design Solution: Release Details (visual refresh)
Current State (below):
Current State: User complained of a "busy" interface and are contextually lost while switching between Steps. They also desired a method of being able to see more in one view so that they could compare and contrast progress of the deployment across all Steps.
Updated State: The navigation was collapsed, so that the center area exposing more details had room to breath contextually. Users were also able to explore through the "tree view" to compare and contrast activities in each Node to see the status of their deployment and judge methods of intervention.
Design Solution: Hotfix
New feature flow (below):
Conclusion
Outcomes and impact
The redesigned Conveyor pacing interface improved onboarding, reduced user toil, and increased service adoption. By consolidating fragmented workflows, the UI now supports 5+ Domains, surfaces deployment stages, and aligns with users' mental models—enabling clear, end-to-end visibility.
Key results:
Enabled onboarding of 16 new Ad-related Services and improved Stream Processing by 80%.
Reduced support tickets for the Conveyor Oncall team and increased self-service efficiency.
Strengthened alignment with Infra's broader reliability goals.
Fostered inclusion and collaboration through open UXR sessions, design talks, and the creation of a Service Migration Badge for Conveyor users to proudly display as they integrated more with the tool. These efforts helped validate design directions and build cross-functional trust.
Key learnings
In infrastructure design, progress is built on clarity, iteration, and strong cross-functional relationships. Phased improvements grounded in real feedback deliver impact that scales.