♟️ The Challenge: People living in cities are struggling to commit to learn a new language and to manage their busy lives.
🧠 The Approach: End-to-end UX design methodology.
📱 The Output: A mobile app that empowers people to learn new vocabulary with short lessons that can be completed when communiting. The app monitors their progress and adjusts the difficulty level according performance and preference.
🕵️ Research & Problem Framing
Competitor analysis
- I start all UX projects by researching the market for comparable products, in this case three vocabulary learning apps. I summarised my research points under the following headings:
- Key objectives
- Overall strategy
- Marketing advantage
- This included a SWOT analysis of each company / product which led to organically stumbling on existing user pain points and opportunities in the market
It was valuable insight to realise how the design of these apps started through the research. By process mapping our system of the old fashioned card-based non-digital flashcards and the cognitive steps that happen when you learn from them. They connected the emotional steps that the brain goes through when progress is recognised and incorporated this valuable step into the process. The app leverages these emotional responses by pushing progress, highlighting this to the user and creating rewards.
User interviews
I approached this user research with three intentions:
- To create a script of questions and be consistent with all participants when posing them
- To ask the easy questions to start, then save the hardest (and perhaps the most pertinent) question until the end
- To ensure that all user data was kept confidential, including changing the name of users when publishing any results
User personas
The next stage was to personify my research findings by writing user stories in the form of a user persona. This would allow my team to gain a snapshot of our optimum target audience and help support design decisions.
User stories vs. Job stories
- In order to identify the top three problems statements, I started by writing user stories in the form of:
- “As a [type of user], I want [some action], so that [outcome]”
- I had this nagging feeling that there were too many assumptions being made with my proto-persona as it felt newly conceived and lacked a strong 2-week research deep-dive.
- In order to overcome this common problem, I discovered the benefits of creating job stories in the form of:
- “When [triggering event] , I want to [motivation / goal] , so I can [intended outcome] “
- By focussing on the triggering event or situation, motivation or goal and the intended outcome, I found that job stories dug deeper to discover the “why” as opposed to the “who”
Problem / hypothesis statements
I concluded this stage of my UX methodology by writing the top three problem statements and corresponding hypothesis statements.
Task analysis
I was particularly pleased with my process map that detailed my system of changing difficulty for the user. Many of my user interview participants told stories of either a language learning or fitness app that changes the difficulty level too quickly or inaccurately. In order to realise my first hypothesis statement I created an algorithm that used a combination of users scores AND a manually inputted user answer to determine the next difficulty level. If the user answered all answers correctly AND confirmed that the task was too easy, then they would be moved up two levels. If only one of these categories were satisfied, then the difficulty level changed by only one level.
Card sort > Site map
I needed a strategy to ascertain what the optimum structure of the bottom tab bar of my app should look like. By engaging with my research participants with various options and conducting a card sorting exercise I came to the following conclusions. The table below shows the changes made to terminology, order and the decision to remove possessional pronouns based on user feedback.
| V1 | V2 | V3 |
| • Learn words from My Decks • My Decks • My Reminders • My Community • Settings | • Home • Learn • Community • Profile • Settings | • Home • Learn • Decks • Profile • Settings |
🏗️ Prototyping & Testing
Lo-fidelity wireframing
Create new deck
Add word(s) to existing deck (enter example sentence manually)
Add word(s) to existing deck (get example sentence from Linguee.com)
Increasing difficulty after “Learning My Words”
User testing
User testing – what needs fixing
“When adding new words I prefer to have the option to input in either EN or DE.“
- A test participant highlighted that they preferred to enter new words in the target language. The user had a German-native partner which was highlighted as the reason for this alternative method. Unfamiliar words spoken by the partner would be entered immediately. This highlighted to me how easy it is to make a design assumption that quickly evolves into a prototype
- Suggested change – HIGH PRIORITY
- Re-design the input screen and allow the user to toggle the language between EN or DE
- Evidence
- Although only one tester highlighted this as a fix, I classified it as high priority to ensure the app did not make the process difficult for similar users
“Other apps were able to predict what I was typing and gave suggestions of words to select.”
- I was grateful to a tester for highlighting this potential feature. Additions like this can greatly increase the speed of word input and heighten the overall user experience
- Suggested change – HIGH PRIORITY
- Add an additional feature to show a drop-down bar containing suggestions as a user enters more than three characters of a word
- Evidence
- Only one user highlighted this during testing, but by bouncing the idea off some additional participants it proved that developing this feature was a worthwhile investment
“I can’t learn 50 words in ten minutes when I’m commuting.”
- In order to deliver a minimal viable product, I built V1 with a simple feature to learn a deck of flashcards. V1 didn’t ask the user how much time they had or how many cards they wanted to learn. Some testers found this a negative experience
- Suggested change – HIGH PRIORITY
- Include a screen that shows a slide bar asking the user to enter ‘time available’ or ‘number of flashcards’ to review
- Evidence
- The suggested feature was driven by my user persona. She has ten minutes per day to learn words during her commute
Project summary
- What opportunities remain for future improvement?
- NEW FEATURE: Connect to friends and compare scores
- NEW FEATURE: Find a Tandem Partner online based on a user’s profile and current learning level
- NEW FEATURE: Integrate a voice recognition model to record the user’s voice and give feedback on pronunciation and accent
- Key learnings:
- Not to be overwhelmed with a new project with the unlimited potential features to develop. Conduct a solid research plan, engage with users and prioritise the top three features per design sprint
- Always read both the design brief and the user persona(s) regularly. This reiterates the design direction
- A user persona should be a guideline and can be questioned or challenged at any stage of the process. Our markets are fast-paced and trends, behaviours and mental models are constantly changing – so should our user personas
Martin Gamble 