The Situation
Alexa+ needed a scalable path for third-party developers to connect their own services, tools, and agents to the platform. Until this point, onboarding was heavily supported: solutions architects and internal engineering teams guided developers through a process that wasn’t designed to be self-serve. For 3P builders arriving with their own existing APIs, MCP capabilities, or agent logic, there was no clear, autonomous path to integration.
The deeper problem was structural. Third-party developers don’t arrive the same way. An API developer connecting a live service has fundamentally different needs than an MCP developer mapping tool capabilities, or an Agent Relay developer negotiating handoff conditions with Alexa. A single onboarding flow couldn’t serve all three without either over-simplifying or overwhelming. And without a self-service option, every integration required human support to complete, which wasn’t sustainable at platform scale.
The Strategy
Rather than designing a traditional setup wizard, I reframed onboarding as an agent-led experience, one that evaluates what a developer brings and actively guides what happens next. The distinction matters: a wizard assumes you know what you need. This agent reasons over your inputs, identifies what’s missing, and helps scaffold the rest.
The core tension I held throughout: the agent needed to be genuinely useful without overreaching. Developers don’t trust automation that makes consequential decisions without them, especially early in a new platform relationship. So the framework draws a clear line between what the agent can own autonomously and what requires explicit human sign-off. That line isn’t a UI pattern. It’s a product principle that shaped every step.
The structural decision was to design one continuous experience that branches at entry and converges at the release lifecycle. API, MCP, and Agent Relay integrations each have meaningfully different needs in Steps 1 through 3, but by Step 4 (Test), every developer is in the same lifecycle. Designing three separate onboarding flows would have fractured the platform. Designing one flow that acknowledges the differences at the right moments preserves coherence without flattening real complexity.
To communicate the full onboarding framework, I built an interactive jobs-to-be-done flow that maps each developer type across the three integration paths, from first connection through the release lifecycle.
Building an Alexa+ Integration
These wireframes show a browser-based developer workspace designed around a simple premise: the agent should do the work, and the developer should make the call. From the moment a service endpoint is entered, the agent auto-detects compatibility, infers capabilities, and generates natural language examples ready for review.
Each step makes the agent’s reasoning visible and asks the developer to confirm it before anything is locked in, so mistakes surface early rather than compounding downstream. The Simulate step brings it home by rendering the actual customer experience on device alongside a live data diff, giving developers a clear view of where the integration holds up and where it needs work.
Note: Prototype coming soon
Key Decisions
- Agent decides where it has signal; humans own what requires judgment. The framework draws a clear line between what the agent can do autonomously (detecting connections, reading manifests, generating scope suggestions) and what requires explicit developer sign-off (scope ownership, handoff contracts, behavioral safety). The boundary shifts across integration types, but the principle is consistent.
- Three paths, one experience. API, MCP, and Agent Relay integrations diverge at entry but converge at the build/prototype stage before proceeding to testing and deployment.
- Simulation before testing, by design. Simulate (Step 3) is low-stakes and developer-controlled. Test (Step 4) is documented and gate-based. Separating them gives developers room to find and fix CX issues before they’re formally evaluated.
- The flowchart serves two audiences. Decision layer for developers: what’s expected at each step. Risk layer for stakeholders: failure modes and mitigations. Making the default state readable without either layer forced a clarity discipline that strengthened the framework itself.
- Jobs-to-be-done over feature documentation. Each step is framed around what the developer needs to be true before moving forward, not what the platform does. This makes it easier to identify where the agent reduces friction versus where it would introduce risk.
The Outcomes
- Created a working prototype that demonstrated the feasibility and value of agent-led onboarding
- Established a shared onboarding framework for future self-service developer tools
- Kicked off cross-team collaboration across design, engineering, and program partners
- Helped scope design investment and clarify where deep UX work was most needed
- Bridged the gap between highly supported 1P workflows and self-supported onboarding for external developers
Amara Hulslander – UX Designer 