Design process
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”:
