Brief

Note: Designs have been edited to protect features scheduled for release in fall/winter 2022.

To ensure users receive important family notifications, we need to accurately capture their mobile phone numbers. In our existing design, we ask users to take another look at the number they entered to make sure it’s correct. To improve this experience, our team decided to use two-factor authentication* to ensure we have the right number.

I prepared a logic diagram to guide conversations with our engineers before showing them low fidelity wireframes of happy and potential error flows. To understand whether these flows were easy and intuitive, I created 3 prototypes for an internal experience review, which would inform our external user research and design direction.

*Two-factor authentication for Family Safety involves sending a code to the mobile phone number given, requiring the user to enter the code they received via text into the app. If the code isn’t received, they can update the phone number they provided.

Role: prototyper, content, and UX designer

Worked with: PM, front and backend engineers, researcher

Logic flow

Besides the UI, the interactions of the user and the system need to make sense. To demonstrate this, I like to map the logic (or “box and arrow flows,” as my baby designer self used to call them). By stripping down what happens if the user or system does X, we create a communication tool between designers, PMs, and engineers. It allows us to get the flow right without getting bogged down by the visuals.

My favorite conversation starter was what happens if the system doesn’t accept the authentication code? I identified 4 key errors a user might encounter:

1. Not inputing enough numbers

2. Typing the wrong code

3. The code expires

4. Too many wrong attempts were made

These are common to high-risk scenarios, like banking login from a new device, but just because we could present these errors didn’t necessarily mean we should. When we get to the external user testing phase, I’d like to understand whether using only errors #2 and #3 feels sufficiently secure.

Wireframes

Similar to logic flows, low fidelity wireframes allow us to get a basic idea of the UI without hyper realistic visuals cementing a design direction. I’ve found high fidelity too soon limits people’s imagination and feedback/brainstorming ability. For this authentication flow, there were 2 screens needed (add number and verify the code) with multiple states throughout the user interaction.

Existing design system vs. custom component

I used low to mid fidelity wireframes to explore how the UI could impact the flow. For example, using boxes or dashes to represent the individual numbers of the authentication code, as opposed to a generic text field, can reduce the possibility of a too short code error; we’re visually communicating that there are 6 digits required instead of making the user read, guess, or pay close attention.

Accessibility and custom text fields

How increased text size could impact code entry was a top-of-mind accessibility question. The Microsoft design system uses a generic text field (a line with hint text) that handles text sizing up easily and it’s been documented for our engineers. I used wireframes to demonstrate how a custom text field (a box per digit) might flow and scroll if the text size were increased.

Additional wireframes: impact of content, errors, and happy flow comparison