DUO SECURITY
Reduced complex remediation process by 50% and prevented enterprise churn.
Why this project mattered
Enterprise customers were downgrading subscriptions because employees couldn’t log in and help desks were overburdened with complex remediation flows. A feature meant to enable security was instead driving churn and threatening Duo’s burgeoning Zero Trust strategy. We needed to solve this customer retention crisis while making the feature easier for sales teams to sell.
​
What I did
Led the cross-functional redesign as both project manager and IC, mentoring two junior designers while planning and conducting user research. I mapped end-to-end workflows across iOS and Android, and designed the prototypes we tested with customers. I also facilitated collaborative workshops that aligned Engineering and Product Management on success metrics, and documented design decisions in a way that demystified our process for non-design partners. By owning these responsibilities directly, I actively steered the solution toward measurable business outcomes.
​
Impact delivered
-
Reduced user flows from 6 to 3 (50% complexity reduction)
- Decreased help desk burden and improved customer confidence
-
Informed broader Zero Trust product strategy
Role
Senior Product Designer, Design Lead
​
Duration
14 weeks
​
Team
In-house product design team
2 Jr. Product Designers, Product Management, Engineering​​
​
Deliverables
Creative Brief
Research findings doc
User flows & wireframes
Prototype
Mockups
Design documentation
Phab Stories/Tasks
The problem: When security becomes a customer retention risk
Duo Mobile as Trusted (DMAT) ensures employee phones meet security policies before accessing work resources. In theory, it's seamless. In reality, it was driving customers away.
Lee, an Acme Corporation employee, stops at a coffee shop to catch up on work. She needs to access her files on Box.
In a perfect world: Lee signs in → DMAT runs a trust check → She gets access
In our reality: Lee's phone fails the trust check → She's blocked → Must contact help desk → And this is where customer heartburn begins
Help desk teams had to navigate complex flows and edge cases across multiple operating systems. Meanwhile, Lee still can't get to her work.
The impact was clear: we weren't just frustrating users, we were losing business
The complexity was killing us:
-
Android and iOS users each had separate flows
-
Help desks were overwhelmed servicing these issues
-
Customers were losing confidence in the product
-
Subscription downgrades = lost business
-
Sales teams struggled to sell the feature
Root cause: Help desk agents had to ask "Does Lee have an iPhone or Android?" and then from there, figure out complex remediation paths. End users felt stuck without understanding what was happening behind the scenes.
This wasn't just a UX problem—it was a customer experience crisis affecting our business model.
Activities & outputs
Identify business goals, Identify key problems, Define scope, Write Creative Brief
The turning point: from features to outcomes
Recognizing this fit into Duo's larger Zero Trust strategy, I reframed the challenge from a feature problem to a business problem:
How might we reduce complexity so we can regain confidence and drive adoption?
As Duo moved toward a Zero Trust business model, this project needed to create something cohesive for sales teams and easily digestible by customers.
Driving the shift from features to metrics
When our team got stuck debating details, I shifted our focus to outcomes that mattered to the business. Rather than getting mired in interface elements, for example, we aligned on what success would actually look like:
​
I defined success metrics as design success criteria. While tracking after launch sat with Product, establishing these baselines gave our design and engineering teams shared goals to design toward:
​
-
Support ticket volume - Fewer tickets means users are getting to their work instead of calling for help
-
Average resolution time - When help desk is contacted, faster resolution benefits both end users and support teams
-
First-contact resolution rate - No escalation to tier 2 or 3 means help desk is solving issues efficiently
Why this worked: This pivot transformed our relationship with Engineering from transactional ("build what design says") to collaborative ("solve the business problem together"). We were now driving toward shared goals instead of defending our own turf.
Activities & outputs
Collaborative workshops, Stakeholder alignment, Define success metrics, Create project roadmap
Collaboration and research helped us reach consensus
I planned and facilitated collaborative workshops to map user flows and edge cases, then synthesized the outputs into the initial flow proposals. This ensured alignment while also giving me concrete artifacts to guide the design direction.
​
Starting on whiteboards, I quickly moved us to Miro to include our Ann Arbor Engineering team. These sessions brought us to consensus on the core problems.
What we discovered: Multiple redundant steps, plenty of edge cases, unclear messaging, and trust check processes that weren't transparent to users. But most importantly, we identified the business cost of this complexity.
Choosing how deep to pull the weed
Our forensics revealed the problem, but we faced a classic strategic decision with engineering constraints: quick wins with faster implementation versus rebuilding from scratch with high time costs. My recommendation was to find a middle ground between the two.
Strategic simplification: By focusing on our success metrics rather than perfect technical solutions, we could achieve meaningful business impact within realistic constraints.
The result: This approach led us to the "happy path" solution that reduced complexity by 50% while staying within engineering feasibility.
Research was an opportunity to also lead and mentor
I planned and led user testing, personally conducting synthesis and turning it into a teaching moment for junior designers. They observed and took notes while I guided decisions, ensuring that the team was learning and we were creating actionable findings.
​
Research approach:
-
Created separate iOS/Android prototypes based on user's device
-
Recruited 10 participants through product management partnerships (end users, help desk, admins)
-
Focused testing on our success metrics: perceived complexity, time on task, content clarity
-
Had junior designers take notes while Engineering observed to demystify the process
Key insight from testing: Users don't care about our product at all—they just want to get to their work. Our success should be measured by invisibility, not engagement.
Activities & outputs
Cross-functional workshops, User flow mapping, Prototyping, User research, Synthesis & insights
Becoming invisible by design
The ultimate realization: This wasn't going to be a flashy solution with beautiful screens. Success would be the opposite—a flow so seamless it feels nearly invisible to users.
The two moments DMAT reveals itself
Moment 1
Progress indicator during trust check (so users don't think they're stuck)
Moment 2
Simple instruction for next steps (due to iOS technical limitations)
Refining for brevity and clarity
Based on research findings, we shifted from long-form text to intuitive icon-and-text combinations. When users hit blocks, messaging became clear and actionable, guiding them toward the right next step.
​
All refinements were documented in a content matrix for consistency and future reference.
Activities & outputs
Wireframes, High-fidelity designs, Content and design documentation
Adoption by 6 key customers led to full market rollout
Field feedback confirmed success:
-
Help desk burden decreased significantly
-
New flow resolved prior complexity, making remediation easier
-
Adoption improved and customer retention strengthened
-
Customers felt more confident rolling out the feature
What we learned defined what came next
Insights from this project informed our broader Zero Trust strategy:
​
-
Prioritizing simplicity in technology decisions
-
Integrating visual cues and assistive guidance across products
-
Making content actionable throughout the product suite
-
Embedding help directly in user flows
Key lesson: Design decisions impact adjacent teams, company operations, and long-term strategy. Simplification processes could be applied across other teams and products.
Activities & outputs
Performance tracking, Stakeholder feedback, Post-launch analysis, Strategic recommendations
Reflection
What worked
Research was key to staying on track. The positive impact we saw after launch reinforced the value of this approach, and the strong working relationships I built with Engineering and Product Management partners made us more effective collaborators on future initiatives. Beyond solving the immediate problem, this project delivered visible, business-aligned results and laid the foundation for our feature team to successfully launch additional products, including Duo Desktop.
​
​
What I'd do differently
​​
1. Metrics
Looking back, the biggest gap was not establishing clear success metrics from the start. While I defined indicators like support ticket volume, resolution time, and first-contact resolution to guide the design, I relied too heavily on our Product Manager to own tracking, and as a result, I never had baseline data to measure against after launch. Yes, I heard anecdotal feedback that adoption improved by around 10%, but without validated methodology or tools in place, that was more of a “nice to hear” than a reportable impact.
If I could do it again, I would gather baseline metrics on customer usage and adoption, then track post-launch changes in adoption and conversion rates. For example, we might have benchmarked trust through NPS or measured support burden through ticket volume.
2. Team collaboration
I also would have addressed collaboration challenges with Engineering earlier. After smooth icebreaker and kickoff sessions, I assumed we had built rapport and could hit the ground running. In reality, Engineering wasn’t used to working closely with a design team and initially saw us as interlopers with a transactional role. That assumption caused churn in the project.
This wasn't solved over a cup of coffee. What ultimately built trust on the team: meticulous documentation, transparency, and respect for their input. Over time, we shifted from awkward interactions to a mutual understanding with smoother collaboration—but if I’d recognized the gap sooner, or simply didn't assume, I could have accelerated that process.
3. Research approach
In hindsight, I would have approached research differently. I invested heavily in high-fidelity prototype testing, but the findings didn’t justify the effort.
Instead of a single, larger research phase, I could have planned two smaller rounds using lower-fidelity or rapid prototypes, or focused on targeted feedback such as content-only testing. That would have allowed us to learn faster, adjust earlier, and reserve high-fidelity validation for when the design was closer to final.
Next up : Indeed Case Study