Voxy Word Library
About Word Library Project
For the glossary component of Voxy’s language learning platform, I worked closely with product management, pedagogy stakeholders, and front-end development to create a Word Library feature where our students would be able to review the vocabulary encountered during their lessons.
Voxy is a language learning platform that teaches English as a second language with real world content like news articles, unscripted dialog, and video clips. Each Unit is comprised of a certain number of Lessons created from this content. Students may have several active units at any given time.
Lead designer on a small cross-functional team with one developer and a product manager.
Strategy, sketching, flows, wireframes, interaction, visual design
Defining the Business Need
I believe every project needs to start with measurable and achievable goals and everyone on the team needs to agree on what those goals are. These goals might come from anywhere – senior team, team leaders, individual contributors, board members, etc. I don't always need to know where it comes from as long as myself and the rest of the team can understand how this goal supports the company's objectives.
Interestingly, we had avoided adding a glossary feature to the product based on a recommendation from the Pedagogy Team that rote memorization and reviewing vocabulary words out of context was a poor use of time and provided a false sense of progress with language acquisition.
The glossary was finally prioritized at the request of the board/investors.
In addition to business goals and user needs, we want to identify any known technical constraints, needs, or requirements. By establishing this boundary upfront we can quickly identify new stories that need to be discussed, scoped and prioritized as they arise.
I worked with one of our senior engineers to uncover all of the possible word attributes we could surface on the front-end. This ranged from word dependent information such as ‘part of speech’ to student specific information such as ‘number of times exposed’.
Understanding User Behaviors and Needs
When the team understands what user needs are motivating a particular behavior, we can predict with more certainty whether or not the solution we provide will actually trigger a behavior change that can move the target metric.
Our kickoff presentation stated that 40% of customer service feature requests were for a glossary or dictionary.
I did a preliminary sorting of our available word attributes based on the following criteria:
Which word attributes are expected in a glossary? (Other apps, textbooks, etc.)
Which word attributes are unique to our product and/or could elevate our experience?
Looking back, I’m curious about those students who had reached out to customer service – how many wanted a glossary of the words they’ve been exposed to, how many wanted a way to study and retake their completed lessons, and how many wanted a translator or dictionary tool?
Know where the risk is. The best way to ensure that a company is investing resources in projects and features that will move the desired metrics, is to validate and invalidate high-risk assumptions as early in the process as possible.
Not all assumptions are bad or dangerous! In fact, the assumptions we make and design for are often the catalysts that can ultimately make a product stand out from the competition.
I wrote our assumptions on sticky notes and placed them on the High/Low Risk, Certain/Uncertain Matrix to determine which, if any, of our assumptions needed to be tested before starting the project. I used a different color for each type of assumption:
Yellow: Assumptions about the problem we are solving and if it is the right problem to be working on right now.
Pink: Assumptions implied by our ideas to solve the problem(s).
Green: Assumptions around our ability to turn the solution into a working product.
Risky Assumption #1
For this project, one of the riskier assumption we had was around implementation – We assumed we would be able to generate, load, and display all of the data for each user’s list within a reasonable loading time. This is risky because a page that takes too long to load or is too bulky to use, is not a successful feature.
At first thought, the test for this could be simple – look up the range of vocabulary words for all users and see how long it takes to load. The problem with this is that we had not yet decided upon the data that would be displayed by default, so a test of this sort would not be conclusive at this point in the project.
It so happens that in this case, a test isn’t actually needed. This is a very common assumption and there are several interaction patterns commonly used to address this concern.
Pagination: Many search engines and e-commerce sites use pagination.
This solution works well when the user is potentially interested in each list item – ex. Amazon
’Load More’ Button: Load a set number of items and place a call to action ‘Load more items’ or ‘Show All’ at the end of the list.
This solution also works great on mobile – ex. LL Bean
Infinite Scrolling: The items load/refresh as the user scrolls down.
This solution works well when the user is enthusiastic about the content – ex. Facebook Newsfeed
Risky Assumption #2
Sometimes a solution assumption will imply an implementation assumption. When this happens, the placement of each assumption on the matrix could vary, so they need to be represented on separate sticky notes.
Solution Assumption (not risky): We assumed that when reviewing vocabulary words, our students would want to see how well they know the each word based on lesson performance.
Implied Implementation Assumption (very risky): We can create a word mastery attribute that is useful to all students.
Determining how to calculate Word Mastery was an entire 'project within a project' with its own needs, assumptions, and design. In the end we settled on a combination of variables such as right/wrong answers, frequency of exposure, difficulty of word, and depreciation over time.
Sketching for Speed
Rapid visualization of ideas can generate immediate feedback from team members and help to build buy-in from stakeholders early on in the process.
Some of the high level concepts explored with sketches for the glossary project included:
• Information organization – Prioritization of word attributes
• Interaction patterns – Creating an experience that was cohesive with the existing product while being appropriate for the user's needs
• Project scope – Having visuals to communicate the details of the project enabled more productive conversations with the engineering team and allowed better upfront timeline estimations
Dot voting can be used at anytime during a project to quickly align expectations, gauge understanding, gather feedback, and allow team members to voice their opinions.
I noticed some tension building within the team around which word attributes needed to be included in the glossary.
I decided to run a very simple asynchronous dot voting exercise that would allow discussion within the team without needing to take up anyone's time in another meeting.
I put each attribute on a sticky note and organized them on the wall.
I put out some sheets of dot stickers and simple instructions reading:
"Vote for the word attributes you believe are most valuable to display in the glossary.
Use GREEN for ‘Must Haves’ and ORANGE for ‘Nice to Haves’."
Dot voting can be used at anytime during a project to quickly align expectations, gather feedback, and allow team members to voice their opinions.
This type of decision should be made based on the user’s needs, not the democratic opinion of the team.
The exercise was used in this context to allow the team to voice their opinions and to encourage the team members with minority opinions to make a better case or put it to rest and move on.
Flows and Maps
Before I open Sketch or Illustrator to start making a wireframe, I want to organize my thoughts and outline a plan.
- Who are the users
- In what context is the user interacting with the product
- User motivations
- Site map of possible paths to reach destination
- Capture all of the possible interactions, decisions, states, etc. for each action on the page
The purpose of this exercise is to think through each of the possible actions on the page so that I can breakdown how each element behaves for all of the possible scenarios.
Wireframes for Search Functionality
By separating out each action/task into its own wireflow, feedback sessions are more likely to stay focused on one interaction at a time.
Below is a sample of some questions and decisions I want to address during the wireframe stage for ‘Word Library – Search Functionality’
Type of search
• Filter as you type OR
• Type and submit
• Partial Word Search – display all words that contain string or only exact matche
• Single Letter Search – If I search for a single letter, should the search return all words containing that letter or only words that start with that letter?
• Can a user refine results?
• Can the user start a new search without resetting/clearing the results?
• If so, does the new query search all words?
• Is the search bar persistent?
In my ideal process, Visual Design should be a straightforward application of styles from a living style guide or pattern library.
New elements should be styled in context of the product as a whole, not just the specific project, to ensure brand and interaction consistency.
The visual design of the Filters box was an adaptation of the 'Tile' style being used in various places such as the Performance Page and the Guide Page.
The word library had a pretty quiet release. The Pedagogy Team didn't want to bring too much attention to it out of concern for distracting students from the more effective learning that occurs during lessons and tutoring sessions.
The students went wild for it – we had more appreciation emails come into Customer Service than we had for any previous feature, update, or fix!