Prompt
At the beginning of each new semester or school year, teachers are faced with the challenge of remembering names for a large number of new students. Design an experience to help an educator match faces to names, with the goal of shortening the time needed to reach complete un-aided accuracy.
The assignment was scoped to 8 hours, so I worked on it over this past Sunday. I opted to make a mobile app for these reasons: - To exercise Material Design patterns as requested. - The assumption that a memorization tool needs to go with the teacher, and not bind them to a location or platform.
Questions
I generally start my design process in text, asking whichever questions come to mind, and jotting down any ideas or assumptions I find. This helps me uncover a larger range of opportunities than when I start projects visually. On reading the prompt, there were a few questions that come to mind immediately.
- What are the most effective methods of memorizing things? What can actually result in un-aided accuracy?
- What kind of teachers are going to use this? K-12? College? Do they have major differences in how they’d utilize something like this?
- Who drives adoption? Do teachers do this for their own benefit, or do schools encourage it?
- Is memorizing names enough benefit in itself for teachers to invest time in this? How much time are they willing to invest?
- What are the benefits of memorizing names? Do teachers who do this show more success?
- How do we populate student names and faces? Are there opportunities to integrate with learning management systems or school administration software? Otherwise, where can this data come from in a way that’s convenient, realistic, and ethical?
- How many students on average does a teacher have? What kind of quantity do we have to design for?
- How long do teachers have to memorize these names? How long do they currently take? What’s an improvement to that?
- What is the scope of this project? Are resources, availability, and timeline something we need to consider, or is this unbounded?
- What are we optimizing for? What does success look like?
If you want, feel free to explore my full unpacking of the problem. It has some things that didn’t make it in.
How many students does the average teacher have?
This one’s important, because it speaks to the nature of the problem. Memorizing ten student names is very different from memorizing hundreds, and calls for a different solution. If a teacher has a hundred students, how often do they cycle? Do you always have to commit a hundred new names to memory, or do you already know forty? Do teachers need to know the names for all their classes, or just their main ones?
I couldn’t answer all of these within the timeframe, but the number of names a teacher needs to memorize on average is key, as it helps us determine what the most appropriate method of memorization is.
Most of the academic data I found centered around student–teacher ratios and class sizes. These sources failed to account for the fact that most teachers have more than one class. My admittedly limited research took me to a number of online sources that answered the right question. Note: with more time, I’d conduct actually thorough research and interview actual teachers as soon as possible.
On Quora, teachers discussed a low of 125 and a high of 216 students per year.
On Yahoo Answers, teachers cited an average of 5-6 classes with 10-30 students each, so 50-180 students per year.
This 2012 article says as many as 275 students.
The amount of students per teacher seems to vary wildly between districts and schools, but across the board it’s much higher than I expected.
What’s the best way to memorize something?
Memorizing names has come up in the past for me. Around two years ago, I spent a DigitalOcean hackathon developing a trivia game for new employees. This would scrape our company’s about page and ask visitors to match names to faces (prototype available on desktop view).
Play around with the prototype:
This ended up being a lot of fun for many veteran employees, who competed with each other for high scores, but less successful at its intended use case. It just wasn’t that good at helping people memorize faces and names.
The interface in itself wasn’t going to help people remember, it was the method it employed, and this was the wrong method.
The prompt for this assignment is to help teachers reach un-aided accuracy. With a high of 275 students, that’s asking a lot. I needed to find a proven method of memorizing a large amount of information quickly. This method would then inform the design process.
Dominic O'Brien’s memory principles
Dominic O'Brien is a professional Mnemonist, which, apparently, is a thing. He won the World Memory Championships 8 times, and he has a Guinness record for memorizing a sequence of 54 decks of cards shuffled randomly. He’s also written 15 memory-related books, one of which is specifically about never forgetting names and faces. When it comes to memory, he knows his stuff.
O'Brien lists 3 principles of memory:
- Association: The basis of all memory.
- Location: Mental images placed in specific locations are them easier to recall.
- Imagination: Exaggerating your mnemonic images make them more effective.
He then goes on to describe a few methods of remembering names, all of which are one form or another of forming strong associations that can will help surface the name when you need it.
Some of my initial ideas:
- Allow teachers to draw on their student’s photos to create powerful, exaggerated mnemonics.
- Perhaps more realistically for an MVP, allow teachers to add a text mnemonic to each student.
- Considering this is an app targeted towards teachers, it’d make sense to educate teachers within the app on how to structure their mnemonics to best memorize names. Teachers value education, so I’m making the assumption that they also value learning.
Spaced repetition
When I thought about memorizing a large amount of information in a short period of time, my mind naturally wandered to college exams and their natural companion—flash cards. I decided to look into methods of obtaining knowledge quickly and maintaining it, and came across the idea of spaced repetition.
According to Wikipedia, “spaced repetition is a learning technique that incorporates increasing intervals of time between subsequent review of previously learned material in order to exploit the psychological spacing effect.” The spacing effect “suggests that ‘cramming’ the night before an exam is not likely to be as effective as studying at intervals in a longer time frame.” Cramming is better than spaced repetition when you need to remember a great deal of information quickly, and you don’t care whether you forgot it the next week.
Since teachers usually need to remember student names over a long period of time, a semester or a year, a spaced method seems more appropriate in this instance. For reference, this is also how Duolingo teaches languages.
One popular method of spaced repetition is the Leitner system. This involves sorting flashcards into groups according to how well the learner knows each one. If you guess right, the card moves to the next group, which has a lower frequency so the card won’t show up as often. If you fail, it’s sent back to the first group.
This system can help people learn quickly and efficiently. It shows information just frequently enough for someone to memorize it. You spend most of your time focusing on things you still don’t remember quite well.
Anki, an app that leverages this system, actually surfaces how long a card will be snoozed.
In this case, as with our app, an intuitive interface is not the critical factor in memorizing something. The chosen algorithm, and its alignment with proven phsycological studies, can make or break this app’s utility.
Note: keep in mind I only had a day to research and design this thing. This is not what I would call a deep dive into memorization.
Introducing Google Cue
I had a set of criteria for a name. It had to incorporate some aspects of education, teaching, faces, repetition, memorization, or a combination of these. It had to be catchy and also, ideally, feel like something that would fit in the Google ecosystem.
I landed on Google Cue. A cue is “a thing said or done that serves as a signal to an actor or other performer to enter or to begin their speech or performance.” Since this app incorporates custom mnemonics, or “cues,” the name felt right.
Teachers are responsible for the data
With no stakeholders to confirm a direction, some of my initial questions required some educated guesswork. I made a few decisions regarding how to proceed. The first of these was regarding the app’s data source.
I realized we wouldn’t be able to obtain student photos automatically from the schools. There are three reasons for this:
- Not all school have their student images on file. This app should be useable by any teacher, so reliance on school’s for this information is a no-go.
- Even if schools did have access to all student photos, they function a lot like governments. They move slowly and they’re beholden to a lot of rules that partners have to work within. In this case, I doubt that privacy policies would consistently allow for our app to use student photos.
- Perhaps most importantly, LMSs and legacy systems are difficult to work with. They usually require a lot of technical overhead to plug into, and different systems will require different integrations.
All of these reasons conspire to create a new gap in the flow that we have to solve for: student data population.
Considering a teacher can have up to 275 students, this experience would have to be streamlined, or teachers would never make it past onboarding.
Adding names
I hate typing on my phone. I can’t imagine how frustrating it would be to have to type out hundreds of names at a time. This level of friction would surely hurt conversion and stop teachers for getting any value out of Cue.
Instead of having teachers do this, I opted to send them to the nearest keyboard.
This link would leverage Google’s ecosystem and drop teachers on a synced Google Sheet with further instructions on how to add students and divide them into classes (more on this later).
On this screen, teachers will be able to easily import any data format containing their students’ names. If they don’t have access to this data, they can still type the names out with the convenience of a full keyboard.
Modern web technologies allow for real-time syncing between apps. When they’re done importing their data, it should immediately be available within the app.
Note: to be clear, I don’t think requiring teachers to type names in is ideal, but sometimes you have to work with the hand you’re dealt.
Adding photos
I’m making the assumption that most schools won’t provide access to photos for students, or won’t release those to teachers due to privacy concerns and technical constraints, so the next step to populating the app is matching photos to student names.
Now, remember, this could potentially require teachers to take just under 300 photos of unenthusiastic students. This is still a monster of a task, so it has to be streamlined.
At this point, you may be asking yourselves, “why force the teachers to work so hard for these photos if the app could just send students requests for their pictures?” First, remember that some of these teachers teach primary and middle school, and imagine how inappropriate parents and faculty would find a request like this. Then, imagine what an average 15 year old would send back.
I chose to divide students into separate classes in the previous step in an effort to break this undertaking into smaller, digestible tasks. Now teachers can focus on populating one class at a time.
When they start the process for a class, the app will go through student names alphabetically. Initially, it opens up a camera with the first student’s name
- The teacher taps on the camera frame to take the photo.
- The teacher taps on the frame again to confirm the photo.
- The app automatically jumps to the next student, keeping the camera open.
What this results in is a process that takes two taps to populate a student, or 60 taps to populate a class of 30. I don’t see this as being a fun task, it could even be miserable with certain classrooms, but that won’t be due to the design.
Another thing I might add to this is an “on deck” area of the next student, so the teacher can be more efficient in managing the process in the actual classroom.
You’ll see that the design of the student cards here matches the design of the flash cards in the memory flow. This is in order to establish a mental model: the cards being populated here are the flash cards, and inversely the flash cards you’ll see later are the cards you just populated. A student always looks the same within the system.
There also needed to be a way to manage students after the fact. Some teachers would miss students on the first go (if they were absent or having a bad hair day). Some students would join classes later, and some would leave. It didn’t make sense for a teacher to have to memorize irrelevant students, or miss out on new students due to thoughtless constraints.
I divided the app into two sections:
- Memorize: go through the memorization flow, and see holistic progress tracking.
- Populate: add and manage student data, pending photos, and see more detailed progress tracking.
I wanted the populate screen to clearly call out which images were needed, and to give the teacher a sense for how they were progressing with each class. I explored a few possible layouts that would achieve both of these things gracefully. I ended up selecting the far right version for its simplicity and economy.
Tapping on one of these cards would animate it into an individual class page, where teachers could add, edit, or remove students.
Memorization
Finally, the most important piece to all of this. I took two things from my research into memorization: the effectiveness of spaced repetition, and the power of mnemonics. Cue combines them both into a powerful, streamlined flow.
Teachers already have enough on their plates. This process shouldn’t feel like a chore. It should be fun and simple. Teachers should be able to enter a flow state and go through a hundred names without noticing. That’s the only way something like this could be sustainable.
As such, where Anki surfaces the inner workings of its spaced repetition, Cue abstracts what’s happening behind the scenes. It just asks teachers if they remembered or forgot a student. No thinking necessary. We can message the app’s “smarts” to teachers via marketing, during onboarding, or on other pages of the app, but I feel like it could get in the way of entering flow state.
Teachers can also add “cues” (the custom mnemonics I mentioned earlier) for each student depending on how they choose to remember them. This is an area where we could help teachers craft better mnemonics through education. While researching this I discovered that Memrise does something similar. They have similar construct called a “mem”—which can be anything from a gif, to a sentence, to a soundbyte—and they provide tips on how best to craft these.
I haven’t designed the flow to add a mnemonic yet, but when viewing student flash cards, teachers will have access to their mnemonics.
Interaction prototype
I wanted to see how the memorization flow would feel, so I put together a Framer.js prototype and spent a while tweaking animations until they felt right. They’re still not quite there, for instance the mnemonic spring animation isn’t really in line with Material, and would be better as a more organic scaling animation. With more than a day, I’d invest more time in perfecting how this flow feels.
Open this page on desktop for a Framer.js prototype.
The prototype works best on Retina screens, using Safari. It may look blurry or too sharp on other screens and browsers. This is due to Framer limitations that I haven’t figured out yet.
The algorithm
The app should use the Leitner system as a baseline.
This system uses increasing levels of proficiency, which work like this:
- All cards start at proficiency level 1. Cards in level 1 are reviewed in every single learning session.
- Cards that are answered correctly move up one level.
- Level 2 cards are reviewed every 2nd learning session, level 3 cards every 3rd learning session, and so forth.
- If a card reaches level 5 and is answered correctly, it’s is deemed as memorized and retired.
- If you answer a card incorrectly, it’s moved all the way back to level 1 and you start over.
- My addition to this: if a mnemonic is used to guess the name, move the card back one level, instead of forward.
We divide the cards up into a number of easily digestible decks. Every day the app will provide its users with one or two learning sessions pertaining to specific decks that the teacher hasn’t seen for a while. It will prompt users via push notifications at times configured by them (settings page pending).
How many decks there are depends on how many students there are to memorize. The number of decks has to align with what we deem is a appropriate timeframe for memorization. Do teachers need to get this done within a week or two? Let’s show more cards per deck. Is a month good enough? Let’s make each learning session more digestible. We need more research to determine this.
The memorization method we pick can make or break the app, so after release we should test and monitor this method to determine how effective it is. With Google’s resources, we could conduct further research into optimizing an algorithm for this kind of memorization.
Some gaps
Considering the limited timeframe, there are a few areas in the app that I haven’t yet explored. For instance, the import flow for student data, the memorization dashboard, educating teachers on good mnemonics, the learning session history, the settings page, search, and so forth.
These sections could possibly uncover additional gaps, and result in more holistic changes to the app. But I’ll leave them for another time.
Wrapping it up
I still have a lot of assumptions as the foundation of this prototype.
- Teachers value education.
- People like to see their progress.
- Most teachers won’t be willing to spend a lot of time on this (most already have much more on their plate than they’re paid to deal with).
- Some teachers have hundreds of students to memorize every semester.
- Individual teachers are the main stakeholders for this app.
- Not every school can provide student names and photos easily.
- Not every student is technically savvy or has access to technology.
- Most data will be entered by the teachers using their phones and cameras. Data entry must be part of the app.
- This is an MVP.
The next steps would be to validate these and figure out whether this thing—or something like it—is worth making.
- How can we validate and test this? We’re Google, can we dogfood this internally before even having to test outside the company? What are the limitations to that? Since teachers are used to memorizing material, would their use be substantially different?
- How do we validate that this is actually worth building?
- How do we validate that teachers actually want or need this and that it’s worth putting our company time into?
- Assuming both of the above are validated, how do we get feedback rapidly and improve the product to make it past MVP?
- What are the most important areas for validation? (e.g. does it help them succeed in memorizing students vs. do they complain about uploading photos? I’d imagine the latter is less important if they see improvements in metrics such as student engagement or success.)
- Who are internal stakeholders, how do we get them on board, and how can we make quick headway?
- Is what we have here actually an MVP? Is there a smaller version of this that would be good enough for testing? What are the next steps for a prototype?
- Could we test with a fixed set of teachers and manually import classes for them so they don’t have to go through that process, and so we wouldn’t have to build an uploader or sync engine?
Needless to say, I take more time with actual products, but I hope this gave you an idea of how I think, and how I tackle projects.
Thanks for reading! 🎉
