Case study · Enterprise platform · Google Cloud (AppSheet)
Adding AI to a platform 2.5 million people already trust
Modernizing a mature no-code platform for AI across seven product surfaces, without breaking the depth enterprise customers depend on.
- Role
UX lead across 7 product surfaces
- Scope
AI creation, data context, platform extension, agent access
- Platform
2.5M+ monthly active users
- Method
UX lead across 7 product surfaces End-to-end design and mixed-methods research
- The sharpest decision in this work was made under pressure: open the platform to agents by the faster, rougher route on purpose, to hold momentum, then build the control and governance layer that made moving fast acceptable to the enterprise.
The challenge
A mature platform millions rely on had to absorb AI without breaking what made it valuable.
AppSheet is a deep enterprise platform that no-code business users rely on every day. Adding AI could not mean rebuilding it, and it could not mean bolting AI onto the side. The work was to modernize how people enter the platform, build inside it, and extend it to agents, while protecting the depth mature enterprise customers depend on. I led UX across seven product surfaces in this modernization, from AI tasks in automation through governed agent access.
AI creation
Cutting the distance from intent to a working app.
Business users with a clear job to do were getting stuck before they even started: schema setup, template browsing, and database design stood between them and a working app. The new entry point let them describe the job in natural language, generated an app and supporting data, then handed control back to the AppSheet editor for deterministic refinement. I was the primary designer through implementation, launch, and post-launch.
Intent became the start / Gemini-backed generation / deterministic editor handoff
Generation step
Generated app and data
Fig. 01 · Natural-language creation flow generating an app and its data
Data context
Making AI automation steerable across large data environments.
As AI Tasks adoption grew, automation creators working across multiple databases could not predict or steer how AI would behave in abstract workflows. Data context gave them a clearer way to expose the right tables and signals to AI, with inline error resolution that caught mistakes before they propagated. I led end-to-end design and the user research.
↓ 23%
↑ 17%+
Task success
↓ 67%
Expression warnings
↓ 55%
Selecting tables and signals
Context applied to a task
Inline error resolution
Fig. 02 · Data context exposing the right tables and signals to AI, with inline error resolution
Mixed-methods research
A mixed-methods study chose the design direction, and first-time retention rose from 18% to 22%.
Enterprise app creators consistently hit a complexity ceiling where the visual builder ran out of room and expressions became the only path forward. Mixed-methods research compared three design directions for the Expression Assistant, and the chosen design lowered cognitive load and made expression workflows easier to finish.
N=86 quantitative study
N=6 qualitative follow-up
ANOVA-backed concept selection
Relative comparison across measured dimensions. Concept C selected. Full statistics in the appendix below.
Dimension
Concept A
Concept B
Usefulness
Lower
Mid
Highest
Ease of use
Mid
Lower
Highest
Perceived cognitive load
Higher
Mid
Lowest
Task flow
Mid
Mid
Smoothest
Satisfaction
Lower
Mid
Highest
Fig. 03 · Quantitative results tables from the N=86 study, with ANOVA concept selection
Extending the platform
Three surfaces that widened where AppSheet reaches.
Making AppSheet feel native inside Docs.
Knowledge workers writing reports and reviewing approvals were context-switching every time they needed AppSheet data. Smart Chips put structured AppSheet records directly into Docs, so the handoff felt like a Workspace-native interaction.
Role · Co-designer on the end-to-end flow and UX research
In Google Docs
In Google Chat
Fig. 04 · AppSheet records surfaced inside Google Docs and Google Chat
A 0 to 1 Gantt view that supported a major Cloud commitment.
A major enterprise customer needed project-planning AppSheet had never offered, scoped at Google Cloud leadership level with a tight timeline. The new Gantt view aligned a familiar planning model to AppSheet’s existing logic and views, with phasing defined under real resource constraints.
First Gantt in AppSheet history · Role · End-to-end UX design lead
Configuring the view
The Gantt chart
Fig. 05 · The first Gantt view in AppSheet history
- Decision under constraint
Shipping the harder path when the data would not cooperate.
Decision-speed
- Spec
Decision
- Ship semi-manual mapping over one-click import
Constraint
- Tight timing and resources, multi-year commitment
Trigger
- Incoming schemas did not match what a Gantt view needs
Call
- Higher friction setup, with guardrails
Reversibility
- Guided one-click path designed, deferred
Role
- End-to-end UX design lead
The stakes
A 0 to 1 feature, shipped under tight timing and resource constraints, tied to an executive-sponsored multi-year commitment. It had to land, and it had to land on schedule.
Import and convert a customer’s existing documents and databases from a generic incumbent project tool into an AppSheet database, then build the Gantt view in one click with minor customization.
Incoming databases did not arrive in the structure or schema a Gantt view requires. The one-click promise broke at the data layer.
I explored and presented the ideal low-friction path, but ship constraints forced the less intuitive route: semi-manual schema setup, mapping each data structure to the Gantt feature by hand.
I explored and presented the ideal low-friction path, but ship constraints forced the less intuitive route: semi-manual schema setup, mapping each data structure to the Gantt feature by hand.
Inline user guidance on the more complex steps, clearer error messages, and troubleshooting documentation linked from both the guide and the inline errors.
A third-party implementation partner, briefed and resourced by the team, to help customers adopt the feature inside their environment.
- Organizational impact
On-time delivery of the commitment, and the feature’s adoption. The inline guidance and a briefed implementation partner were there to keep a harder setup from ending in task failure or abandonment.
A heavier first run. Creators did setup work the ideal path would have removed, on the less discoverable route.
A native database that made enterprise apps easier to adopt and scale.
App creators running large apps on legacy or third-party data kept hitting reliability and performance ceilings. A stronger native database UX and a guided migration flow lowered the cost of moving into the Google Cloud ecosystem.
Role · Led end-to-end design and research
Database interface
Guided migration stepper
Fig. 06 · Native AppSheet Database with guided migration
Extending the platform
Opening a mature platform to agents without giving up control.
App creators wanted their AppSheet apps usable by AI agents from Forge and other platforms, but IT admins needed clear guarantees about which data, operations, and permissions were exposed. MCP let creators selectively share app capabilities while keeping databases, bots, and automations under explicit governance. I was the end-to-end UX lead.
Selected capabilities exposed / data access stayed governed / operations remained bounded
Selecting capabilities
Permission levels
Connected agent
Fig. 07 · MCP configuration governing which capabilities agents can reach
- Decision under constraint
Choosing the faster route into agents, on purpose.
Decision-speed
- Spec
Decision
- Start with MCP, phase guided conversion
Constraint
- Partial backend integration, time to market
Paths weighed
- Two, explored in parallel
Evidence
- Engineering proofs of concept, both paths
Call
- Ship MCP first, phase granular permissions
Reversibility
- Phased, not dropped
Role
- End-to-end UX lead
The constraint
AppSheet’s backend was not fully integrated with the surrounding product ecosystem, and time to market mattered. Opening apps to agents meant a hard fork between two routes, and the team could not fund both at full depth on the timeline.
Invest in the backend so creators could turn an existing app into an agent in two or three clicks, with light instruction, surfaced natively across the company’s product surfaces. The most intuitive and discoverable route, and the slowest to build.
Ship a faster, less discoverable route that opened apps to agents as tools through an MCP server, with granular permission levels built for enterprise security and data governance.
I explored and iterated the discoverable path first, the one that would surface on the AppSheet landing page and other product surfaces, and in parallel designed the MCP feature with detailed, granular permission controls. Engineering ran proofs of concept on simple app conversion against the MCP path. After debate, and after I showed how the MCP design kept the enterprise user in full control of security and governance, the team chose to start with MCP and phase the granular permission work.
This was not the most discoverable or intuitive way for the existing base to bring their apps into an agentic workflow. The team chose it to move faster, hold momentum against a generic competitor, and keep creators who wanted to test agentic tools as a possible replacement for the toolset they already counted on.
The granular, enterprise-grade permission and governance layer was what made the faster path acceptable to ship. Its rollout was phased rather than dropped, so control never lagged behind access.
- Organizational impact
Momentum on agents, and enterprise control over which data, operations, and permissions were ever exposed.
Discoverability. The first way in was a configuration step, not a two-or-three-click conversion surfaced where creators already work.
Impact
Recognized impact across adoption, growth, and the enterprise base.
2.5M+
18 → 22%
First-time creator retention
Award
Google Cloud Tech Impact Award
100K+
The deeper interaction designs and the complete research are available on request.
Request the full case study →
Impact
Restraint as much as invention.
Modernizing a platform millions of people depend on is a problem of restraint as much as invention: add the new capability, and protect what already works. That balance, designing for the people who cannot afford the tool to break, is the same problem I work on everywhere a mistake has a real cost.