In early 2017, Duo launched a new feature called “Trusted Endpoints”. This feature helped Duo customers to identify which laptops/desktops are corporate-owned (managed) vs personal (unmanaged) and then allowed them to prevent personal devices accessing critical applications. This was a first to market product and generated a lot of industry excitement. However, many of our customers asked us to expand it to mobile devices which we then pursued.
With the rise of personal devices or more commonly referred to as BYODs (bring your own device) in organizations, security teams are concerned about potential risks to their environment. Existing device management tools can only identify corporate devices that are already enrolled in device management software. However, when users access company applications from personal devices, those devices are not known to the IT administrator (our user persona Gary). Duo set off to fix this problem by providing visibility and control around these two groups of devices.
I worked with a product manager to recruit customers to participate in an Active Development Program. This is a program that required a customer to spend 30 mins per week with us on the phone. In the beginning of this project, I leveraged these calls to ask customers preliminary questions around their needs for this feature.
This project was highly technical and required Duo engineers to build new technologies that did not exist before. Doing technical research prior to jumping into design was a must. During this process, I worked along side with engineers. We discovered that identifying a personal vs. corporate mobile device required an extra step that must be performed by a user themselves.
User flows always help me to see the bigger picture and identify steps that were previously hidden from the eye. For this project, I identified a couple important scenarios for an Eve (our end-user persona) whose mobile device was not enrolled into mobile device management (MDM) software yet (meaning it was not managed yet).
Scenario #1. Eve is trying to login to her work application using her personal device. This scenario could lead to a few different outcomes depending Gary’s (our IT admin user persona) environment: he might allow Eve to enroll her device into an MDM, he might want her to contact him, or he simply might tell her she can’t use her personal device.
Scenario #2. Eve is using her corporate-issued mobile device that also was not enrolled yet. In this case she definitely had to contact Gary to get help enrolling it.
Later research proved that scenario #2 happens very rarely as corporate issued devices come pre-enrolled most of the time. We switched our focus only to scenario #1.
When you are logging into an application, the only thing you want is to get to your application. Everything that stands in between will add frustration. Due to our technical limitations, I knew I already had to add an extra step to Eve’s authentication flow - she had to physically press a button to initiate a check that we couldn’t do on the background without her involvement.
Another thing to know about Eve: security is not on top of her mind. She doesn’t think about it and a most of the time she just relies on Gary to tell her what to do.
Design of this project was only involving 3 – 5 new screens in the authentication flow. It might seem that knocking them out should have been an easy task. In my experience, I learned that designing for one screen can be 10X more challenging than outlining a flow of 10+. In my case, the most important thing was language: language that will be empathetic, straight to the point, clear and actionable.
I started sketching some ideas on paper:
I started putting screens together in Sketch and outlining different flows. As I mentioned before, language was everything which meant building clickable prototypes and testing them was a priority.
Edge cases were very important and could not be overlooked. In order for us to check if a device is trusted, the Duo mobile app had to be installed. But what happens if it’s not?
One advantage of designing for Eve is that you are surrounded by them. I put my interactive prototypes on my phone and hallway tested them. I tried several prototypes that used different terminology. I kept track of the results in Google sheets.
The results of these tests were clear. They showed that users did not understand the terminology “managed/not managed” but understood when you referred to their device as “personal” and to their work device as “corporate”:
After doing 3 rounds of internal usability testing and 2 rounds of external testing, I determined the language and flow that was understood by our users. I added an easy way out for Eves, that didn’t have the Duo Mobile app installed, by adding a link “I don’t have the Duo Mobile app” to the main screen.
Trusted mobile endpoints have been available to Duo customers for almost a year. Many customers have dropped their mobile device management subscriptions in favor of using Duo trusted mobile endpoints feature that only required light-weight Duo Mobile app.
Adding this feature allowed Duo to provide a complete picture of device environments. Now, Garys can set policies around types of devices, and restrict not-trusted devices from accessing applications containing sensitive data.
Examples of high fidelity iconography exploration: