Cisco · Duo Security

Early Access Portal

Overview

01
Context
02
The Approach
03
The Process
04
The Outcome
Context

Problem & Solution

The Problem

The old feedback model ran entirely on outreach, with a person in the middle of every loop — recruitment took days to weeks, response rates landed under 1%.

Idea
Day 1
Research
Weeks–months
Design
Weeks
Build
Weeks
Alpha & iterate
Weeks
Beta, iterate, GA
Weeks
  • Recruitment — days to weeks per program
  • Response rate — under 1%
  • Dependency — brokered through customer success
The Solution

A self-service loop where customers turn on beta features and send feedback themselves — no recruitment, no one brokering the middle.

Context

Project Goals

  • Stand up a brand-new team and figure out a working process from scratch
  • Launch within a few sprints
  • Figure out where AI could accelerate the work
  • Test a new working model — juggling two projects and context-switching deliberately, so we never lose time to a "lull"
Process

How we worked together

Working Group

10-12 stakeholders across product, engineering, design, and leadership

Cadence

Monday standup, Wednesday sprint planning, Friday office hours and demos

Alignment

Meeting recaps and design reviews handled async through micro boards and prototypes

Preview

Preview of the results

Status

Shipped and out in customer beta right now

Timeline

Jul 26 — 1.5 months of results so far

Leadership

Positive feedback and excitement from leadership

Behind The Build

How did we do this?

Phase 1

What did we start with?

Handed off
  • PRD from the PM
  • A Lovable prototype
Gathered for context
  • Talked with other teams who'd worked on a few concepts a while back, for context
  • Talked with researchers about how we recruit users to test our features
  • Used Claude to run competitive research
Research

Competitive teardown

A wider teardown of how Linear, Vercel, Notion, Stripe, and Slack each handle beta — looking for the same handful of things across every product.

  • Location — where beta features live in the product
  • Naming — how beta features are labeled and described
  • Enabling features — how users turn beta features on and off
  • Design — what kind of visual treatment is used
  • Feedback — how input gets collected and routed back
Together, these five things gave us a rough skeleton to build our own version from.
Competitive teardown board comparing Linear, Vercel, Notion, Stripe, and Slack
00  Iteration

The vision, grounded in the product

The PM's Lovable concept rebuilt inside the real Duo admin shell, as an Early Access settings page. A grounded starting point, before real content structure or a feedback loop.

Live · click to explore
What worked
  • Grounding the vision in the real shell made it feel shippable, fast
What didn't
  • No content structure or feedback loop yet — still a shell, not a product
Design Hub

Where every iteration lived

A running home for the work between reviews, so nothing got lost as the design moved fast.

Friday demos

Every Friday, stakeholders reviewed the current iteration live, reacting to a working build instead of a spec.

Miro board

A running Miro board captured feedback, open questions, and decisions between demos, so nothing got lost async.

Together, these kept every iteration visible and every piece of feedback traceable.
01  Iteration

First design pass

The first build designed in code. Page inside the admin panel, feature-list structure, status, enable/disable, and a feedback prompt.

Live · click to explore
  • First build designed entirely in code, living inside the admin panel
  • Introduced a feature-list structure with per-feature status and an enable/disable toggle
  • Added a feedback prompt to start closing the loop with customers
  • Looked at existing patterns already in the product to see what could be salvaged
  • Collected feedback and stayed aligned across many stakeholders as the design moved
02  Iteration

Closest to the end state

Explored where early access lives: dedicated homepage vs. top-nav entry. A content pass tightened feature names and descriptions.

Live · click to explore
  • Promoted early access to a top-nav entry instead of burying it in settings
  • Tightened feature names and descriptions in a dedicated content pass
  • The structure that came closest to the shipping end state
  • Revisited and refined based on incoming feedback while eng started building the backend in parallel
  • Started scaling the design down and thinking about long-term maintenance and upkeep
Timeline

So can we build all this in a few sprints?

V1  In development

The build that shipped

Feedback intake, routing, and the early-access surface consolidated into what customers actually touch. Handed to engineering, now entering customer beta.

V1 — the build handed to engineering, entering customer beta
  • Consolidated the early-access surface into the page customers will actually touch
  • Built feedback intake that tags and routes input to the right teams
  • The build handed to engineering, now entering customer beta
A scaled-down version, not the full end-state vision — cut down to the smallest slice worth shipping and testing first.
Mid-Build

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

What shipping V1 changed

Beyond the build itself — the process, the team, and what it surfaced for next time.

  • Design hub — every iteration lived in one place the whole team could point to, instead of scattered files and screenshots.
  • What went well, what didn't — as a group, [fill in specifics].
  • Metrics — 81 enrollments and 40% of customers rolled out within a month of shipping V1.
  • AI showed us where we were weak — designing in code surfaced gaps in our working process and where the team has room to grow.
  • What I could have done better — [fill in specifics].