Embark — Language Learning

Discovery, Wireframing, and Prototype Testing Case Study

Platforms: Android, iOS, Web
Team/Role: Lead UX Designer on a team of 3 UX designers and 20 Developers
Website: Play Store | App Store

If you visit either of those links, you’ll notice a different logo. I’ve kept the old logo because I’m not sure how permanent this new one is.

Overview

I worked for Global Educational Technologies(GET) on their flagship product, Embark — Language Learning, for almost two years. At the time I joined the team, the app was in its very early stages, didn’t have a name, and there was only vocabulary lessons and some review content. Now, two years later, Embark has vocabulary, phrases, grammar and listening content. While I designed the majority of the features and activities in Embark, the project below represents a small sample of the type of work I did there.

Embark — Language Learning is a language acquisition tool for missionaries of the Church of Jesus Christ of Latter-day Saints. This app was created to replace an old language acquisition tool from the 90’s called Technology Assisted Language Learning (TALL).

Problem

Part of the Embark design philosophy has been to enable users to dedicate mental bandwidth towards learning their assigned language by reducing the cognitive load needed to have successful study sessions. To accomplish this, we intentionally designed Embark to allow users to decide which topic to study, but limit their ability to dictate exactly which words they’d learn. Instead, our content team calculated the priority of words to learn based on their frequency of use and importance in missionary vernacular. We then fed these words to users 6 at a time in structured lessons.

As the apps user base grew, so did the number of requests to create more flexibility with allowing users to decide exactly which words they would learn.

Solution

To accomplish this change, I kept the current system of feeding 6 prioritized words, but added a feature to give “pro-users” more control over their learning experience, allowing them to dictate exactly which words they want to learn first.

Challenges

Finding balance in The Force
Though we would be introducing more control to users, I still wanted to ensure I found the balance between giving them enough control to enhance their studies without giving them too much control to where it encumbers their studies.

Signal to Noise Ratio
The number of features requested to appear in the redesign would make it difficult to avoid a noisy interface. With a desire to create a clean and intuitive UI, I also wanted to avoid users having to scroll through lengthy pages if possible.

Results

This feature removed a huge painpoint for a lot of users which led to higher adoption rate for new missionaries and improved retention. Early in Embark’s lifetime, it was assumed that removing control and creating a guided language learning process would be a stress relief for missionaries, but in discovery, we found that our users actually craved far more control over their language learning than what we had previously been giving them.

Discovery

Much of the discovery for this project was conducted by my excellent PM counterpart. Our observations combined with those of our Product Owner led to the solution we came to.

Observations

After compiling and analysing user feedback provided through Instabug — an in-app feedback plugin — and various peripheral observations of users during user testing for other features, it became clear that a stumbling block for users was the inability to manually choose exactly which words to study. Missionaries at the Missionary Training Center often structure their language study in preparation for teaching lessons in their target language. In order to best prepare for these lessons, they would frequently identify key words they needed to learn in their target language and study those. Embark’s rigid lesson structure was actually beginning to hinder users ability to adequately fulfill their learning needs.

Analysis

It was clear that users wanted a few key changes to Embarks lesson structure. They wanted:

1. To be able to choose the exact word they wanted to study and add it to a lesson.
2. To be able to see a list of all the words in a lesson along with their translations. Some users were very specific about the need to see a list of words and their translations without having to complete a lesson first.
3. To be able to specify the number of words they could learn in a given lesson. Early in the apps history, designers discovered that 6 words per lesson was ideal for the type of content we delivered, so they set a default number of 6 for each lesson. What we were beginning to see was that as missionaries became slightly more advanced in their language skills, they would want to add 10–20 words per lesson and found the default 6 to be boring.

Due to the scope of these changes and the possible extenuating implications of altering the number of words per workout, we decided to limit this project to just managing which words users learn per workout and not the number of words.

Ideation

Brainstorming

Before designing, the PM, Product Owner and I held a quick brainstorming session to come up with as many options as possible of how we could solve this problem.

From our brainstorm, I then moved into creating collaborative sketches in Invision Freehand. I’d sketch potential ideas, then we’d discuss and give feedback.

Initially, the idea was to use this problem as an opportunity to add various other pieces of functionality into the app such as more logical gamification and reward systems where the amount of words you learned would affect the number of words you could view translations for without completing an activity. These additional ideas over complicated the initial problem and began to drastically expand the scope of the task. We pulled back on the reigns and decided to narrow our scope again and focus on a few less additions.

With the refined scope, we repeated this iterative process another three times with lots of feedback and discussion. Eventually, we cut back all of the other ideas we were playing around with to settle on creating one screen that would allow users to:

• See native and target language words
• Listen to audio for each word
• Select up to six words they would like to practice in their next lesson
• Identify which words they already knew, which would be moved from learn lessons into review lessons

Design

Principles

Signal to Noise Ratio
Alignment/Balance

Features

This screen would have long lists of words requiring a lot of functionality per list item. Listing all these items and their functionality in a way that users could understand without cluttering the screen or creating too much noise would be a problem.

There are two sets of opposing features on this screen. One set is native language vs target language. The other is the indication of words users want to learn vs the indication that a word has already been learned.

Iterations

I quickly found a design that allowed for the separation of the two sets of opposing features. By placing them on opposite sides of the screen, it created a clear barrier between what each feature. We were then able to add simple instructions at the top of the screen to help guide the user.

Prototyping and Testing

I tested several variations of the above designs with various missionaries with the intent to identify two things.

1. Which font size, icon size, and spacing would appeal most to users and allow them to navigate this screen with ease?
2. Which variations in font weight and color would most clearly indicate the proper affordances?

Results

Initially, we assumed users would want small icons and text in order to fit the most content on screen, but found that missionaries preferred larger icons with more spacing. The effect of condensed list items caused missionaries to feel overwhelmed and confused by the congestion.

As one final adjustment, we found through testing that missionaries disliked being limited to only identifying 6 words to study at a time. This limitation was forcing missionaries to return to this screen after every single lesson to again identify another 6 words to study. Rather than limit the number to 6, we changed the check boxes to stars and treated starring a word as prioritizing it. This allowed missionaries to identify all the words that were important to them in larger chunks which reduced the amount of overall time they’d have to spend managing their learning experience.

Conclusion

What was the end result

The sollution was a modal that could be pulled up just before entering a lesson that would allow users to manage the content of their upcoming lesson. Users could prioritize words and identify words they already know to prevent wasting time.

How did the change effect user’s

This feature removed a huge painpoint for a lot of users. Early in Embark’s lifetime, it was assumed that removing control and creating a guided language learning process would be a stress relief for missionaries, but in discovery, we found that our users actually craved far more control over their language learning than what we had previously been giving them.

What did I learn through this process

I learned the value of really listening to your users and understanding exactly what their needs, values, and painpoints are. If we hadn’t been paying as much attention during testing for other features, we may have missed warning signs that were presenting themselves in our periphery. By paying attention to the little signs users gave us that something was wrong, we were able to identify a substantial issue and resolve it quickly.

What would I do differently?

We resolved our users needs and relieved a painpoint, but if I were to do this task again, I would’ve spent more time iterating on the layout and iconography to see if there was a better way to avoid the use of instructions at the top of the modal. I think there was probably a way to present the information on this screen in a better way, but there were certain business needs we had to fulfill that limited the amount of time we could dedicate to this task. Overall, I’m happy with the way this task turned out.

Thanks for reading! Check out my other work and let me know what you think! Critiques and feedback are more than welcome. Leave comments or contact me at jackson.lloydlp@gmail.com.

Thanks,

— Jackson

Chatbooks

Sany

MTC Tools