What We Found

The cow tools problem.

A Far Side cartoon shows a cow displaying a set of tools it made. They're bizarre and useless — because a cow has no idea what a human actually needs. The joke is that the maker and the user are so misaligned that the output is incomprehensible. That was AI Workbench. The platform was built by engineers who understood the infrastructure deeply, but hadn't sufficiently understood how the people using it actually worked — what they were trying to accomplish, where they got stuck, what "done" looked like to them. The result was a set of tools that made sense from the inside but baffled people on the outside.

I discovered that over 90% of churned users were hands-on engineers and AI/ML scientists, unlike the main assumption that our metrics were underperforming due to non-technical users abandoning our technically geared product. One more cut mattered: 71% of respondents were mid-career, meaning that they already know their trade, they have strong tool preferences, and expect quick ROI inside a sprint, not sometime in the future. These users were workers in the middle of working on a deliverable, with tight timelines and high expectations. When that group comments that a tool is "hard to understand," they usually don't mean they can't figure out what it's for; they mean it didn't justify the time it took to figure out.

The people churning were exactly who the platform was for — ~90% technical, 71% mid-career. Not the wrong audience.

With the audience fit ruled out, the tempting conclusion was a usability problem: the UI is confusing, the docs are thin, let's clean it up. But before accepting that conclusion, I wanted to dive deeper into what our churned users were saying.

First: This bucket is the largest driver of drop-off from our users with 10 mentions from burst and lapsed users, and describes the same underlying sentiment: the value proposition was not strong or clear enough immediately to justify continued use.

This response from a user stood out to me the most. Here was a capable engineer, asking us to just show them the point of our product. Every version of the drop-off traces back to that one unanswered question.

Second: This issue caused dropoff even before the users can reach value: Without an easy way to learn more about the product and its value, users did not return to the product after their initial evaluation of the features. In some cases, this lack of clarity made external tools with more discoverable documentation and learning resources a more attractive alternative.

These two points together reveal that the real problem is not technical capability or user sophistication. Value clarity was the root cause; the docs and usability friction only amplified it. Better external tools weren't the main reason people left; they were the default people fell back to once AI development platform's value wasn't immediately apparent, especially for newer Intuit employees.

Interestingly, one group didn't fit the pattern at all: our power users. They complained about the same friction the churned users did — same clunky setup, missing docs, and the steep curve. Yet, they stayed. So the question stopped being "why is the product hard?" and became "why did the same friction end some users and not others?"

The Forensic

What the power users actually had.

I worked backward through it. If the survivors weren't spared the friction, something else explained why they pushed through. I took the three obvious candidates and tested each against the data.

• Was it time? No. We had 8-year veterans who churned and 1-to-3-year newcomers who became power users. Time buys tolerance for friction, but it doesn't create commitment.
• Was it adopting before other tools existed? Early power users had fewer external AI tools to compare against, and were forced to experiment internally. However, the power users still complain about UX and friction. They stay because the value is clear, not because there are no alternatives. So external tools raise the bar, but they don’t explain why power users stayed.
• Was it hands-on help — workshops, live demos, someone walking them through the first build? Surprisingly, yes! These support systems not only made the value clear, but also showed a successful path. A good demo is worth a thousand words — the users didn’t have to guess how to get started, and they were able to see the end-to-end success that reduced their early cognitive load that would have come with interpreting docs and reverse-engineering workflows. All these address the two biggest challenges.

The Insight

The product was quietly depending on human hand-holding to work at all.

Power users didn't win out on patience or talent. They persisted because a human held their hand across the exact gap where everyone else fell in. This showed that the white-glove support wasn't a nice-to-have this supposed "self-serve" tool; it was absolutely necessary to guarantee quick time-to-first-value.

This quote may seem like a cheesy success story at a glance, but it demonstrates that the user made it because they were willing to reach out to support and stick through. Most users not only do not owe us that patience, but also ended up churning simply because they couldn't stick through with a tool that did not seem like a quick value add to their workflow.

The team's first instinct was the obvious one: if people are getting stuck, write a more thorough documentation and guidebook. But the responses from our users had already ruled that out. The users who struggled most weren't the ones without docs; they were the ones reading them.

Realistically, more docs wouldn't have helped this user. The problem with documentation is that it drifts as the tool changes weekly. Even when it's current, it's written by the engineers who built the feature, describing what they made rather than what a user needs to do to get value out of it. It's the cow tools problem again, one layer down: the docs made sense from the inside and baffled everyone outside. You can't write your way out of a guidance problem with more of the same baffling guidance.

The other one-dimensional solution might be “We should just do more training. ” This is not a scalable solution, unfortunately, as there will never be enough support engineers to personally walk every AI Builders at Intuit to their first win.

So the new direction wasn't "write better docs" or "run more workshops." It was: take the one thing the white-glove treatment did: guide someone to a working result before they give up, and encode it into the product experience itself, so every user gets that guided first run, not just the ones who happened to get a person.

After the research, I decided to go through the process myself.

During a hackathon week, I tried to build an agent from scratch. I'm a former software engineer, I'd worked on the agent starter kit, I knew the platform. I assumed it would be straightforward.

It wasn't. I cloned the wrong repo. The documentation sent me to three different surfaces in the wrong order. I spent time manually copying values between systems that clearly already knew about each other. I had to download a third-party API client just to send a test request. I dug through Slack to find workarounds other people had written. After a few hours of this, I was able to send a simple prompt, but that was about it.

If I couldn't get through it with all that context and documentation, the problem wasn't that users needed better documentation or a friendlier UI. The assumption that this whole workflow had to happen across multiple disconnected websites was the problem.

The Reframe

What if developers never had to leave their terminal?

This ties to the problem of value proposition: if users had to jump through multiple documentation and tools to connect all the moving parts to simply send a prompt to the agent and get a response, they're going to abandon the poorly paved path and look for a better road. But even a well-executed version of the same approach would still require developers to leave their natural environment to configure things back and forth in a browser and an IDE.

As a former engineer, I also recognized the solution pattern. Developers work with their terminals, IDE, and now AI coding assistants. That's where they're fast and in context. Tools like create-react-app exist to collapse complex setup into a single command so developers can skip the scaffolding and get to the actual work. There was no reason agent development at Intuit couldn't follow the same model.

I pitched the idea of building the workflow as a plugin for AI coding assistants rather than a new surface — where a developer types "I want to build an agent" into Claude, and Claude handles the entire setup: service registration, IDPS configuration, starter kit scaffolding, skills installation, prompt loading, local testing, evals, to submitting their first PR. No context switching and digging around for the right documentation or Slack anecdotes!

The Prototype

Claude Code simulator to communicate the process

To make the idea concrete, I built a coded prototype that simulates what the experience looks like in a terminal using Claude Code (to build something that looks and behaves like Claude...! Whoa!). The reason was simple: seeing the flow was much easier to understand than explaining the idea to engineers. They immediately knew what I was talking about because they've done something like this before in their day-to-day. I met where the devs were to communicate the direction, so that we can meet our users where they were.

I recorded a walkthrough through the full flow: prerequisite detection, environment scaffolding, skills discovery via natural language, prompt loading, local testing with trace output, and quick evals against Langfuse data.

Validation

I took the walkthrough back to the people the research was about.

Before pitching it internally, I shared the walkthrough with actual developers — the same population whose churn started this whole investigation. The point was to check the fix against the problem: if these were the people who'd bounced off the old setup, did the new flow actually land?

It did, and pointedly on the exact thing the research had flagged. One developer's first reaction was to ask whether it set the agent up "as if done on a paved path" — the paved-vs-gravel path distinction that had surfaced verbatim in the survey comments. When I confirmed it did, the response was immediate:

Others compared it straight against the status quo — "this looks much better than the current state, the flow feels smoother" — and one reviewed it in detail, called it "clear flow and easy to follow," then started listing what he'd want next. That last part mattered most: people don't invest effort extending something they don't believe in. The fix wasn't just tolerable, it was something they wanted to build on. That's the validation I brought to the team, and this prototype became the spec; the PM wrote the PRD from it, and with everyone on the same page, the team was able to ship the workflow as Day-0 Agent Setup.

The Outcome

From prototype to a shipped plugin.

The workflow shipped as Day-0 Agent Setup and now live in the Intuit Developer Plugin Registry. It handles the numerous steps in the massive diagram so engineers can go from zero to a running agent without manual cross-tool wiring.

Executive Summary

Two tools, 10,000+ users, one fractured experience.

At Intuit, prompt engineering is at the heart of building generative AI capabilities. But our tooling was deeply fractured: developers were forced to create rigid project containers in the AI Hub just to test a prompt, while 10,000+ monthly users relied on a separate legacy internal tool with a competing prompt feature.

I led the evolution of Prompt Playground from a nested tool into a global platform experience. By conducting a systematic UX audit of both tools, uncovering deep user friction, and building an interactive React prototype, I reconciled GenStudio's instant simplicity with Prompt Playground's advanced engineering power — doubling adoption and delivering a unified source of truth for prompt engineering.

After V1 shipped, I stepped back and identified a major platform issue: the legacy tool had 10,000+ monthly active users, 42% of them on its legacy "Prompt Design" feature. Two tools were solving the same problem with no coordination. Before bringing Playground to the global level, I ran a deep UI/UX audit to understand why users clung to GenStudio despite AIW's newer features.

Deep Qualitative Insights

What real builders said.

Beyond the survey, qualitative FMH interviews with top builders revealed critical platform gaps the numbers alone couldn't explain.

• Senior agent SWE. Ditched internal tools entirely — his prompt architectures were tied to external execution tools that neither product supported.
• Credit Karma prompt engineering team. Lost three weeks of work to a session-history bug and an unannounced default backend system prompt — forcing them to third-party tools (e.g. Dify) to chain multi-agent flows.

Rather than force a lift-and-shift, I designed a unified Global Prompt Playground that combined GenStudio's rapid zero-state drafting with Playground's advanced engineering controls — one surface serving both audiences.

Core Design Solutions

• Progressive disclosure layout. The primary view opens with a clean, un-cluttered prompt editor and instant output stream. Parameter sliders (temperature, top-p), Knowledge Bases (RAG), and model selectors sit in expandable panels.
• 3-way side-by-side diff inspector. Builders drag-and-drop up to three revisions side by side, visually highlighting text diffs, parameter shifts, and token counts.
• Modular prompt construction. Message blocks with explicit roles (System, User, Assistant, Tool), supporting dynamic variable inserts and reusable prompt segments.
• Session vs. registry architecture. Unlinked drafting from permanent code. Unsaved sessions persist for 30 days for low-stakes drafting, with a clear "Publish to Registry" flow to bind production-ready prompts to GenOS Use Cases.

Prototyping Approach

A real link, not a static Figma flow.

Because generative AI outputs are dynamic and non-deterministic, static Figma clickthroughs couldn't capture real iteration patterns. I built a fully interactive React prototype hosted on internal GitHub Pages and shared the live link during FMH sessions — users typed real prompts, manipulated parameters, and evaluated multi-column diffs. Feedback reflected real iteration patterns, not reactions to a happy path. I then translated those validated patterns back into our core design system components.

The Global Playground vision and architecture were presented at Intuit's AI Share Out & Architecture forum with leadership present, and across org-wide Pre-GED workshops.

Delivering It in Cycles

From a validated prototype to a shippable plan.

The prototype told us what worked — but it was one dense surface, and we had two engineering teams and a live user base to protect. So I broke the validated feature set into an MVP / Target State / Nice-to-Have matrix and mapped it to phased releases. This gave PM and engineering a shared language for prioritization, kept scope from ballooning before launch, and let the team ship the Global Playground in cycles rather than one risky big-bang release. Key MVP features shipped in December '24; all three phased releases are now live.

The Problem

A strong foundation, but not built for dense platform workflows.

Intuit already had a mature, company-wide design system (IDS) supporting hundreds of designers and thousands of developers across flagship products like TurboTax, QuickBooks, and Mailchimp.

But our team worked in a more technical domain: interfaces that had to handle dense data, complex configuration, multiple statuses, and layered information beyond what standard product patterns were designed for.

As a result, four product teams were each reinventing the same components — designers rebuilding them in Figma, developers hand-wiring approximations in code — and critiques kept getting stuck on component-level decisions instead of the user flow.

We didn't need to replace IDS. We needed a specialized layer that extended it for the realities of our platform — and every extension came from a real workflow need, not a bigger library for its own sake:

• Higher-priority and inline-icon badge states, so status could be scanned at a glance in data-heavy views.
• A menu that supported search, grouping, and nested actions, because our workflows had more to configure than a simple dropdown could hold.
• Density, multi-status, and configuration patterns that reflected how our platform actually worked — not decorative variants.

My Role: Turning Patterns Into Infrastructure

Standardizing fractured experiences

I started by turning repeated patterns into reusable Figma components, documenting when to use them, and bringing those standards into design critiques. Over time, critiques became less about reinventing patterns and more about aligning on shared decisions: which component to use, what states it needed, and whether a new pattern belonged in the system.

Because I came from a development background, I also contributed directly to the coded library. Engineering support was limited and volunteer-based, so I used my front-end skills and AI-assisted workflows to move components from Figma specs into working React components faster — while preserving the details teams depended on, including density, status states, configuration, and edge cases.

I also helped create the operating model around the system: monthly meetings with developers across platform teams, an open channel for bugs and requests, and a triage process for prioritizing what to build next. The system became maintainable because there was a clear way to request, discuss, build, and improve components.

Spotlight: The Search Result Row

Three products, three inconsistent search surfaces, one shared component.

Search looked completely different in every product — and every version was broken in its own way. One crammed everything in at high density with inconsistent spacing. Another wasted space, repeated the same labels row after row, put related information far apart, and had no ownership info at all — you couldn't tell which team or project a result belonged to. A third was so barebones it surfaced almost nothing useful while still eating up the whole result area. The challenge was determining whether three seemingly different surfaces were actually variations of the same underlying pattern.

The Synthesis

Find what's common — then find what should have been common.

I pulled apart all three surfaces and mapped the shared anatomy: a search input, category chips or tabs to divide results, the results area itself (table, card, or list), and inside each result — an icon, name, description, tags or badges, and a checklist filter. Some of these existed everywhere; some didn't exist anywhere but clearly should have (ownership was the big one). Naming that gap was half the work.

Then I set the principles the component had to hold to: a max-width bound of 1280px, grouping related information closer together, and reducing redundant and low-density info sprawl. Everything after that was iteration against those rules and against real team feedback.

The Guidelines

The component is only half of it — the rules for using it are the other half.

A flexible component with no guardrails just recreates the original problem in a new place. So alongside the component, I wrote UX guidelines based on product audits, cross-team feedback, and the devisions that shaped each iteration. The goal was to help teams understand not just what they could toggle, but what they should use and why.

From Figma to Shipped

I didn't hand off the spec — I coded it and put it in a real product.

A component only counts once it is in someone’s product. So I built the search result row into the design system as a published package, composed from existing system pieces like menus, badges, and icons rather than reinventing them.

It was styled entirely with design tokens, with no hardcoded colors, and shipped with unit tests, snapshots, Storybook stories, and documentation so the next team could adopt it without asking me how it worked.

Building it end to end surfaced things a Figma file never would. A design call — the right-rail actions read cleaner as a single kebab menu than as a split button — was one I could just make in the code. And while wiring it up I traced a two-year-old dependency bug: a stale package version hoisted at the monorepo root was silently overriding the live one, so local changes to a shared component were being ignored across the whole system. Fixing it unblocked more than my own component.

Then I closed the loop: I opened a pull request against one of the products to swap its bespoke search interface over to the shared component, rolled out behind a feature flag as a canary so the team could validate it in production safely. The migration removed more product code than it added — which is the whole point of a design system, made concrete.

Recent Shipping

The system is alive, not a one-time launch.

Over the past year I've shipped Menu v2, Card, Popover, Breadcrumb, an expanded AI icon set, and a redesigned PageHeader, plus a long tail of fixes driven by real in-product usage rather than Storybook edge cases. I also led the React 16.13 → 18.3 upgrade for the repo so component authors weren't blocked by the older runtime.

Most of these came directly out of pain we were seeing in product reviews — components that worked in isolation but broke when composed inside an actual page. Pulling those fixes into the system meant the next team to hit the same problem just got the fix for free.

The Hidden Setup Gap

The real barrier wasn't AI — it was setup.

The issue wasn't willingness. It was that AI coding tools assumed a developer baseline many non-developers had never needed before. "Use Claude Code" sounds simple in theory, but the actual starting line was much further back — some designers had never opened a terminal, authenticated through GitHub, cloned a repo, installed dependencies, or seen how an AI coding agent connects to a codebase.

So enablement couldn't start with advanced prompting or contribution workflows. It had to start with the basics: what the terminal is, how GitHub authentication works, how to open a project locally, what an environment setup error looks like, and how to recover when the agent gets stuck. The bootcamp became less about teaching people to "code" and more about making the invisible technical assumptions visible.

That's why the bootstrap repo mattered. Once those basics were demystified — and once as many setup decisions as possible were removed — designers could actually reach the design problem and prototype with the design system, instead of getting blocked long before they ever got there.

That's why the guide met people where the fear was. The setup chapter explicitly reassured people that they wouldn't break their machine and that we'd go step by step. The tone was deliberate — the barrier was confidence as much as knowledge.

My Role

Translating developer-native workflows for the rest of the team.

I became the bridge between design, engineering, and the new AI tooling workflows — helping designers, PMs, ops partners, content designers, and managers get from "I want to try this" to "I can build, host, and share a working prototype." That meant hand-holding people through the full path: setting up their environments, choosing the right tool for the task, prompting against the design system, debugging missing dependencies, hosting prototypes in GitHub, and knowing when a prototype could become a real contribution to a team's codebase.

The Tool Ladder

Start where you're comfortable; climb only as far as you need.

Part of being the bridge was matching the tool to a person's technical comfort level instead of pushing everyone into the most advanced workflow. I laid out a tool ladder: prompt-to-prototype tools for quick wireframing, an AI IDE for people ready to touch code in a repo, and a terminal-based coding agent for heavier implementation work. People could start where they were comfortable and climb only as far as they needed.

The System I Built

A guide, a bootstrap repo, and shared AI rules.

The first blocker was setup knowledge. The paved-path engineering repos came with the right design-system setup, but also the overhead of a full product codebase. Blank starter apps were lighter, but missing the internal token stylesheets, dependencies, and component-registry setup that make the design system render correctly. So I built a prototype bootstrap repo people could clone instead of scaffolding their own — pre-wired with the internal component registry, CDN token stylesheets, and design-system dependencies. From the first prompt, someone could tell an agent "use the design system button" and get the right component, correctly styled.

Then I wrote an end-to-end enablement guide covering setup, tool choice, prompting patterns, common errors, GitHub hosting, and the Intuit-specific gotchas that usually only come from years of shipping inside the company. I paired it with 1:1 setup sessions so people could get over the first intimidating step with support — not just learning to code, but learning how to interact with an AI agent at all.

I authored and maintain the guide myself, but it didn't stay static: it grew from the real questions the people I coached ran into. Whenever someone hit something the guide didn't cover, I'd walk them through it and then fold the answer back in so the next person never had to ask. That feedback loop kept it current with wherever people were actually getting stuck — and the fact that it kept accumulating questions was itself a sign the team was really using it.

Finally, I added shared AI rules to the repo. They tell coding agents to prioritize design-system components, use tokens instead of hardcoded values, and avoid custom components when a system one already exists — so the right defaults were encoded into the workflow, not left to individual memory.

Why the rules were necessary

"Looks right" and "belongs in the system" aren't the same thing.

Part of the guide was diagnosing exactly why AI output drifted. When you point a prompt-to-prototype tool at a design-system library, it doesn't reuse the real, production components — it reads the color and type styles and re-generates its own lookalike versions on top of a different underlying UI library. The result is close enough to fool a screenshot but wrong in the code: custom components where system ones exist, and the same drift I was cleaning up in product repos.

You can nudge it toward the right component one frame at a time, but the moment you add another element the cycle repeats. That's the gap the bootstrap repo and the AGENTS.md rules close by default — they point agents at the real component registry instead of letting them re-invent it.

One source, every editor

Different people, different tools, same rules.

People across the company use different AI editors — Cursor, Claude Code, Codex. Each reads its own config file, so a rule written for one is invisible to the others. Rather than maintain three drifting copies, I kept the full ruleset in AGENTS.md as the single source of truth and made CLAUDE.md and .cursorrules thin pointers back to it. Update the rules once; every editor stays in sync.

The Artifacts

What people could clone, read, and use immediately.

The bootstrap repo and enablement guide turned a developer-native setup process into a repeatable starting point for non-developers. Instead of scaffolding a blank app, finding the right dependencies, and debugging missing design-system styles, people could clone the repo, follow the guide, and start prompting against the real design system.

Making the Defaults Real

I also applied the same standards directly in product code.

Across two large product repos, I opened pull requests that replaced AI-generated lookalike components with real design-system components, removed duplicated styles, pulled repeated patterns into shared components, and surfaced platform features the original implementation had buried. Leaning on Claude let me scan whole repos and fix recurring mistakes at scale, while my development background helped me confirm, redirect, and review the output.

Those 20+ PRs showed the difference between "AI generated something that looks right" and "AI helped produce code that belongs in the system." But the more important move was encoding the standards into AGENTS.md so future AI-assisted contributions started from the right defaults.

Why this matters

It changed who could participate in building.

This was not just about faster prototypes. Designers could move beyond Figma clickthroughs and build real coded prototypes with real interactions and real design-system components — complete flows, wired in minutes instead of the hours it takes to fake every click target in Figma.

That changes what a prototype is for. It's real enough to put in front of customers and watch them actually use it, not click a prescribed path. And because it's built on the real design system, developers can lift and ship it rather than rebuild it from a static file — so the design-to-dev handoff stops being a rewrite.

And it wasn't only designers. PMs and content designers could explore ideas without waiting for a developer to scaffold the first version. Developers received prototypes and contributions closer to real implementation instead of static files to rebuild from scratch.

The A2D Design team hit 100% adoption of the prototype setup and bootstrap repo, and I supported designers, PMs, ops partners, content designers, and managers through setup, prompting, hosting, and contribution workflows.

The bigger unlock wasn't that I could code faster with AI. It was that I made AI-assisted building usable for the rest of the team.

A catalog, not a registry.

The discovery page is where a builder asks the first question: does what I need already exist? The skill cards lead with the human-readable name and version, follow with a citymap-style namespace path (business-finance/accounting/accounting-engine), then a one-paragraph description of what the skill actually does. The filters — type, BU, status — match the way platform stewards think about skills, not the way the database stores them. Archived skills stay visible with a clear pill so nobody accidentally builds against something on its way out.

The sidebar is doing real work too. It's where I put the documentation links and the Slack channel for support — because the moment someone discovers a skill is also the moment they have the most specific question, and the answer shouldn't live three tabs away.

Bundles live on the project. So does promotion.

A bundle is a versioned collection of skills attached to a DevPortal project — the same project that runs the agent that will consume it. So the bundle management surface lives on the project page, not on the platform-level Skills page. That single placement decision absorbs a lot of access-control complexity for free: if you can edit the project, you can edit its bundles.

The environment tabs — E2E and Prod — make the promotion model visible in the place builders already think about environments. Promote to prod is a per-row action, not a separate flow. Archiving a bundle is right next to it. The destructive action gets a red outline; the production-affecting action gets a primary one. Nothing about the system is hidden, but nothing requires a wiki to operate either.

The agent is the last mile.

Once a bundle exists, the agent has to pick it up. The Agents page is where that happens: each agent in the project, the framework it runs on (langgraph in this view), and the environments it's deployed to as colored chips (QAL, E2E, PRD). The same vocabulary as the bundle page, in the same order, so the mental model carries over.

The split between Owned by us and External matters more than it looks. Product teams at Intuit consume each other's agents constantly — and historically nobody knew which agents were owned where, which made debugging anything cross-team painful. Surfacing ownership as a primary tab made cross-team dependencies legible. The Test agent action sits next to every agent so verification is one click from the row you're already looking at, not a separate page.

The Connective Tissue

Three surfaces, one cross-system collaboration.

The reason all three surfaces feel like one product is the alignment underneath them. Each skill knows what MCP tools it needs to call; each bundle knows what DevPortal project it lives under; each agent knows what bundle it consumes and what environments it ships to. I worked across three teams to make that alignment real — the skills registry team, the tools/MCP registry team (a separate org), and DevPortal stewards. The UI only works if those three systems agree on the model. The harder design work was that agreement, not the screens.