01
INTRO
Initial Assumption / Problem
"I learned the wrong definition for the test!"
"Learning new vocab can be so laborious."
Having a crowd based flashcard / vocabulary app can save time for those looking to study a subject. But how do we know the terms other people provide are correct? What if we need a more flexible method of learning? The story begins here...
THE GOAL
To create a crowd-sharing flashcard native app experience with focus on validation and alternative styles of learning.
MY ROLE
As UX / UI Designer, I was responsible for the creation of all elements from conception to final design.
TIMEFRAME
1 month
TOOLS
Don't underestimate the seductive power of a decent vocabulary.
02
DESIGN PROCESS
Design Methodologies
User Needs
User Interviews
Doing / Thinking / Feeling
Assumptions
Competitive Analysis
5 W's
Proto-personas
User Stories
Job Stories
Problem Statement
Hypothesis Statement
User Flows
Design Brainstorming
Low-fidelity Wireframes
Mid-fidelity Wireframes & Prototypes
Design Iterations
Usability Testing
User Testing Validation
Design Iterations
03
EMPATHIZE
Exploring the Problem Space
“Flashcards give your brain a very quick way to check if you got the answer correct. Grading your own work is an act of self-reflection which deepens memory. Scientists refer to this as metacognition." - E. Barry
Why?:
A Competitive Analysis was chosen to explore the current leaders in the market and learn their strengths and weaknesses. This was helpful in learning functionalities that are important to include as well as points of frustration to avoid.
Three questions were used during this competitive analysis:
-
Is the app useful?
-
Is it easy to use?
-
Does it accomplish the users goals?
As indicated by app usage and popularity all three apps scored well and provided valuable insight as to what works well in the app space, however they also made known some frustration points.
Successes:
-
Simple & customizable
-
Easily find decks to study
-
Easy editing
Frustrations:
-
Timing scheme difficult to understand
-
Poor UI: HTML is shown when editing in mobile app
-
Can't be sure terms are correct
Takeaway:
In addition to the collected successes and frustration points, the following initial hypothesis was developed through the 5 Ws:
Who - The app should allow for a wide variety of users who are at least at a reading level.
What - A mobile application focused on the learning of new vocabulary
When - 2 learning models: focused 10-20 minute sessions, and a notifications appearing throughout the day. The notification method will show 3 flashcards at a time at designated times throughout the day.
Where - depending on model - either throughout the day at random locations or when the user has time - on the subway, lunch break, study hall, public spaces where mobile data / wifi is available
Why - to enrich and serve users who are seeking higher learning
04
DEFINE
Research Goals
1. To validate / disprove initial hypothesis and calibrate app niche according to users needs.
2. To discover how users typically use flashcard apps and what learning styles they like to employ.
3. To uncover further important functionalities as well as frustrations and pain points in the apps they currently use.
User Interviews
I conducted user interviews with three individuals of different backgrounds and ages to discover their current method and environment when learning, reasoning and experience, frustrations and successes as well as a walk through of the steps they go through when learning a new word.
Proto-Personas
Proto-personas were then constructed to better distill and clarify this information as well as to define behaviors, needs and goals. Going forward this was an important deliverable to have on hand to deepen the connection toward users.
Why?:
Because of time / bugetary constraints, a single data collection method was used. User Interviews were chosen as qualitative data would have more impact in deepening the connection with users. Proto-personas, rather than complete personas were chosen to better understand and design for users within these constraints.
What do users do / think / feel?
User Interviews revealed the following:
I’m Doing...
-
Writing things down helps
-
Using Duolingo
-
Using workbooks
-
Will work on repetition / exposure
-
Subconsciously works on concepts while doing non-thinking activities
-
Google terms then look them up in a dictionary
I’m Thinking...
-
Frameworks are helpful
-
It’s best done through interaction
-
Cognates and Latin roots help. Also Chunking
-
Vocab is mostly rote memorization
-
Concepts need to set in through the subconscious
-
I don't like being interrupted during the day
-
I don’t like duolingo because they are not straightforward with prices
I’m Feeling...
-
I like flashcards / immersion / conversation /Duolingo style
-
I like quiet study or white noise
-
Being tested at the correct level is hard
-
Long words were difficult
-
Interactions are more enjoyable when further knowledge is gained
-
It is an issue for me when apps don’t give you the price up front
Takeaway:
A major finding was that all research participants preferred not to be interrupted with vocabulary throughout the day via notification. Because of this finding, the proposed notification method was dropped and focus given to the validation model. A Proto-persona was developed as a guiding light going forward to ensure that all future methods and steps empathize with users and more closely align with their needs, goals and behaviors.
For a closer look at Jonathan's persona and his behaviors, needs and goals click here:
PROBLEM STATEMENT
"Lexify" users need a customizable and verification based vocabulary/flashcard app because they want to enrich their lives and deepen their knowledge.
We will know this to be true when we see customer conversion and they are able to fulfill their learning needs in a timely manner.
05
IDEATE
Getting from A to B... and sometimes back again.
Why?:
User Flows were developed to better understand how users can best traverse the app and complete their personal goals, and to avoid designer mis-steps.
.png)
Takeaway:
User flows were particularly helpful in getting a birds-eye view of the application structure. It helped uncover necessary options in card-creation and card-validation methods that were not thought of during brain-storming. If this had not been uncovered during user flows, elements would need to have been redesigned further on in the design cycle.
06
PROTOTYPE
Low-Fidelity Wireframes
Takeaway:
After multiple ideation sessions, a fact-checker functionality was developed as the validation model to ensure crowd sourced cards are correct.
Mid-Fidelity Wireframes
Takeaway:
Further refinement was made developing the mid-fidelity wireframes. The navigation bar remained a flat hierarchical structure, but was expanded to include "Decks" so that users can more easily access their downloaded and created card decks. Further thought was made into how the fact-checker validation system might integrate into the interface with external sources.
"Pay attention to what users do, not what they say."
-Jakob Nielsen
07
TEST
Finding weak-points...
Why?:
Usability Testing was conducted with a mid-fidelity functional prototype in order to save time and money before creating and testing with high-fidelity wireframes, and to find areas of improvement.
For the Complete Usability Test Report click here:
Takeaway:
Usability testing revealed areas in need of improvement, most significantly the onboarding process. The previous flow led to confusion once users completed log-in. In lieu of a "pre-boarding" process where functionality is laid out before login, a post login "coach-marks" onboarding process has been implemented. The re-designed onboarding process can be found in the Usability Testing Report above.
08
FUTURE STEPS
High Fidelity Prototype
A high fidelity prototype is in the works! Please check back or drop me a note if you would like to see some of my high-fidelity work.
09
Conclusion
Retrospective
Flexibility to change directions midway. After uncovering data that disproved the initial hypothesis, I switched gears and was able to focus on aspects of the app that are really important to users, and remove the things that frustrate them.
What went well:
What didn't go well:
Some data is better than no data, but I still would have liked more data to further confirm / negate the derived hypothesis. Specifically, quantitative data via surveys would help define the target user more clearly.
Usability questions tended to be too specific in nature. More general questions that let the user take the steps they feel are correct will better serve testing in future iterations.
Improvement areas:
Thanks for stopping by!