Staff Product Designer · ServiceNow / Moveworks
How I think about AI-native experiencesIntent-drivenHuman-in-the-loopInvisible when it works
Case studies on AI agents and developer platforms, each focused on the decisions behind the design.
An AI builder for creating plugins through conversation. I designed every run to stay visible and controllable: the plan adapts to feedback, approvals match the level of risk, and a stalled or failed step recovers without losing work.
GenAI search for Intuit's developer portal. It reads what developers mean, not just the keywords, so the right API or doc shows up on the first page. Built from 200,000 real queries, sorted by intent with an LLM.
A vision for incident recovery. Leadership asked for dashboards, but responders needed help, so I led the shift to AI agents that page owners, rank likely causes and recommend fixes. People approve every change.
Intuit bet on selling its financial APIs. I led design for the developer platform that made the bet pay off, from discovering the API to go-live.
Six deep dives from the 0→1 build, each with its own case study.
Let first- and third-party developers browse, use, and customize 1,000+ widgets across Intuit in a few clicks.
View case study →A self-serve flow for app keys and credentials that cut turnaround from more than a week to under two hours.
View case study →Real-time insight into API usage, performance, and health, so partners can debug and decide with live data.
View case study →Aligned 3 orgs on one end-to-end developer journey and won buy-in with a future-state prototype that shaped the FY24 roadmap.
View case study →
One navigation for product-based (QuickBooks) and service-based (Intuit Financial Services) APIs, so developers find key APIs in minutes.
View case study →A new visual identity for Intuit Financial Services, with design tokens and a component library adopted across the platform.
View case study →Engineers relied on tribal knowledge and had to seek help from others. I made the path self-serve, then used GenAI to guide them from idea to working code.
Engagement policy validation that helps non-technical users understand test results more easily.
View case study ↗
Helped clients build and deploy a working customer service app in 60 days.
View case study ↗
Helped clients create business applications quickly, with a great user experience.
View case study ↗
An interactive, immersive way for dance enthusiasts to learn whenever and wherever they want.
View case study ↗When a P1 hit Intuit's developer platform, it took 79 minutes on average to recover. I showed the problem wasn't missing data, it was people coordinating under pressure, and led the shift to AI agents that page the owner, rank likely causes and recommend fixes. People approve every change.
Explore the coded prototypeMeasured on [n] P1/P2 incidents, [period] vs. [baseline]. The FY26 target is a 70% reduction in time to resolution.
Across QuickBooks, Payments, Payroll and TurboTax. Downtime here is a financial disruption for customers and small businesses.
Every minute affects people who rely on Intuit to get paid, pay others and file taxes.
Spent on operational overhead instead of building.
We need better incident dashboards.
People were forced to coordinate, interpret and decide under extreme pressure.
A responder, in research: "I'm navigating a maze of alerts, dashboards, logs and Slack threads, and none of them connect."
Recovery didn't fail because people lacked skill. Each role needed a different truth at the same moment, and every tool showed them the same view.
What broke?
Who owns what? What's next?
What's the customer impact?
I led a service-blueprint workshop with 35+ leaders. We mapped where coordination lag cost time and money, and aligned on one recovery framework instead of team-by-team fixes.
Six named agents tested as "too many concepts to remember." I folded them into one recovery view: the agents work in the background, and responders see one summary and one recommendation.
Recovery broke down at human coordination under pressure, so we pivoted the whole approach, not just the dashboard.
Instead of a passive dashboard, an active system that takes part in the incident.
A wrong page costs minutes. A wrong rollback can cause a second incident.
Research said help showed up too late and asking agents felt manual. I made the experience AI-first: shared context, then AI-guided recovery, then manual investigation only when needed.
Responders scrolled past the context they needed. I moved to a left-to-right scan: status, impact, context, then actions, the order people read urgency.
Three columns: incident details everyone shares, insights for your role (charts for engineers, status for managers), and a live stream of updates and agent reasoning.
A collapsible timeline keeps focus, and conversational deep dives happen in context, so insight lives where the work happens.
Measured on [n] P1/P2 incidents, [period] vs. [baseline].
Round 1 failed because the agents sat on top of the old workflow.
Three people, one incident, three different questions.
Agents earn autonomy one decision at a time, starting with recommendations.
Search was the most-used feature on Intuit's developer portal, and it kept missing. I had an LLM read 200,000 real queries: developers search by intent, but the portal was built by type. I rebuilt search around intent, and first-page success went from 20% to 80%.
High engagement didn't mean high efficiency. Search returned results, not confidence, so engineers looped: guess a keyword, scan, open, back out, try again.
Were we about to fail a third time?
A third redesign would have been another guess, so I went back to the evidence. Usage data showed the symptom. Interviews, benchmarks and past research showed the cause.
| Month | Searches | With a click |
|---|---|---|
| Jul 2023 | 226.9K | 52.3K |
| Aug 2023 | 274.7K | 63.7K |
| Sep 2023 | 244.4K | 60.3K |
| Oct 2023 | 274.5K | 66.8K |
| Nov 2023 | 228.6K | 56.4K |
| Dec 2023 | 209.1K | 52.8K |
| Jan 2024 | 300.0K | 69.6K |
| Feb 2024 | 323.6K | 74.7K |
| Mar 2024 | 347.6K | 79.0K |
| Apr 2024 | 353.9K | 79.0K |
| May 2024 | 387.8K | 87.7K |
Each one became an opportunity in the next section, shown in the same color.
Search returned a long, mixed list, so people opened link after link to find the right one.
Leads to PrecisionNew hires searched "deployment" and got nothing, because content used internal product names.
Leads to EducationEven long-time engineers didn't know what the portal offered.
Leads to VisibilityResults ignored your team and projects, so people asked on Slack instead.
Leads to PersonalizationHow might we cut the noise and return high-confidence results?
How might we show developers what the portal offers, in the words they already use?
How might we turn a hidden destination into a daily habit?
How might we make the portal feel built for each developer?
From ~200k unique queries by ~6,000 developers, Jun 2023 to Jun 2024, categorized with an LLM.
Developers search in their own words, but the portal is organized by type. Instead of forcing one to match the other, I split the work into three layers.
It finds the right APIs and docs, even when no keyword matches.
Is it live, is it up to date, which tech stack it uses.
APIs, docs and widgets each get a tab with their own filters.
The owning teams agreed on the metadata fields together in card sorting.
Each option traded something away. I tested all three before committing to a direction.
If people search by intent, the UI should show it. I put intent chips above the results so developers could steer directly.
"Why are there two searches on the page?"
That's what developers asked in follow-me-home sessions. They missed the real filters, so I took intent out of the UI and kept it in the engine. The cost: no visible "browse by intent" entry point.
Cards gave more whitespace, but testing showed a single list made technical metadata much easier to parse, and it matched every other tab.
Making the primary filters visually stronger broke the habit of paging through results, and turned passive browsers into active refiners.
Different patterns per tab felt disjointed. One pattern everywhere made filtering predictable and cut the cost of switching tabs.
Intuit Certified ServiceUpdated 12:43 PM PSTPayments gateway client for internal web apps.
TemporaryUpdated 12:43 PM PSTSandbox build for a short-lived experiment.
ArchivedUpdated 12:43 PM PSTReplaced by a newer version. Kept for reference.
DeletedUpdated 12:43 PM PSTNo longer available. Links point to its successor.
Team workspace with repos, pipelines and owners.
Business capability and the assets that power it.
REST endpoints with auth, limits and examples.
Drop-in UI component with configuration options.
How-to guide with steps and code samples.
Shipped in 2025. Search MAU doubled, from 3k to 6k.
Most developers find their answer without paging.
Natural-language queries now land on technical assets.
Developers refine instead of scrolling.
You can't fix search by polishing the interface alone.
My own intent chips taught me to keep each where it's strongest.
What's nextVisibility and personalization, starting with "Filter by my projects."
Intuit's financial APIs, like account verification and bank connectivity, only powered its own products. The bet was to sell them to other companies: sell the engine, not just the car. I led design for the developer platform that made that possible.
Three orgs each owned a piece of the developer experience, with their own priorities. I ran North Star workshops to agree on one five-phase journey, then built an end-to-end prototype of the ideal state. Leaders bought into it, and it shaped the FY24 roadmap.
[The hardest disagreement, e.g. product-named vs. task-based navigation, and how the tree test settled it]
The old portal only fit QuickBooks APIs. I tested three structures with 70 developers in a tree test, then 29 more in usability studies.
| Structure tested | Accuracy | Directness | Avg. time |
|---|---|---|---|
| By domain (chosen) | 51% | 58% | 4:44 |
| By API product | 49% | 41% | 6:33 |
| Existing internal model | 27% | 42% | 7:11 |
Domain-based navigation was fastest and most direct, so we went with it. At 51%, half of developers still missed, so I kept iterating on labels. In the final usability round, accuracy reached 86–88%.
Getting production keys took five steps by email and PDF, across three siloed teams, with up to a week of silence. I turned that wall of questions into a "gate": five short steps (profile, scopes, compliance, billing, hosting), each with progress and a time estimate, plus autosave and inline edits.
Developers liked the form. They just never looked for keys there. So I moved the entry point to where they already were.
We started with Storybook, then moved away from it: it couldn't show multi-screen flows or real customization. I designed a framework that could. With 12 fintech developers, we learned they expected to edit inside the widget itself. Renaming "capability" to "transaction" raised the success rate for switching products from 16% to 66%.
Partners debugged with delayed Splunk logs. I designed real-time usage, error, and latency views (P50, P75, P99). Research with 14 developers showed error data was split across tabs and easy to miss, so I added one-click selection for each API and clearer hover details on the charts.
A new look for Intuit Financial Services, with design tokens and a component library. Every team on the platform adopted it as the standard.
To find docs, set up assets and get to working code, Intuit engineers relied on tribal knowledge and had to seek help from others. Over two program generations I designed a self-serve path through all of it: first one step at a time, then end to end with a GenAI guide.
Developer platform · Intuit
Docs looked different for every capability, API quality was hard to judge, and setting up an asset took manual steps, so engineers asked whoever knew. We measured progress on a five-level self-serve maturity scale, from manual processes to a platform that lets developers focus on their own code.
Manual work and heavy support for basic tasks.
Standard requests, still some manual steps.
Automated provisioning; most needs are self-serve.
Self-serve is monitored and improved continuously.
Developers focus on their own code.
From "Who knows how to do this?" to "What do you want to build?"
1.0 made each step predictable on its own. 2.0 connected the steps, with GenAI guiding developers from discovery into development.
Pick a stage to see which tools cover it.
Discover & learn Docs, tutorials and onboarding.
A landing page and content page template: intro, what's new, demos, getting started and concepts, so developers always know where to look.
One documentation quality score built from a checklist, writing quality, working links and customer feedback. Missing required docs are flagged, and scores turn red below 60%, amber below 80%.
Each API shows which maturity criteria it meets, from self-serve to reusable across capabilities to ready for external developers, so owners know exactly what to fix next.
Developers start from a journey, like importing tax data from uploaded documents, instead of hunting for each widget and API. Every step shows its status, from not started to done.
From discovery into development, in five steps. The prototype at the top of this page plays the whole flow.
Say what you want to build.The assistant starts from intent and shows similar solutions to reuse.
Add context.Attach the PRD, tech doc and Figma file.
Get a plan.It drafts a technical diagram and creates the Jira epic.
See everything you need.Front-end, back-end and data pieces, each with its paved road.
Follow the steps.Workspace, UI components from the Figma file, integrations, then monitoring.Engineers found, set up and shipped more on their own.
One doc template and one maturity score gave every team the same target.
The 1.0 building blocks became the steps GenAI could plan with.
GenAI could only plan a path because 1.0 had already made docs, scores and paved roads consistent. An assistant is only as good as the pieces it connects.
Intuit had hundreds of reusable web widgets, but using one meant tracking down its author. I designed an explorer to publish, find and customize them, for internal (1P) and external (3P) developers.
Inside the IFS platform · chapter 1 of 6
Hundreds of useful web widgets existed across Intuit: flows like connecting a bank account, often spanning several screens. None of them were explorable, so reuse depended on who you knew.
Builds widgets on AppFabric or uses them in plugins and apps. Wants a self-serve way to publish them.
Uses widgets inside their own apps. Wants an easy way to find one and make it match their brand.
"I want to customize the Add Connection widget, but I can't find or use widgets easily, so I don't feel in control."
A left panel to browse and switch widgets, a toolbar for global settings like language and theme, and a right panel for each screen. The rule: what you see is what you get, with every change previewed live in the widget.
Customize every screen, check it on desktop and mobile, then copy the configuration straight into your code.
Three issues shaped the MVP: preview screens had to be technically feasible, browsing showed too few widgets, and per-screen customization was too hidden.
Outside Intuit, you customize a widget after creating an app, right in the app dashboard. Two widgets were available at launch.
Global or per-screen styling with drill-down sections, plus customization of the bank selection screen.
Most read the preview as static, and many never found the bank selection screen.
A screen stepper on the preview, from Intro and consent to Success, with back and next.
The bank list or the screen title? People couldn't tell.
Header text, body text, primary button, with Global and Per screen kept apart.
They expected to customize by editing the widget itself.
Select a part of the widget to edit it, with the panel as a backup.
Only 16% found and switched to another product.
"Transaction" instead of "Capability". Tested with half the participants: 66%.
Developers expected a clear way to switch products. Naming each product, starting with Transaction, made other products easy to find and switch to.
Found another product: 16% → 66%
The same explorer and customization model in both portals.
A framework that works for any capability, not one widget at a time.
Find, preview and configure a widget without contacting its author.
Before any app went live, Intuit reviewed it against security, privacy and sanctions policies, through PDFs, email threads and about a week of waiting. I redesigned go-live as one self-serve flow inside the developer portal.
Inside the IFS platform · chapter 2 of 6
Across the developer journey, the step that stopped people wasn't code. It was getting production keys, because every app first had to pass security, privacy and sanctions checks.
The developer acted twice. Everything else happened out of sight, and one rejection sent them back to the start.
I set three principles for the team, so every decision in the go-live flow could be checked against them.
A developer should never have to guess where things stand: progress and a time estimate on every step.
No offline PDFs or email threads, even for the legal steps. Forms, billing and documents all live in the portal.
Company details once, app details per app, so nothing is typed twice.
Compliance became a few short task groups: profile and hosting, scopes, compliance and billing, so developers never face one long form.
Compliance broken into short task groups instead of one wall of questions.
Production keys visible from day one, locked, so there's a clear goal to work toward.
Every task shows how long it takes, and each group shows the time left.
Insurance questions, like $1M general liability or $5M cyber coverage, often need someone else in the company, so the order can't be forced.
Every field saves as you go, and fields are prefilled from sandbox activity, so developers confirm instead of retyping.
Pay-as-you-go with a 60-day trial, or a custom plan, as the last step of the same flow.
After submitting, a read-only summary shows everything that was sent, and when to expect a reply.
Keys arrive during the trial. Insurance certificates upload into the portal later, with the deadline always on screen.
Company details carry over, so developers only add what's new.
Looks great. Very clean UI.
Only 5 of 12 reached production keys.
The form worked. Nobody could find it.
The tile sits on the app overview, where developers land every day.
Developers managing several apps can start without opening each one.
Down from about a week of reviews, emails and waiting.
From 40 to 60, as the legal steps became a product experience.
With 4 US financial institutions on the platform.
A flawless go-live flow means nothing if no one finds it. The biggest win came from the entrance, not the form. And in infrastructure products, trust signals are the experience: don't hide complexity, explain it.
Developers building on Intuit's financial APIs waited minutes for usage charts and logs, so they couldn't troubleshoot their own integrations. I designed an analytics page that answers three questions at a glance: is it working, what's failing, and is it fast.
Inside the IFS platform · chapter 3 of 6
Successful (2XX) and failed (4XX, 5XX) requests for any window up to a week.
Errors broken down by status code and HTTP method, with logs you can filter.
Response time trends at P50, P75 and P99.
Partners building on the Account Verification and Transactions APIs needed requests, failures and logs while troubleshooting. Charts relied on slow Splunk logs, so they always lagged.
Preset windows of 1 hour, 4 hours, 1 day and 1 week, charts that rescale to the range, logs filtered by HTTP method, and a way to send feedback from the page.
Couldn't monitor error distribution and latency.
Got there, but only after hunting for the right chart.
Requests and errors on one view, quick time presets, and a highlighted time when you hover for detail.
Quick selection of the top 5 or top 10 APIs, instead of unchecking rows in a table.
I specced the analytics charts as a small system: color with clear rules, and the same interactions on every chart.
Teal for success. Red and magenta for errors.
#00B797#00B3C2#F7576C#F54BACEach method keeps its hue on every chart.
#5DABFF#00D5B0#A1CC3B#F88A42#FF77C7Warmer as responses get slower.
#7FD000#FFDC00#FF9331Ten distinct hues, so a Top 10 never repeats.
#5DABFF#00D0E0#00D5B0#3BD85E#A1CC3B#D99001#F88A42#FF808C#FF77C7#B496FF
Requests, failures and latency for each API, up to a week back.
No more hunting across tabs to explain a spike.
Version 1 targeted the FY23 external launch of Intuit's financial APIs.
Intuit's developer experience mirrored its org chart, so every team built its own piece. I ran workshops across three orgs to map the external developer's journey end to end, then prototyped the ideal state, and that prototype shaped the FY24 roadmap.
Inside the IFS platform · chapter 4 of 6
Product APIs, service APIs and platform infrastructure each had their own tools, docs and roadmap. Every team asked "What can we build?", and developers got fragmented toolsets and isolated repos.
What can we build?Fragmented toolsets and isolated repos.
What must the developer experience?One platform mindset.
I hosted design workshops with designers, PMs and architects from three orgs. Mapping the journey together showed each team where its work sat in a developer's day, and gave everyone one person to design for.
He wants his web app to let users connect their banks and fetch transactions. We also agreed on shared terms: workspace, 3P app, widget, sandbox, credentials and production.
The ideal-state prototype gave leaders something concrete to agree on.
The vision set the strategic direction for the next year.
Teams built against one journey, cutting design and communication cost.
Three orgs didn't need another proposal. They needed to see the same developer, moving through the same five phases, before they could agree on what to build.
The external portal was organized by Intuit's products and teams, and it couldn't fit the new financial services APIs. I led a new information architecture, tree-tested three structures with 70 developers, and shipped navigation organized by what developers want to do.
Inside the IFS platform · chapter 5 of 6
Developers had to learn Intuit's corporate structure to find an API.
The IA couldn't take in the new City Map financial services without breaking.
With no shared language, moving between APIs felt like switching operating systems.
You navigate through product brands.
You navigate by what you want to get done.
, , or
Separate "API Explorer" and "Documentation" top-level nav items, with submenus grouped around task-focused language.
The label tells you what you can do there.
Separate "API Explorer" and "Documentation" top-level nav items, with submenus grouped around products and brands.
Brand layers add a level, and you have to know that QuickBooks Online owns invoices.
Combine "API Explorer and Documentation" into one top-level item, with both nested under each API product.
You need the org's product names before you can find the API reference.
Find overview content for identity features.
Accuracy: found the right place. Directness: got there without backtracking. Bars for time are scaled to 8 minutes.
12 interviews shaped an MVP on the task IA. Then 4 usability studies compared two left-nav patterns. Both scored well.
Bars for time are relative; shorter is faster.
REST and GraphQL explorers sit side by side, and the left nav keeps the same behavior for every API product.
Each product gets an overview with quick access to its APIs, so docs and reference stay one click apart.
27%51%
7:114:44
42%58%
Task-based IA vs. the existing structure, tree test with 70 developers. The same task-based model later shaped the internal developer portal IA.
Intuit was opening its financial APIs to outside developers, but both developer portals still wore the classic corporate blue. I set the visual direction for the external (3P) and internal (1P) portals: a new primary color, an illustration system, and tokens that let one component library theme both.
Inside the IFS platform · chapter 6 of 6
Agave-80 as the primary color, and the case for it.
Principles, color roles, illustration and icons.
Tokens and Figma libraries for the 1P and 3P portals.
Intuit's engineering had moved fast, but its developer look stayed anchored to the classic blue. That gap started to matter in FY23, when we opened internal City Map capabilities to external developers.
Website
Developer docs
Website
Developer docs
Website
Developer docs
Website
Developer docsFrom color, type and interaction patterns to illustration, each has a point of view its developers recognize. To compete, Intuit's developer platform needed one too.
Light, uncluttered pages that put key information first.
The right tools for the right people at the right time.
Clear, concise steps through complex tasks.
#0077C5#00828DFeels digital-native, apart from legacy banking.
The green hue signals money and financial data.
Drawn straight from IDS 2.0, so it keeps the parent brand's trust.
#E1F9FF#C2F5FF#00828D#006771#005056#393A3D#6B6C72Sets the context of the story.
Chosen to match the moment.
Ties the pieces into one image.
Simple enough for content-heavy pages. Agave on clothing and assets, blue tints for scenes.
skin-100 · 110
#FBE4CA · #F8D4ABskin-120 · 130
#F9DCB2 · #F5CD91skin-140 · 150
#E1A373 · #D2854Askin-160 · 170
#A15F3C · #7A3F20skin-180 · 190
#5F3927 · #4A2411Scenes and shapes use soft blue tints, clothing and assets use Agave-60 and Agave-80, and outlines use one neutral gray, so illustrations sit quietly next to the product.
I mapped Intuit Design System tokens to QuickBooks tokens, with Agave as the new primary. Components point to tokens, not hex values, so one library themes both portals.
color-action-standard
Internal and external developers now see the same visual language.
Built on IDS, with design tokens that scale to new products and themes.
Teams build from the Agave library instead of fragmented, per-page UI.
Agave won because it came from IDS 2.0, not because of taste. The argument was about keeping the parent brand's trust while signaling money and speed.
I turn new technology into design that solves real problems and moves the business.
I'm a product design leader with 9+ years of experience.
A free spirit at heart, I'm endlessly curious and creative. I love to understand how things work, build things and solve problems.