A developer recently reached out to me about his idea for a language acquisition app. He had used a variety of apps and online resources over the years to help him with learning languages, but even after using these tools consistently, he didn’t feel that his proficiency was improving very much.
He felt that he was lacking a deeper understanding of grammatical rules, and noted that many language apps seemed to focus on immersion and vocabulary over grammar. He wanted to create an app that would help him reach his desired level of fluency; While he knew that he’d like the app to incorporate the learning technique of spaced repetition, he hadn’t worked out very many details yet.
While this was admittedly a vague start to a project, I thought it would be an interesting challenge. I structured the project into five major phases:
Research: Understand the existing apps within the language acquisition landscape, what users like or dislike about these tools, and how users approach learning a language in general
Define: Use my research findings to frame the specific issues to be addressed, brainstorm potential solutions, and develop the app’s information architecture
Prototype: Create UI requirements, low-fidelity sketches, and mid-fidelity wireframes
Test: Assess the usability of my wireframes by conducting live testing sessions with potential users of the app, and identify any patterns, confusion, or roadblocks
Design: Develop branding materials (app name, logo, colors, etc.), then create high-fidelity wireframes and a comprehensive UI kit to hand off to the developer
First I delved into some of the primary theories of second language acquisition:
Input Hypothesis: Developed by linguist Stephen Krashen in the 1970s/80s
Learners progress in their knowledge when they comprehend language input that is slightly more advanced than their current level
Improvement in language ability is only dependent upon subconscious acquisition and never on conscious learning
Skill-Based Theories: Based on models of skill acquisition in cognitive psychology; Learning a language is no different than any other skill
Adaptive control of thought: Progression from declarative knowledge (conscious/fact-based) to procedural knowledge (how an activity is done)
- Comprehensible Output: Emphasis on production of language (speaking), receiving feedback, and correcting
I found that there seemed to be a fairly stark divide between people who believe that immersive learning is effective, and those who do not:
My primary research consisted of user interviews. I recruited a handful of participants that shared a few key traits:
Intermediate learners actively studying a language(s)
Currently using at least one mobile app for learning
Aim to become fluent in their chosen language – possibly live and/or work abroad
I synthesized my interview notes into an empathy map:
Using the insights and needs from my empathy map, I created my persona, Felix: A law student in his early 20s who wants to become fluent in his desired language so that he can live and work abroad one day
Felix’s needs for a language app:
Daily “bite-sized” lessons that fit into his schedule (less than 30 minutes)
Feedback that provides him with a sense of his progress and proficiency
Confidence that what he’s studying can be applied to real-world scenarios
Using the insights and needs from my empathy map, I created a handful of POV (point of view) statements with the following format:
“Felix (our persona) needs [need], because [insight]”
For each POV statement, I developed a HMW (“How might we…?”) question to identify the specific issues that this app would address:
“How might we help Felix achieve [need]?”
Not only did the POV statements and HMW questions help keep the focus on our users’ needs, they also helped guide me and the developer as we embarked on our brainstorming session.
For each HMW question, we took a few minutes to do quick, rapid-fire brainstorming – listing off any ideas that came to our heads. Once we had rotated through all the questions, we would start the cycle all over again, until we had completed multiple brainstorming sessions for each HMW. We wanted to generate a sufficient amount of ideas that could be narrowed down and ultimately funneled into potential features and UI requirements.
After our brainstorming session, we distilled our ideas down to the few we liked the best, as we didn’t want to create a bloated app that was trying to do too many things at once. These are the three primary ideas we chose to shape the direction of the app:
Daily Challenge Format: A new mini lesson every day (~10 to 20 minutes)
Real Sources: Challenges would be based on real-world sources with native speakers (news articles, clips from TV shows, etc.)
“Don’t break the chain!”: Calendar visualizations to show the user how many days in a row they’ve practiced, and motivate them to continue their streak
Moving into the information architecture, I created a sitemap outlining the screens for v1 of the app. I then isolated one of the main tasks that a user could accomplish (signing up for an account and completing a daily challenge), in order to develop a fuller picture of a single flow from beginning to end.
After developing a UI requirements document and creating some sketches, I started on my mid-fidelity wireframes – expanding on the screens for each flow to ensure I would have sufficient material for usability testing. I created minimal, greyscale screens so that I could primarily focus on the layout and visual hierarchy without getting distracted by color, typography, or any other UI design elements.
(At this point, the developer and I had been tossing around a variety of ideas for the app name, and settled on “Dayling” – playing off the “daily” format of the app, and using “ling” to indicate the language focus.)
Before moving into the final UI design phase of the project, I created a usability test plan to assess the learnability and efficiency of my mid-fidelity wireframes. I conducted live testing sessions with three users, taking detailed notes to see if I could uncover any potential patterns, pain points, or confusion.
Liked the daily challenge format
Liked that it drew from real sources
Questions were too “test-like”
Article example wasn’t interesting
Unsure how to exit score screen
To kick off the UI Design phase of the project, I worked with the developer to outline a quick list of brand adjectives for Dayling:
After developing the brand logo based on these adjectives, I created a style tile so I could discuss the general visual direction of the app with the developer before starting on my final wireframes.
I went through multiple cycles of feedback and iteration with my mentor to arrive at my most recent set of wireframes.
The biggest challenge with these wireframes was striking the right balance in tone: I wanted to create a UI that was playful and engaging without overwhelming the user or distracting from the core content of the challenges.
I plan to continue working on these designs as the developer moves forward with building the app.