The challenge - We talked to 4 designers and ran a small pilot with the demo, and two problems kept coming up. First, the AI made screens quickly, but they didn't look like our product: close-enough components, random spacing, and colors and fonts that weren't from Keystone. Designers had to check and fix every screen, which used up the time AI was supposed to save. And when the AI said it was done, they couldn't tell whether the result met our standards or had just finished running. Second, getting started was hard. Before typing a single prompt, people had to install Trae (an AI code editor), connect Git, and connect Figma, and designers found it hard to get through. On top of that, small, low-risk requests still landed on designers to build from scratch.

What it should be - My goal was for Keystone Studio to be the AI prototyping tool that knows our design standards best, not another general-purpose generator. Since it's the design system's official product, I set a clear quality bar: every prototype is built with Keystone components, and V1 fully supports Keystone Core. The demo was based on Open Design, a powerful open-source tool made for developers, with support for many design systems and output formats. I kept what mattered, generating and previewing prototypes, and removed or tucked away the technical settings and terms designers didn't need, like runtime settings, model keys, and system prompts. It focuses on one design system and one job.

Built-in quality checks - A quality bar only works if you can check it, so I added Design Lint, an automatic quality check. After each page is generated, it finds elements that should have been Keystone components and styles that don't use Keystone tokens, highlights them on the page, and explains what's wrong. "Fix all" only fixes issues with a clear Keystone match and leaves the rest for the designer to decide. In V1, it only checks components and tokens, on purpose: it asks "is this from Keystone?", not "is this the right design choice?". Designers can also select one element and change its tokens in a side panel, or describe a change that applies only to that element. The AI also shows its status at each step, so designers know what "done" actually means.

From prototype to real code - A prototype that only lives behind a link still has to be rebuilt by engineers. In V1, designers use Git the way engineers do: each person works on their own branch and merges their changes, so prototypes end up in the same code base engineers use. For reviews, designers can share a link to a fixed version of the prototype. Reviewers can click through it but can't edit it, and the designer can turn the link off at any time. V1 also helps content designers. They enter a Starling (our internal localization platform) space and project name, and Keystone Studio creates the Starling keys from the text in the prototype. That replaces the screenshots, notes, and spreadsheets they used to put together by hand.

Prioritizing V1 - The goal for V1 was simple: get the core flow working (prompt, generate, edit, share) so people would start using it. Anything that didn't help with that waited, including advanced settings and developer-focused features. Onboarding got the most attention, because that's where the pilot lost people. Keystone Studio now installs the code editor and sets up Git on its own. The Figma MCP connection is optional, so people can skip it and connect later in Settings. The app only stops when it really needs the user, and then it gives step-by-step instructions. Advanced settings are still there for power users, just out of the way. To measure success, I looked at how much rework was left, not just how many people used it: how long it takes to get the first usable preview, how many components aren't from Keystone, how often people edit after generating, and where new users drop off during setup.

What's next - V1 has just launched. In the short term, I want to expand what it can build with: more templates, new Keystone components as the design system grows, and custom components other teams have built on Keystone. I also want better editing tools, and a more advanced quality check that reviews layout and patterns, not just components. Longer term, I want it to be a true end-to-end tool, with output that fits each use case. For example, a prototype made for usability testing could come with built-in tracking and a dashboard that records how people use it, so the team can learn from it and improve the next version.

The takeaway - Acting as PM showed me how much design judgment matters before any design work starts: deciding what to build, what to cut, and what good looks like.

The challenge - PMs were stuck either way. Small requests still had to wait for a designer, and when design was stretched thin, they sat. Big requests were hard to hand off at all, because an interaction inside an existing framework is hard to put into words. Design and engineering felt the same gap from the other side, going back and forth over what was designed versus what could be built. Prompt-to-design tools didn't help. They didn't know our product or follow our standards, so they could generate a screen quickly, just not the right one.

Giving the AI our product - To be useful, AI had to know our product and hold itself to our standards. I started with the product. Working with engineering, I connected Creation Craft to our real front-end code, modules, and design system, instead of generating mock-ups on the side. PMs now make changes inside the real product: they select a real component and describe what to change, rather than explaining an interaction in words. Built on real components, the result is stable, fast, and close to what engineering can ship.

Giving the AI our standards - Connecting the code base told the AI which components exist, but not how our product puts them together, so pages came out built from the right parts but laid out like someone else's product. I turned our Figma pattern library into a skill the AI follows before it lays anything out. It first figures out which of our page patterns the request matches, and checks whether each interaction in it, like a filter or a batch action, already exists somewhere in the product. It keeps the parts every page of that type must keep, fills the flexible ones from the request, and shows each field by what it is: a link, plain text, a tooltip, or "--" when empty. It asks for components by what they do, not by Figma names, which rarely match the code. When no pattern fits, it borrows from the closest one instead of inventing a layout, and flags anything it had to guess for a person to review.

Request  ·  A builder describes a change
        ↓
Match  ·  Find the closest page pattern
        ↓
Structure  ·  Keep what's fixed, fill the rest
        ↓
Content  ·  Show each field by what it is
        ↓
Components  ·  Ask by role, not by name
        ↓
Self-check  ──────→  Flag anything it guessed

For the cases no pattern covers, a harness keeps it from improvising: when it hits a real gap, it stops and asks a person instead of guessing. In one session, the AI built a filter and flagged that our library had no "Clear all" text button. It used the closest variant and asked whether an existing pattern should replace it, and the builder pointed it to the one on the Leads page. AI can move fast, but it shouldn't guess.

Where I drew the line - I left design review out of the first version on purpose. Shipping sooner puts Creation Craft in more people's hands, and adoption and feedback tell us what to build next faster than a plan would. I kept collaboration simple for the same reason: builders can attach references, documents and images for now, and share a project. Members can edit it, while only the owner can delete it or invite others. The cost is that the gate is not in the product yet, so for now the skill carries that weight. Early feedback, mostly verbal and mostly from PMs, has been positive.

What's next - The next version is a closed loop inside Creation Craft with review at its center. A PM builds a prototype, a designer reviews and approves it, and only then does it go to engineering. We'll also design a richer permission system and let builders pull in references from Figma and other tools.

The takeaway - When everyone can build, the line between design, engineering, and PM gets thinner, and design matters even more. AI can't replace taste, so someone still has to hold the quality bar, and that falls to the designer. My job on Creation Craft was to open building up to everyone while keeping that gate in the designer's hands.

The system - I separated three questions the old structure had tangled together: whose portfolio is in view, where revenue was delivered, and what time period matters. Set once, that context carries through the whole page. The most important decision was that attainment always measures the full portfolio of whoever is in scope, whether a sales IC or a leader, even when the view is filtered to one account or region. Filters change what you're looking at, but never what a metric means.

Launch prototype

Answer the core questions - The questions are always the same: How are we doing? Are we on pace? Why? The design answers them from top to bottom. Pace is where revenue alone falls short. Reaching 60% of goal is great in week three and worrying in week eleven, so every attainment bar marks how much of the period has passed, and the trend compares today's run rate with the rate needed to hit the goal. Why is the hard one: a revenue shift rarely has one cause. Users can switch between region, product, business line, and sub-brand, then drill from a Global Account down to its Ad Accounts. The chart and the client list stay in sync, so the answer and its evidence are always on screen together.

The takeaway - On the surface, this is a homepage. Most of the work was deciding which business model the product should reflect: separating whose portfolio you see from where the revenue happens, and making sure no filter can change what a metric means.

The challenge - The process used to run offline. Rules lived in documents, data lived in separate systems, and conflicts surfaced only after decisions were made. Leaders couldn't see the consequences of a transfer, and the regional operations team, rMSO (Regional Monetization Strategy & Operations), had no single view of 60+ teams globally.

But going online was the easy part. Sales leaders wanted speed and freedom; rMSO needed consistent rules, clean data, and fair arbitration. If the rules were too loose, plans would break at execution. If they were too strict, leaders would work around them. So I started with the operating model (who decides what, when, and with what information) and designed the experience around it.

The system - Each decision sits with the people best placed to make it. rMSO sets rules once. Leaders make transfers within them. rMSO settles collisions. A dashboard shows where every team stands. Two principles connect it all. Context travels: a rule becomes a recommendation's reason, then a check on selection, then a flagged conflict. Validation tightens: flexible while leaders explore, strict as execution nears.

One view of the entire operation - rMSO's core question is where the risk is. The dashboard answers it without opening every team. Top metrics size the work; each team row shows its step, status, and deadline. Every number is a way in; conflict counts, for example, link straight to resolution. It's built as the place where work starts, not just a report.

Policy, written once - rMSO defines rules once and applies them across departments. Territory fields appear only when needed, keeping the common case short. I made each rule's name show up as the reason tag on every account it recommends, so leaders see why an account was suggested, not just that it was.

Decisions with consequences in view - Leaders review hundreds of accounts. Instead of a flat search, the flow narrows: recommendations first, quick filters for common strategies, stackable filters for the rest. Each row shows revenue trend and target impact, so the tradeoff is visible before the decision. Recommended and manual picks stay separate, then merge into one summary that runs target, capacity, and exception checks.

When teams want the same account - When teams claim the same account, letting the first or latest request win would hide the disagreement. Instead, competing requests stay side by side until rMSO decides, grouped under the parent company for context. Bulk actions clear routine cases; only moving accounts to a new team requires a reason. Extra steps only show up where the stakes are high.

Impact - The results so far:

•Revenue that had to be moved between teams after the quarter closed fell by nearly 80% in Q4 compared with the Q1–Q3 average, so revenue data is more accurate and there is far less cleanup after each quarter.

•Sales leaders now handle more than 80% of transfers on their own, up from 2.4% in 2025. That cleared the bottleneck at rMSO and made it clear who owns each decision.

•The full process for moving an account between sales teams now runs in one system. Sales leaders reported 77% less time and 82% less work, and rMSO reported 56% less time and 64% less work.

The takeaway - The real design work was deciding where each decision lives and making sure its reasoning reaches the next person. When goals compete, a good experience depends on a clear operating model underneath.

That groundwork is also what makes the system legible to AI. Once every recommendation carries its reason and every decision has a clear owner, the same structure can support agents that draft the plan and surface the tradeoffs, not just tools that display them.