Cisco · Duo Security
Early Access Portal
Manual outreach was the bottleneck
The Problem
The old feedback model ran entirely on outreach, with a person in the middle of every loop. Alpha and beta were where the work stalled.
| Pain | Reality |
|---|
| Recruitment | Product managers spent days to weeks per program finding customers |
| Response rate | Manual outreach landed under 1% |
| Dependency | Every conversation brokered through customer success |
| Repetition | The whole cycle restarted at alpha → beta → GA |
Opt in, no one in the middle
The Solution
A self-service loop where customers turn on beta features and send feedback themselves — no recruitment, no one brokering the middle.
Customer
turns on features →
← routed feedback
Product
team
For customers
Opt into early access and shape the product on their own terms, instead of waiting to be found.
Internally
Feedback comes back tagged and routed, so product managers reclaim the weeks lost to recruitment and synthesis.
No one brokers the loop anymore — value runs both directions, and signal flows back at scale.
Goals & Team
What we set out to do — and who did it
Covering research framing, the end-state vision, every iteration, and the build that shipped to engineering. No separate design team, and deliberately no Figma stage.
Goals
- Let customers opt in and give feedback without a PM brokering every conversation
- Ship a V1 fast enough to test the real question: will customers use it themselves?
- Hand engineering something built to scale, not a one-off prototype
4
Core team: design, product management, and two engineers
4+
Stakeholders — product, engineering, design, and leadership — in weekly review
0
Figma files — every iteration designed directly in code
Collaboration
Trust built on a live build, not a deck
Every Friday, product, engineering, and leadership reviewed the same working software — not a mockup, not a spec. That changed how the team worked together.
Mon standup · Wed office hours · Fri — 4+ stakeholders review a live build
One conversation, not three
Feasibility, design intent, and scope got resolved live in the room, instead of bouncing across separate design review, eng scoping, and PM alignment meetings.
Shared reality over assumptions
Everyone reacted to the same real thing each week, instead of carrying their own mental model of what "the feature" was supposed to be.
Faster trust, faster yes
Leadership could see progress firsthand every week, which made it easier to greenlight scope changes without a lengthy re-pitch.
The build itself became the shared source of truth for product, engineering, and leadership alike.
Preview
Where things stand today
V1 shipped and is live in customer beta. Here's the headline — we'll walk through how we got here.
~1 mo
Design to customer beta — record time for a project of this scale
81
Enrollments in the first month
40%
Of customers rolled out across 5 shipping features
39 customers enrolled, 4 of 5 features at double-digit adoption — full breakdown ahead.
Behind The Build
How did we do this?
Design Process
Not a blank page — a handoff to build on
It began with a starting direction from product, taken much further before the first real build.
Starting point
- Rough PRD
- Initial competitive research
- Lovable mockup
Taken further
- Reviewed the existing research
- Far wider competitive teardown
- Grounded the vision into the product
From there, the direction was rebuilt inside the actual product — the real Duo admin shell, its navigation, and existing components.
Research
Competitive teardown, and a gut check internally
A wider teardown of how Linear, Vercel, Notion, Stripe, and Slack each handle beta — plus context from another team on how we recruit customers to test features.
- Surfacing — where beta features live in the UI
- Enrollment — how users opt into early access
- Feedback — how input gets routed back
- Design system — badges, toggles, density
- Recruitment — talked with another team's researchers about how they recruit customers to test features
Design
Finding a skeleton to build on
An early design-system map didn't hold up. What worked instead was starting from what already existed and designing for who'd actually use it.
The skeleton experiment
A full design-system map didn't work in the early phases. Instead, took the real test environment and had Claude replicate its skeleton as the base, then referenced the PM's prototype to bring it to life.
Designing for risk-averse security users
Duo customers expect Duo to lead on what's most secure. Features roll out to small targeted groups first, then scale up on a percentage basis.
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.
- Rebuilt the PM's Lovable concept inside the real Duo admin shell and its existing components
- Framed early access as a settings page rather than a standalone surface
- A grounded starting point, with no real content structure or feedback loop yet
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
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.
- 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.
- 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
From a North Star to a Spec
Design the end state, then cut scope
The PRD was a North Star: direction, with almost no requirements. Instead of waiting for it to fill in, I designed the end state in code, then cut scope down to the V1 worth shipping first.
| Earlier attempt | This time |
|---|
| Build toward the full automated vision | Start with the simplest possible version |
| Scope kept expanding | Iterate weekly, nothing gets scrapped |
| Never shipped | Every V1 decision made with the end state in mind |
What V1 had to prove: a Beta Programs page, a short feature list, status with a per-feature toggle, and a feedback prompt on opt-out. One question — if we give customers a page to enroll themselves, will they use it?
Building the MVP
Naming, content, and the surprises along the way
Getting the MVP right meant nailing the details customers would actually read, and adjusting to a few things no one planned for.
Naming & content
- Naming convention and placement for each feature entry
- Why we landed on this structure over the alternatives explored
- A dedicated content-design pass on feature names and descriptions
During the build
- Modal alignment issues that needed a design fix mid-build
- Coordinated with the documentation team on the shipped experience
- A few features asked to be added last-minute
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.
- 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
Results
Live in customer beta
V1 went into customer beta and is actively in review, gathering more feedback as customers use it.
~1 mo
Design to customer beta — record time for a project of this scale
5
Features shipping to customers, rolled out on a percentage basis
0
Middlemen — no manual recruitment or customer-success coordination
1.5 weeks in
- 148 unique visitors
- 231 total visits
- 21 engaged with a feature
1 month in
- 39 customers enrolled
- 40% of customers rolled out
- 4 of 5 features at double-digit adoption
AI Learnings
How designing in code with AI changed the workflow
The biggest shift wasn't a feature — it was the loop the whole team worked in.
Hours, not weeks
Each iteration went from idea to a working, clickable build in hours instead of weeks — design stayed ahead of the project instead of trailing it.
Reviews changed shape
Weekly reviews shifted from critiquing mockups to critiquing working software — feasibility questions got answered on the spot, not punted to a follow-up.
The tradeoff
Less upfront spec meant more in-flight scope negotiation — the PRD got written against something real, but it was written later, not first.
What we'd tell another team: don't wait for the spec to stabilize — build the end state, cut it down to a V1, and let the working software carry the argument.
Impact
Design hub
Placeholder — drop in what the design hub is and what it enabled.
Fill in: what the design hub is, and what it unlocked for the team.
Reflections
Design led the project
The real shift was the process. Designing in code with AI turned ideas into working screens in hours instead of weeks, so design ran ahead of the project instead of trailing it.
- Design led the project — there was always something real to react to, instead of waiting on a spec.
- The build kept everyone aligned — product, engineering, and customer success worked off the same real thing instead of their own assumptions.
- Requirements emerged by reacting — each demo sharpened the PRD against something real, not an abstract doc.
- What went well, what didn't — as a group, [fill in specifics].
- What I'd do differently — [fill in specifics].
Cisco / Duo Security · 2026
