Agora.io · 2024 · 9 months
Designing for reducing time to first agent from hours to under 3 minutes.
Reducing time to first agent from roughly 30 to 60 minutes down to 3 minutes.
Role
Principal Product Designer
Team
1 PM, 5 FE, 3 BE, 3 QA, +1 Designer
Timeline
9 months to launch
North star
Time to first agent: 30-60 min → 3 min
Problem
Agora had the infrastructure. It didn’t have a product around it.
A Conversational AI SDK was live on top of Agora’s real-time audio network. Developers still had to stitch speech-to-text, an LLM, and text-to-speech together on their own before hearing a single reply.
Customers coming from call-center work wanted a faster path to production. Most never reached it.
Baseline TTFD
30-60 min
Sign-up to a first working agent before the Agent Studio redesign.
Objective
Shorten the path from evaluation to a first working agent.
Design a studio that improved confidence in moving beyond a demo. The immediate product objective was narrow: make the early lifecycle easier to follow.
Immediate Goals
Configure an agent with less setup overhead.
Reach a live test earlier.
Surface enough deployment and monitoring context to support real implementation decisions.
Business Goal
Reach the first 1M minutes of usage. Help more developers reach value sooner, improve the chances of reaching a first live agent, and create continuity from testing to paid usage.
Research
Finding out where people actually gave up.
One week of discovery during product definition. Five interviews, one designer, a PM sitting in on half of them. This wasn’t a full study but just lean research to commit and test against.
Research approach plan
Secondary Research plan
| What information will we gather | Where will we get it | What questions does it address |
|---|---|---|
| Competitor setup flows | LiveKit, Vapi, Retell: docs + trial sign-ups | What patterns do users expect for setup, testing, production? |
| Funnel data on ConvAI SDK | Internal product analytics | Where does drop-off happen after sign-up? |
| Enterprise voice-AI readiness | Public CCaaS reports, vendor marketing | What production signals do enterprise buyers expect? |
| ... | ... | ... |
| ... | ... | ... |
Primary Research plan
| Who will we study | Where will we find them | What topics will we explore |
|---|---|---|
| Integration engineers | Existing SDK customers | Workflow pain, demo-to-prod blockers, debug needs |
| Solution architects | Partner accounts evaluating ConvAI | Architecture decisions, cost/scale, observability asks |
| Product managers | Internal stakeholders and customer-side product leads | Non-technical expectations, onboarding clarity, value communication |
| ... | ... | ... |
| ... | ... | ... |
Methods used
Competitive analysis
Heuristic walkthrough of LiveKit, Vapi, and Retell setup flows to map expected patterns.
Sales + customer asks
B2B-enterprise input from active deals and customer requests.
Interviews
Five exploratory conversations (n=5) with integration engineers, solutions architects, and product managers.
Secondary research
ConvAI SDK funnel analytics and enterprise voice-AI demand reports.
Insights and opportunities
01
Users trusted the agent only after hearing it.
When the first audible test took hours, most users stalled out. Trust arrived through the speaker, not the setup screen.
02
Users wanted production answers before committing.
Cost, scale, and failure modes lived in docs behind setup. Users needed them upfront to justify moving past a demo.
03
Users lost momentum when they did not know the next step after deploy.
Getting an agent live was not enough. People still had to figure out whether to route to telephony, launch on web, or keep testing. Once the product stopped telling them what to do next, they context-switched into docs and lost momentum.
Goals
Four behaviors the studio had to cause.
Research told us where people fell off. These four principles guided us toward what good would look like if we fixed it, and what number to watch for each one.
Adoption
A developer can configure a voice agent without writing integration code.
Time to a first configured agent in about 3 minutes.
Activation
A user reaches paid intent by adding a card after the 10,000-minute test stage.
Card-added activation rate at ~3× baseline.
Retention
People came back to monitor, test and configure agent or campaign performance.
Repeat build rate above 25 percent.
Confidence
The product answers production questions before a developer has to ask.
Observability adoption above 60 percent of deployers.
Growth Loop Hypotesis
Each goal was designed to feed the next. When a developer ships their first agent quickly, that agent runs in production. Production usage shows which models, prompts and configurations actually work, so the platform can surface better starting points. The next developer inherits a smarter default. Held as a bet going in, not a proven mechanic.
A developer hears their agent respond in the same session.
Low friction means more builds get past the blank canvas.
We learn where developers drop off, what they need, and what is missing.
Those signals shape which models, prompts and flows we surface first.
The next developer inherits a smarter starting point.
- 01
First call
A developer hears their agent respond in the same session.
- 02
More agents
Low friction means more builds get past the blank canvas.
- 03
Usage signals
We learn where developers drop off, what they need, and what is missing.
- 04
Better defaults
Those signals shape which models, prompts and flows we surface first.
- 05
Shorter path
The next developer inherits a smarter starting point.
Assumptions
Explicit bets going in. Each shaped the studio’s design and became measurable.
| Assumption | Rationale | KPI | Success Metric |
|---|---|---|---|
Users will prefer one unified agent builder to stitching services. | Competitive review showed LiveKit/Vapi users valued integrated UX. | TTFD | ~3 minutes to first working agent |
Seeing results early will drive continued exploration and deployment. | Interviews revealed users lose momentum during long setup phases. | Test-to-deploy conversion | 3x baseline rate |
Observability will increase deployment confidence. | Enterprise buyers flagged cost/performance visibility as gating factor. | Observability adoption | 60%+ of deployers |
A node-based editor will facilitate faster automation. | Early exploration suggested advanced automation users might want visual orchestration. | Automation setup speed | Faster multi-step automation setup |
Solution
What Agent Studio shipped with.
Six surfaces covering the full agent lifecycle. Each one maps to a goal from the table above and the metric badge shows which one it drives.
01 · Build
AdoptionAgent configurable in a few quick steps.
- What it is: A guided form for wiring STT, LLM, and TTS with sensible defaults.
- Why it exists: Removed the stitch-three-vendors-by-hand step that blocked every first-time user in interviews.
Results
What moved, before and after.
Measured over the first 90 days post-GA, against the baseline funnel from the problem section.
Adoption
Time to a first configured agent
Before30 to 60 minutes
After3 minutes
Activation
Card-added activation rate
Before~1 in 10 (pre-studio funnel)
After~3× baseline
Retention
Repeat build rate (same dev, 2nd agent)
BeforeNot tracked pre-studio
After25%+
Confidence
Observability adoption
BeforeSurface didn’t exist
After60%+ of deployers
Where assumptions failed
One of the clearest assumptions behind the original builder was that users would prefer a node-based graph editor for configuring agents. That assumption failed: the graph added setup overhead, buried the next action, and pulled the product away from the adoption outcome in the table above.
To move time to a first configured agent from roughly 30 to 60 minutes down to 3 minutes, the agent builder had to be redesigned around a simpler setup flow with clearer defaults and a faster path to live testing.
Before: node-based graph editor.
After: simpler setup flow with clearer defaults.
What stuck
TTFD dropped from roughly 30 to 60 minutes down to 3 minutes. Observability went from nonexistent to a default surface developers opened on their first deploy. The growth loop from the goals section started compounding: more shipped agents fed better templates, and better templates shortened the next developer’s path.
What changed my thinking
It was making the agent audible within the first three minutes of signup. Once developers could hear their agent respond, trust followed. In voice AI, confidence is an audio problem before it is a screen problem.