DUO MOBILE AS TRUSTED
Simplifying Authentication to Lower Support Overhead and Improve Adoption
To access work applications and documents, end-users must first authenticate on their mobile devices using a feature called Duo Mobile as Trusted. However, authentication workflows varied by device and security policy, creating unpredictability.
This inconsistency overwhelmed IT help desks with support tickets, frustrated end users, and eroded customer confidence—ultimately leading to subscription attrition.​
Impact
Eased help desk burden, strengthened customer retention, and improved feature adoption.
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
UX Brief
User flows & wireframes
Prototype
Research findings doc
Mockups
Design documentation
Components
Phab Stories/Tasks
Customers struggled with complex end-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.
“We've struggled to provide clarity to customers and they in turn have struggled to have predictability.”
— Product Manager
Using Miro to map out existing workflows and edge cases helped me see the big picture. Our team collaborated with our remote engineering team to vet everything for accuracy—making sure nothing was missed on our end.
Activities & outputs
Stakeholder interviews, Identify business goals, Research user needs, Define scope, Write UX Design Brief
Speedbump! We needed shared purpose before we could work well together
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—particularly around balancing speed of delivery with user experience. By creating space for open 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.
This diagram makes it look easy. We had to establish an operating model with our engineering partners... it wasn't solved over a cup of coffee. This required a fair amount of discussion and navigating differences throughout the project.
Activities & outputs
Team icebreaker, operating model discussions, ongoing rapport throughout project lifespan
Collaborative workshopping helped us gain consensus
I led whiteboarding sessions with the intent to map out an improved flow. We first 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 be cleaned up to reduce the variation in flows across mobile 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.
I led virtual whiteboarding sessions—which were messy at times—but they ultimately helped us align on the "happy path" above that solved for the majority of our end users.
Activities & outputs
Workshopping / whiteboarding, User flows
Success meant being almost invisible
After whiteboarding sessions, we regrouped as a team and I wired out the "MVP" happy path for iOS and Android.
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... sigh).​ Success, in this case, would mean the opposite—the flow would be so seamless that it would feel nearly invisible to the end user.
​
That all said, we still needed to test the idea to understand how it would land with key customers.
The "happy path" (shown here for iOS) greatly reduced how much the user had to interact with us. That’s when it hit me: success would mean being as invisible to the user as possible.
Activities & outputs
User flows, Wireframes
Testing (mostly) gave us the green light
I led moderated testing with 10 key customer reps—admins, help desk, and end users—using an interactive prototype of the happy path workflow. 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.
“This felt pretty fast—the feedback was just enough to know that it worked.”
— Customer end-user
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 in prep for build & launch
With insights in hand, we were nearing the build and launch phase. To support this, we made final refinements to the flow and 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.
​
Accessibility considerations are core to Duo’s design system, so we ensured our work met (or exceeded) expectations through reviews with the Design Systems & a11y team.
​
To set up a smooth handoff, we documented design decisions, app behaviors, UI states, and more 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 development.
All of this led up to our launch.
We applied Duo’s visual design system and contributed new components, documenting the work as we prepared to add patterns back into the system.
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, we stayed close to customers 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.​
-
Adoption improved and customer retention strengthened – With a more predictable, transparent experience, customers felt more confident rolling out the feature.
After launch, we retained and added a number of high profile companies to our customer roster.
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 for the team, including:
-
Prioritizing simplicity in our technology
-
Integrating visual cues and assistive guidance
-
Making content actionable
-
Embedding help directly in the user flow
Learnings from this project informed how we approached solutions in future products and features.
Conclusion & reflection
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.​
Next up : Verta Prime Case Study »