Work/Arcade Control Plane

Case study ( 04 ) · Arcade.dev

Turning Arcade from an infrastructure inventory into an agent deployment control plane.

A take-home redesign of Arcade.dev. I chose the problem, set the north star, scoped the build and shipped a working prototype of the path to a first authorized tool call.

Role
Product Designer, end to end
Format
Take-home challenge, solo
Skills
Product strategy, IA, onboarding, AI UX, prototyping
Tools
Figma, shadcn/ui, Cursor + Figma MCP, ChatGPT

Context

Arcade wins when the first tool call works.

Arcade is the auth and tool-calling layer for AI agents. The take-home was open-ended, so I treated it like week one as a founding designer: no PM, no spec. I owned the problem, the scope and how to measure it.

Before designing anything, I tried every product flow myself, logged where it broke, and shadowed an AI engineer for 30 minutes.

  • North star: 1

    First successful, authorized, reviewable tool call.

  • How I worked

    Product flows tried All (Logged wins and failures); AI engineer interview 30 (Minutes, with shadowing)

  • Shipped: A deck and a working prototype in code.

    Figma and shadcn/ui first, then Cursor with the Figma MCP.


Problem

Users meet the architecture before the value.

The dashboard is a resource inventory. Users have to assemble Arcade's runtime in their heads before anything runs.

  • Old dashboard: ≈8k

    Tools exposed by default.

  • Sidebar: 18

    Flat items, named after backend objects.

  • First decision: 3

    Paths to pick before any value: code, gateway, sandbox.

  • Diagnosis

    01 Resource inventory (18 items); 02 Decision paralysis (3 paths); 03 Fragmented setup (4 places); 04 Weak feedback (No next step)


Strategy

Build one path, completely.

Everything served one moment. I built the path to it end to end and labelled the rest.

  • Sidebar built: 4/12

    Plus onboarding and the code wizard, outside the sidebar.

  • Built

    Dashboard (4 states); Playground (Chat + Execute); Tool catalog (39 integrations); Servers (Gateway wizard)

  • Deferred: Users, policies, runs, audit and usage wait.

    They matter, but none gets a new user closer to the first call.



Onboarding

Intent before infrastructure.

Ask what they want done, recommend the fastest path, keep expert paths one click away.

  • Before

    1 Land on a resource dashboard; 2 Pick code, gateway or sandbox; 3 Assemble docs, config, OAuth; Hope the first call works

  • After

    1 Pick an outcome (5 goals); 2 Choose a path (1 recommended); 3 Connect & run (Inline auth); Trace, then Project Home

  • Three paths

    ▶ Playground, ⇄ MCP gateway, </> SDK, ↗ Explore first

  • Expert wizards: 8 steps

    Gateway and SDK each, with live status beside every step.

  • Default: Sandbox first.

    “Sandbox runs are safe to test. You can promote to production later.”

Step 1: pick an outcome
Step 2: choose how to use it

Playground

A runtime simulator, not a chat box.

Every run shows the same eight checks. When a tool needs access, the run pauses and asks in place.

  • Checks per run: 8

    Paused at 3

  • The trace: Paused for one scope: issues:create.

    User intent; Tool selected; Authorization (Now); Scope check; Policy check; Tool execution; Result returned; Audit log saved

  • To authorize: 1 click

    “Continue to Linear”, inside the run.

  • In the Playground

    Modes 2 (Chat · Execute); Tools ready 64 (Across 20+ apps)

Chat, execution map and trace rail
Authorization, at the moment it's needed

Project Home

One page, four states.

The dashboard follows the user's progress, and every blocker ships with its fix.

  • States

    0/3 Empty, 1/3 Needs auth, 3/4 First run, 4/4 Active

  • First run: 3/4

    Setup done. Next: enable test users.

  • Success rate: 91%

  • Blockers, ranked

    Salesforce auth expired (Fix now); Slack missing chat:write (Reauthorize); Slack approval pending (Review); Gateway has no client (Copy config)

  • Pick tools (2 mins)

    Choose the tools your agent can call.

  • Connect auth (3 mins)

    Authorize once, inside the run.

  • Test action (1 min)

    Run your first reviewable tool call.

Needs auth: one next action
Active: health, runs and blockers (prototype data)

Measurement

Time to a safe agent in production.

Scale it if time to first call drops without new auth drop-off. Rethink it if users run but never open a trace.

Prototype target: a new user reaches a first authorized, reviewable tool call in a single session, without leaving the product for docs.

  • Activation funnel

    Start 100, M2 84, Auth 68, M1 54, M3 42, M4 30, M5 20. Illustrative shape. No data until it's instrumented.

  • Five metrics: Measured by safe production use, not time in the dashboard.

    M1 Time to first authorized call (Activation); M2 Setup completion by path (Onboarding); M3 First trace opened (Understanding); M4 Repeat call in week 1 (Retention); M5 Invited user activation (Rollout)

  • 2 weeks · Validate

    Built: Prototype, tested with 5–10 agent builders.

  • 4 weeks · Beta

    Next: Onboarding and Playground MVP, instrumented.

  • 8 weeks · Production

    Later: Live node canvas, real-time runs, readiness score.


Outcome

A working path to the first call.

Simulated data, no production results yet. The metrics above decide whether it scales.

The call I'd want to own as a first designer: pick the moment that matters, build the path to it, and be honest about what waits.

  • Risk: The guided path hides power.

    Mitigation: “Explore dashboard first” stays one click away.

  • Risk: Sandbox success doesn't transfer.

    Mitigation: First run ends in “Enable test users”.

  • Risk: Simulated data.

    Mitigation: the 2-week plan tests with real agent builders.

View the prototype