DUO MOBILE AS TRUSTED
Simplifying Authentication to Lower Support Overhead and Improve Adoption
Why this project?
To access work applications and documents, end-users must first authenticate using a feature called Duo Mobile as Trusted. However, authentication workflows varied by device and security policy, creating unpredictability.
When problems arose, this inconsistency overwhelmed IT help desks with support tickets, frustrated end users, and eroded customer confidence—ultimately leading to subscription attrition.
Outcome
The redesigned flow provided customers with much needed piece of mind, leading to an increase in their adoption of the feature.
Role
Senior Product Designer focused on UX flows, research, project management, and mentorship.
Duration
14 weeks
Team
In-house product design team
2 Jr. Product Designers, Product Management, Engineering
Deliverables
Creative Brief
User flows & wireframes
Prototype
Research findings doc
Mockups
Design documentation
Phab Stories/Tasks
Customers struggled with supporting complex user flows
I took a step back to understand the full picture—how each workflow was presented to end users, and the technology behind them. Three main issues quickly emerged: too many steps, unclear instructions, and unpredictable edge cases.
This complexity was creating downstream headaches for help desk teams—but the impact went deeper than support tickets. It was eroding customer confidence. We heard directly from customers that the friction their help desks experienced led them to question the product’s value, and in some cases, even downgrade their subscriptions.
With this discovery in hand, I planned out our workshopping sessions.
“We've struggled to provide clarity to customers and they in turn have struggled to have predictability.”
— Product Manager
Activities & outputs
Stakeholder interviews, Identify business goals, Research user needs, Define scope, Write Creative Brief
We needed a shared purpose before we could start
Our engineering team hadn’t previously worked closely with designers, so we took time upfront to build shared understanding of our processes. Early on, there were some tensions as we worked through differences in priorities and approach. By creating space for dialogue and staying consistent in how we worked, we were able to improve on their perceptions—and our working model— over the course of the project. This wasn't solved over a cup of coffee.
Activities & outputs
Team icebreaker, operating model discussions, ongoing rapport throughout the project lifespan
Collaborative workshopping helped us gain consensus
I led whiteboarding sessions to map out an improved flow. We focused on reducing round trips between apps, since that was the biggest source of heartburn for users. On the engineering side, we explored how the underlying technology could reduce the variation in flows across operating systems.
Eventually, we landed on a “happy path” concept that worked for most iOS and Android users. Our hypothesis: this simplified workflow would eliminate the majority of edge cases, making it easier for help desk teams to support their end users—and hopefully, helping to rebuild overall customer confidence.
Activities & outputs
Workshopping / whiteboarding, User flows
Wireframing: Success meant being almost invisible
After whiteboarding sessions, I began wiring out happy path "flavors" for iOS and Android. At a screen-by-screen level, our footprint to the user was quite small.
That’s when it hit me: this wasn’t going to be a flashy solution with beautiful screens we’d showcase in a deck (a thought I was reminded of while writing this case study). Success, in this case, would mean the opposite—the flow would be so seamless that it would feel nearly invisible to the end user.
Even so, we still needed to test the concept to understand how it would land with key customers.
Closeup: Wireframing occurred in tandem with visual design explorations. As visual screens were completed, they would replace wireframes in the overall flow.
Activities & outputs
Wireframing (low and high fidelity)
Testing (mostly) gave us the green light
After moving the happy path from wireframes to interactive prototype, I planned and led moderated testing with 10 key customers—admins, help desk, and end users. We tested for perceived complexity, time on task, and reactions to revised content and iconography.
The goal was to see if the flow felt clearer, faster, and easier—and whether it would reduce help desk strain. We mostly got the green light: while feedback was largely positive, some content rewrites caused confusion and made users pause.
We synthesized our findings as a team and identified areas for final refinement before launch.
An animated representation of the happy path flow—not the actual prototype used in research.
Activities & outputs
Prototyping, 10 Customer interviews, Synthesis, Findings doc
Bringing it together for build & launch
To prepare for our build and launch phase, we applied Duo’s visual design system—contributing our new iconography back into the system. For the aforementioned content hiccups, we opted to use more visual assistance in lieu of explicitly verbalizing what to do next—knowing we could iterate during launch.
I documented design decisions, behaviors, and UI states in Confluence, and wrote corresponding stories and tasks in Phab (a Jira-like tool). Through regular check-ins and ad hoc touchpoints, we maintained design QA throughout dev.
All of this led up to our launch.
Activities & outputs
Mockups, Design handoff documentation, Components, Design QA
Launch and listen: burden down, adoption up
Once the simplified Duo Mobile as Trusted workflow was launched and socialized with key customers, we stayed close to gather feedback as they rolled it out. Our Product Manager was our "hot line" for insights.
We heard of several key successes from the field:
-
Help desk burden decreased – The new flow resolved the prior complexity making it easier to remediate any end-user issues.
-
With a more predictable, transparent experience, customers felt more confident rolling out the feature.
Activities & outputs
Product Management check-ins
What we learned defined what came next for us
By partnering closely with Product Management and sharing our learnings from this project, we shaped how future products and features would be designed by our team.
For example, our findings helped shape broader product strategies, including:
-
Prioritizing simplicity in our technology
-
Integrating visual cues and assistive guidance
-
Making content actionable
-
Embedding help directly in user flows
Activities & outputs
Project retrospective
What worked and what could have been better
Seeing the positive impact after launch reinforced the success of our efforts. As a feature team, we went on to develop several more products and features, most notably Duo Desktop. The working relationships we built with our Engineering and Product partners only made us more effective in future projects.
Looking back, one lesson stands out—I would have gotten ahead of our engineering working model more quickly. I made assumptions on how we would work right out of the gate that proved to be weakly supported. The project would have been smoother had we taken time to get to know each others working styles better.
Finally, I would have liked the opportunity to measure business impact, but I didn’t get the chance to circle back.
-
Did we truly regain trust—beyond the verbal feedback we received? I would have measured this through CSAT, NPS, and user surveys.
-
How much did adoption improve? I would have looked at activation and conversion rates to understand the lift.
Measuring against baseline NPS scores, for example, would have revealed more of our impact.
Next up : Verta Prime Case Study »