Introduction

This project took place during my time at General Assembly. I wanted to tackle the challenge of language learning, as it’s a personal interest of mine.

I’d also just taken an evening course where one of the students had ‘completed’ the app Duolingo, but still wasn’t able to use the language, which make me think about different ways to approach the problem space.

Another goal of mine was to approach this project using scientifically backed methods, to give users' confidence that they were learning using proven methods.



User interviews

The first stage in the process was carrying out user interviews. My two main goals were to gather the reasons that people learn a new language, as well as the existing pain points.

I carried these out both over the phone and in person. After writing the main points on post-it notes, I synthesised the data to try and find patterns.

There were three things that really stood out - users felt rewarded in their language learning by seeing their own progress, they needed language which was usable in day to day life, and they didn’t want to spend lots of time.

I wanted to give learners a real, accurate reflection of their progression in their language learning journey, which I felt was something lacking from other solutions.





Persona generation

I created the following persona using the data collected and synthesised from the user interviews I conducted for this project.



Competitor review

I carried out a review of competitors in the space, highlighting the areas which my persona found more important



User flow

Before creating designs, I worked on a user flow to help myself and my stakeholders understand the functionality needed for the app.



Feature prioritisation

I carried out two different feature prioritisation techniques (MoSCoW and impact/vs users affected) for this project, helping me focus on more valuable features.



Wireframing/Prototyping

I initially creating some low fidelity hand drawn wireframes to help me solidify the user flows into workable solutions.

I used these early wireframes to create prototypes in Marvel, to validate my assumptions and get feedback as early as possible in the process.



After this, I created a low/mid fidelity wireframe of the entire MVP of the app in sketch:




I prototyped my design using InVision. After user testing of the previous design, I found that many people were confused with two main states of the app - the ‘card creation’ state and the testing state. In response to this, I greatly simplified the happy path of the app (to just four screens from the previous eight).

Users in testing were much more receptive to this new flow, and found the app much clearer and easier to use.

I kept the additional card customisation feature, but made it optional. This means that powers users who would benefit from this can still use it, but it doesn’t block or confuse anyone.

Additionally, I simplified a lot of the text and used colour to clarify the progression timeline.



I presented the results of this project to my class and instructors at the General Assembly campus.

The project was positively received which was a great result for me but more importantly, during this project I learnt many valuable lessons, primarily:

  • To trust user testing, even if that means changing an idea

  • If it’s necessary to have to explain how an app works, change the design

  • Quicker prototypes are more useful that higher fidelity ones.

These were important learnings which I will bring with me to future projects.