User research
When I joined the project, Studio was still in a pre-alpha state with a rough drag-and-drop experience. The target personas and jobs to be done were still unclear, and I had fundamental concerns about the editor’s usability. I initiated a research study to better understand customers’ mental models and evaluate the usability of the core editing experience.
Jobs to be done
My PM and I translated the research into a focused set of jobs to be done that captured the underlying goals, motivations, and challenges we heard from customers. This gave the team a shared understanding of the problems that mattered most and became a north star for product decisions.
When I need to create a new marketing experience, I want to use our existing design system and approved components, so I can maintain brand consistency while moving quickly.
When I create experiences for my organization, I want to build and iterate without depending on developers, so I can launch campaigns and updates ASAP.
When I need to create unique digital experiences, I want the freedom to design flexible layouts beyond rigid templates, so I can bring creative ideas to life without being constrained by our current design system components.
When I scale digital experiences across teams, markets, and languages, I want to reuse designs I have created, so I can efficiently manage complexity without rebuilding experiences from scratch.
Editor experience
Usability testing exposed a basic failure: the canvas could not be trusted. Drag-and-drop behaved unpredictably, users lost track of what had changed, and undo was unclear. Some testers deleted entire pages and started over. Routine edits had become guesswork.
Rough coded prototype for early canvas usability testing
“I would probably never touch it again.”
“Is it the thing’s fault or am I stupid?”
“Moving stuff around was the biggest challenge I encountered.”
The findings reshaped our priorities. In close partnership with Product and Engineering, we agreed that the canvas experience needed deeper investment and shifted focus from adding new features to strengthening the editor’s core interactions.
Over the next three months, I worked with the team to redesign the canvas interaction model while Engineering rebuilt the drag-and-drop architecture from the ground up. Follow-up usability testing showed significant improvements in task success and satisfaction, validating the decision.
Design systems research
We initially assumed Studio could integrate directly with a customer’s design system. I led customer research that showed those systems varied widely in structure, maturity, and source of truth. Some lived primarily in Figma, others in Storybook, and many also relied on reusable production components that were never formally codified as part of a design system.
That insight changed our approach. Rather than treating the design system as one monolithic integration, we focused on the coded components themselves as the points of integration, wherever they lived. Through the SDK, developers could expose approved, production-ready building blocks in Studio, giving creative teams flexibility without sacrificing consistency or control.
Continuous improvement validation
Throughout development, we performed customer and partner validation to test the major design decisions behind Studio. We validated the core editor model, drag-and-drop interactions, component workflows, layout controls, and design system integration with the people who would ultimately use and implement the product.
This helped us move quickly without designing in a vacuum. Feedback from customers and partners shaped multiple iterations of the experience, especially around making the editor feel intuitive, predictable, and powerful enough for creative teams while still preserving the structure and control enterprise customers expected. By the time Studio launched, the product had been continuously tested against real workflows.