Duolingo

Project Overview

A case study on how I designed an account switcher for Duolingo.

Duolingo has amassed a cult of 12 million app users who learn Spanish, French, German, Italian and Portuguese. However, according to CNET critic Jaymar Cabebe, “The app makes you log out and log back in to switch, which is less convenient for couples or even families who share a device.”Intrigued by this problem, I applied Lean UX design principles to create a more seamless experience for families.

The Challenge

Help families and couples switch between accounts without the tedious log-in/log-back-in process In other words, create an account switcher that reduces friction. It’s called “Click. Click. Awesome.” (A witty mantra by the legendary Hiten Shah.)

Duolingo Before & After

Below you will find before and after shots of the Duolingo interface. The before is what Duolingo looked like as of June 6, 2014 without an account switching experience. The after is my redesign with an account switching experience.

Before

After

How I got here

I ran a design sprint in two weeks where I prototyped and tested account-switching flows for the iOS tablet app. Below is my two week design process.

Adapted and inspired by Google Ventures & Laura Klein’s Lean UX book

Here's how I did it

1. Understand Needs: Persona Development

Persona:

Personas put people at the heart of the design process. It’s a powerful storytelling technique that informs design strategy.Meet Ann Karn: Ann is a stay-at-home mom.

Meet Ann Karn: Ann is a stay-at-home mom. She’s fascinated by languages.

This need can be summed up with a user story statement:

[As a <type of user>, I want <some goal> so that <some reason>]

To put this in perspective for Ann or any similar persona, here’s what a complete user story statement looks like:

As a mom who shares an iPad with the whole family, I want an easy way to switch between accounts so that I don’t have to log out and log back in to play Duolingo.

How can I help Ann and her family?

After crafting a persona and user story, I wrote down epics and needs. The purpose of the epic and the needs is to understand the scope and figure out how to meet your users’ needs.

With the design stories, we can address each story one at a time in the task flow.

Task Flow

The flow diagram below depicts how a user travels through the system as they switch accounts. The diagram also shows alternate flows and edge cases (unexpected things that happen with the feature) that a user may run into while performing an account switch.

2. Ideate

Sketches

Next, I experimented with as many solutions as possible. I create this on paper to ideate quickly. After I sketched, I talked to a few people about the sketches to make sure I wasn’t missing any major part of the experience.

3. Iterate

Wireframes

I extracted the top sketches and converted them into wireframes. The wireframes explain the copy, call-to-actions, and other interface elements, as well as how they all work together.

The scenarios and design considerations acted as anchors. I was able to imagine how Ann’s family would move through the account switching feature.

4. Create prototype and validate with real users

Through InVision, I created three separate clickable prototypes.

Each prototype tested different approaches to switching accounts. The objective here was to figure out where the confusion was when users move through the flow. There were:

3 rounds of usability tests (groups of 5 users)
15 users tested

In the first two sets of prototypes, users got stuck. A common reaction was: “I don’t get it. I’m confused.” Making a simple feature like an account switcher is actually incredibly complicated. (Thank goodness people failed! The usability tests informed how I could move forward and iterate.)

Final Design

After all of the tests and iterations, the third prototype was a success. Everyone could switch accounts. And, if a user did not have an account, she could add an account to switch into. You can play with the interactive prototype here! For a quick demo of how it all works, check out the video demo:

Click here to see the prototype

What I learned

Test early and often to see what works best.

‍The easiest thing a designer can do is get sucked into designing. We forget to test. We also choose not to test. There isn’t time for it. Luckily, I challenged myself: for every interactive prototype, I tested at least five people.

Before each usability test, I was confident users could easily switch accounts. However, most of the users in the first two rounds of testing failed to accomplish this task. They all went to the wrong places (i.e tapped wrong button and got lost.) I was horrified.

I hustled. I made changes and came up with a cleaner prototype for round three. Everyone I tested completed the account switching smoothly. Colleagues who watched the demo video or who tried the final prototype said it was so plain and simple. That would not have been possible if users had not failed using the feature in the first two prototypes.

When you create a product, how often do you get things right the first time?

The point of Lean UX is to put out Minimum Viable Products to learn as much as possible. This is what happened here. Watching people go through my first clickable prototype was painful. After reiterating and testing, users could use the feature effortlessly.
The simplest things are the hardest to design.

An account switcher seemed so simple.

What did I encounter?

A pile of crumpled sketches. Wireframes that will never see the light of day. Clickable prototypes that floundered. All I wanted to do was tweet #facepalm and #uxfail when people bombed the usability tests. On the flip side, without the tests, I wouldn’t have had any idea on how to move forward.
For inspiration, I often look to Japanese industrial design Naoto Fukasawa. He said,

Designers often want to make something special, something that really grabs people’s attention. But I realized that when we actually use these products, whether or not they are special is not that important. So I decided it would be a good idea to look at people’s subconscious behavior instead—or, as I call this principle, ‘design dissolving in behavior.’ I realized then that design has to achieve an object ‘without thought.’

Fukusawa’s philosophy resonates with my own design principles. The future of design isn’t about how to make the next flashiest thing. It’s about making products that are intuitive and “dissolve in behavior.”

I’m not affiliated with Duolingo. I’m exploring UX Design in the education technology space. I studied under Kate Rutter & Laura Klein @Tradecraft in San Francisco. Special thanks to Karen Bhatia for making this article sparkle.

This post is also on Medium.