Back
Cisco · Duo Security

Early Access Portal

Overview

01
Context
02
The Process
03
Execution
04
Impact & Results
05
Reflections
Context

About Duo Security

Duo Security is an access security company that helps businesses make sure only the right people, not hackers, can log into their apps and systems, through things like two factor login checks and device trust checks.

User / Employee
Universal Prompt
(3rd-party website)
Universal Prompt: Duo's login verification screen shown on a 3rd-party website
Duo Mobile App
Duo Mobile push notification with Approve and Deny, shown on a phone
IT Administrator
Admin Panel
Duo Admin Panel home dashboard, where administrators manage users, devices, and policy
Context

Problem & Solution

The Problem

Getting beta features to customers ran entirely on manual outreach, with a person in the middle of every loop.

Idea
Research
Design
Build
Alpha
Beta, GA
  • Recruitment: days to weeks per program
  • Response rate: under 1%
  • Dependency: brokered through customer success
The Solution

A self-service portal where customers turn on beta features and send feedback themselves.

Context

Project Goals

Launch the beta portal within a few sprints
Experiment with a new working model: juggling two projects at once within a small group
Come out with a clear process and a read on what's working
Context

Collaboration

Design (me)
Product Mgr
Engineer
Engineer
Core team
10–12
stakeholders across product, engineering, design, and leadership
Weekly cadence
MONStandup
WEDOffice hours
FRIDemos / discussion
Alignment
  • Meeting recaps shared in channels
  • Async design reviews through Miro boards
  • Live working prototypes shared for feedback
Context

Preview of the results

Entering beta in record time for a project of this scale
81 enrollments across 39 customers in month one, zero PM outreach
4 of 5 V1 features hit double-digit enrollment on their own, entirely self-serve
The Process

How did we do this?

The Process

What did we start with?

A product-to-design handoff: what the PM handed off, and what design gathered before picking it up.

From product
  • PRD from the PM, the starting brief for the Early Access Portal
  • A Lovable prototype, a rough first build to react to
Gathered by design
  • Talked with other teams who'd explored concepts before, for context
  • Talked with researchers about how we recruit users to test features
  • Used Claude to run competitive research
The Process

Competitive research

with Claude

Experimented with running the competitive research through Claude, comparing how Linear, Vercel, Notion, Stripe, and Slack each handle beta.

Competitive research board comparing Linear, Vercel, Notion, Stripe, and Slack
  • Location: where it lives in the product
  • Naming: how it's labeled and described
  • Enabling: how it's turned on and off
  • Design: how it looks and feels
  • Feedback: how input gets collected
These areas gave us a rough skeleton to build our own version from.
The Process

Design setup

with Claude

Experimenting with designing in code with Claude, instead of Figma.

Attempt What I tried Outcome
Design system MCP Pull real components via our design system's MCP Too early, unreliable
Storybook Read components straight from Storybook Not accurate enough
GitHub repos Cloned our design system's repos into Claude Code Too much scope to extract cleanly
Inspect & copy Copy code from our test environment via inspector Still not clean
"Good enough" solution
Had Claude copy the base shell straight from our test environment.
The Process

Grounding the vision

The PM's Lovable concept rebuilt inside the real Duo admin shell, as an Early Access settings page.

Live · click to explore
What worked
  • Gives a designer a real starting point for the vision
What didn't
  • Layout wouldn't hold up as more features got added over time
  • Too many iterations packed into one section
The Process

Where every iteration lived

A site pinned in our team channel opened straight to this hub, where everything related to design lived, organized in one place.

Live · click to explore
Design Folder hub listing the final version and previous iterations of the Early Access Portal design
  • PRD, Confluence page, and Miro board, all in one place
  • Older iterations never got lost
  • Friday demos plus an async Miro board
  • More reviewers weighed in, without more meetings
The Process

First design pass

The first design pass, built as three collapsible sections inside the admin panel.

Live · click to explore
  • What's new & coming up surfaces recent and upcoming changes
  • Currently enabled lives in its own dedicated list
  • Search and filters make the full feature table easy to scan
  • Disabling a feature takes a confirmation step to prevent accidents
What didn't work
  • Having all three sections expanded hid the full feature list
  • Needed more context around what's new
  • Unclear what happens if a user is interested in a "coming soon" feature
  • Enabling a feature felt too abrupt
The Process

Second design pass

A refinement pass that tightened the structure and content based on feedback so far.

Live · click to explore
What's changed
  • A documentation link points to what's new and changing
  • A notify action pings admins when a feature goes live
  • One table now, filtered with tabs
  • The action button was toned down to something more subtle
  • Two-step enabling confirms before it turns on
Execution

Can we build this in a few sprints?

Execution

Version 1

Scaled down to the basics to start: the smallest version worth shipping and testing first.

Live · click to explore
  • Lives on the home page, not buried in settings
  • Simpler two-step modals for enabling and disabling
  • Learn more links out to the testing guide
Kept maintenance in mind throughout: didn't want getting into the portal, or keeping it running, to become its own source of extra work.
Execution

Unexpected things along the way

Not everything about V1 was planned. A few things surfaced once the build was already underway.

Modal alignment
A design fix needed mid-build to get spacing and alignment right across the modal states.
Documentation team
Coordinated with docs so the shipped experience matched what customers would actually read.
Last-minute features
A few features were asked to be added late, reshuffling scope days before launch.
Impact & Results

Results

Shipped into customer beta in under 1.5 months and rolling out to customers today.

1.5 weeks in
7
enrollments
  • 148 unique visitors
  • 231 total visits
  • 21 engaged with a feature
→
1 month in
81
enrollments
  • 39 customers enrolled
  • 40% of customers rolled out
  • 4 of 5 features at double-digit adoption
  • Design hub made it easy to collect feedback and iterate in one place.
  • Engineers enjoyed the working process, and found it easier working with real prototype output than static mocks.
  • Leadership asked the team to pilot a new way of working other teams could adopt.
Reflections

Learnings

Beyond the build itself: what worked, what didn't, and what it surfaced about the process.

What went well
A working prototype accelerated feedback cycles and aligned stakeholders quickly, and engineering stopped rebuilding the middle of the flow once the end state was clear.
What didn't go well
It also made it too easy to loop in anyone. Threads got hard to manage and often meant extra follow-up work afterward.
AI learning
AI could spin up a full design system in minutes, but turning that speed into a real team workflow still took time and experimentation, and looked different for every designer.

Thank you! Questions?