Repairing trust in Twilio Studio's canvas
Studio is a visual workflow builder, and the canvas is its primary surface. Developers use Studio to build and manage complex communication flows without writing extensive code.
After an untested canvas redesign broke customer trust, I led design for the recovery, restoring the navigation cues and canvas space customers relied on. Since shipping, negative feedback has dropped 79%.

A redesign removed what people needed most
In early 2026, the Studio team shipped a redesigned canvas. It went out without user testing or a phased rollout, and customers felt it immediately. The redesign had removed what people depended on to navigate large flows. Most noticeably, the color coding disappeared and the working canvas area shrank.
The old canvas stayed available as a fallback, and customers kept using it because the new one didn't meet their needs. Engineering was maintaining two canvases at once, shipping fixes to the new one while the old one stayed live as a safety net.
My PM and I didn't design the new canvas or plan its release, but we did own the recovery.
A chance to prove we were listening
Customers who send detailed, frustrated feedback are often your most invested users, and we were getting a lot of it. That gave us insight into where the new canvas was failing people, and a chance to rebuild trust by acting on what they told us.
Our core goals were to reduce negative feedback and migrate customers to the new canvas. Talking directly with the ones who'd been most vocal was also an opportunity to build longer-term partnerships so we'd discover blockers earlier next time.

The classic canvas

The untested redesign
Consolidating and categorizing the feedback
First, I pulled every piece of customer feedback into one place and tagged it. Out of 19 customers who'd submitted feedback, I identified 58 individual pieces of feedback related to UI and usability.
The most common themes:
Shipping fast fixes
My engineering partners and I identified what we could fix right away:
- Bring back color-coded widgets and connector lines.
- Add the ability to collapse the widget library panel for more real estate.
- Make widget borders and transition lines darker and thicker for improved contrast.
For users managing massive flows, color was how they oriented themselves. Each color marked a widget type, so users could scan a large flow and understand its structure at a glance. Restoring the color was the fastest, highest-leverage fix we could make.
Designing for the bigger problems
While those improvements shipped, I started design explorations for the bigger changes. The canvas needed more real estate, and the configuration panel's narrow input fields were cutting off long strings of text and long variable values. I also revisited two features from the classic canvas: a list of blocking errors, which had been reduced to a generic message in the redesign, and an in-canvas view of revision history, which had been removed during a separate design system migration in favor of a tab that had the same information.
Choosing to slow down and validate
Based on speed, I proposed two paths to the team: ship a direction fast, or take a few more weeks to validate first. Skipping research was what got us here in the first place, so we agreed that extra time was worth it.
The design system was mid-overhaul at the time, and the Figma library hadn't caught up. A static Figma prototype would have tested components that were already being replaced. Instead, I used Claude Code to build interactive prototypes for two canvas options and two configuration panel options.
The canvas options

Inline canvas with expand button

Full-screen canvas by default
The configuration panel options

Expand side panel into a modal

Horizontally expand side panel width
What we heard in research sessions
Our research goal was to test whether people could find the improvements we were making, and ensure we weren't introducing new problems while we were at it.
We tested with 5 internal Twilio users across two group sessions, and 4 customers in individual sessions.
- Most participants preferred the full-screen canvas by default. The product navigation felt irrelevant while they were actively editing a flow, though one participant who regularly cross-referenced other console areas preferred the inline view instead.
- The expandable configuration panel was well-received and highly discoverable. The modal variant got negative feedback because participants preferred to see the canvas while editing widgets.
- The unpublished changes indicator, which contained the draft flow's revision history, was highly valued, especially in environments where multiple people edit the same flow. One participant wanted it placed closer to the publish button.
Prioritizing migration blockers
My PM, engineering partners, and I prioritized the improvements that were actively blocking migration, so those changes shipped first. New requests like drag-and-drop connector management, which didn't exist in the classic canvas at all, went into a dedicated backlog as net-new work.
Once the highest-priority changes shipped, we began folding in quality-of-life improvements alongside them.
A refreshed canvas, shaped by customer feedback
The redesigned canvas centers on three key changes, driven directly by what we heard in research.
The canvas opens in full-screen by default, giving complex flows room to breathe without page navigation competing for space.
The configuration panel can be expanded, letting text fields dynamically resize to accommodate long strings of text and long variable values.
The error list and revision history now live in a new left-hand navigation rail, alongside the widget library and a new flow outline panel.
A measurable shift in trust
The team is still shipping improvements as of writing, and customers are already noticing the changes we've made. We're finally on a path to deprecate the legacy canvas for good.
We're also building relationships with the users who know this product deeply, which has started to rebuild the trust the original rollout damaged.
Reflecting on learning fast and rebuilding trust
AI prototyping changed what we could learn
For a canvas-based product, people needed to actually click, drag, and expand things to tell us whether an interaction worked. While a static mockup could show what something looked like, only a working prototype could show what it was like to use in practice.
Trust came back through action
Trust came back because we combined speed with personal follow-through. We shipped fast, high-impact fixes and followed that up by getting on calls with the customers who'd been most vocal about what wasn't working.



