View the original post
Some days, I feel a bit like Billy Madison. A grown man walking into class with a bunch of six year olds. Sitting cross-legged on the floor listening to the teacher. Trying valiantly to fit my man-size legs under a kid-size desk.
Unlike Adam Sandler’s titular character, I’m not the moronic son of a hotel tycoon repeating school. So, let me explain why I’m doing this.
Remember when you were a kid?
Do you remember your first day of school? Do you remember the first time you used a digital device? What was your favourite toy or game when you were six years old? Could you explain why you loved it, what was so engaging about it?
Cool, those memories are going to be really useful if you want to create a product for children, right?
Except… you probably don’t remember all that well. Recall bias means that even if you 100% sincerely believe that you are sharing a true memory, you’re not. The wonderfully titled Catalogue of Bias explains, “Recall bias is a systematic error that occurs when participants do not remember previous events or experiences accurately or omit details: the accuracy and volume of memories may be influenced by subsequent events and experiences.”
Even if you do have a photographic memory, your experiences as a kid, especially your experiences with digital technology are wildly different from the experiences of a kid today. Your experiences are irrelevant at best, dangerously misleading at worst. Sorry.
To make a great product, you obviously need to understand your users. Especially when working with younger users (the audience I work with is aged 5–12) I’ve found by far the most valuable qualitative discovery method is ethnographic research. Simply spending time with kids in their natural habitat beats focus groups or lab tests every time. I work in edtech so I try to spend a lot of time in classrooms.
I’m a big fan of designing for ‘the bookends’ — that is understanding that no one is actually exactly average and designing for the mythical ‘average user’ is not helpful. If you can design a product that works for the users on either extreme of a spectrum, young-old, newbie-pro, confident-terrified, it is more likely to make the product better for everyone in between. Podcast 99% Invisible did a great episode on the problem of designing for the average, I thoroughly recommend it.
The company I work for, Makers Empire, makes “the world’s most fun and easy to use 3D design program”. It is designed specifically for elementary school-aged learners. There are big differences in what a 5 year old and a 12 year old can do, so I decided I needed to focus more on the younger end of our user base.
In the latter half of 2020, I was able to spend a double lesson each week for a semester with two combined grade 1–2 classes during their technology lessons. I met with their very helpful principal and two very accommodating teachers. We set a goal for the semester (make a flying machine) and mapped out a rough plan for the first few lessons. The teachers then stood back and let me jump in the deep end.
Here is what the students taught me:
1. By first grade there are already massive differences in students’ digital literacy
I fully expected there to be a range of literacy levels and I suspected that the amount of text in our app might be a problem. We have a built-in text-to-speech tool, but even then, comprehension can be an issue.
What I didn’t quite expect was some kids to stare blankly when prompted to ‘click’, ‘tap’ or ‘swipe’. Words like “open” and “button” are common to even the most casual app user, but mean something else to a six year old who isn’t.
Key learning: Design on-boarding for very young users assuming zero prior knowledge. Really, zero.
2. There is also a big difference in students’ ability to cope with ambiguity
Before starting any task, I’d try to set the scene through telling stories and asking questions to ensure the whole class had a shared understanding of the context of what we’re working on for that lesson. I’d ask follow up questions to verify they understood the concepts and to give them a chance to relate the concept to their own experiences.
I’d then try to rally enthusiasm with a question like, “Okay, are we ready to try?”, to which I’d hear a cacophony of replies, “Yes! Yes! Yes! Yes! Yes! Yes! No. Yes! Yes!”
Wait up… who said “No”?
As the majority of students started on their task for the lesson, I’d quietly talk to the reluctant students. I found that they mostly understood the context and the task, but the common complaint was, “I don’t know how to do it”.
“That’s okay, we’re all still learning” I’d reassure them, “and I can help you if you get stuck. Would you like to have a try?” — “No.”
I was surprised to see such a deep aversion to dealing with uncertainty had already formed by such a young age in some students. A small portion of kids when given a bunch of blocks and asked to make a tower would freeze.
If we’re designing for the bookends, as I believe we should, we have to try to understand the reluctant learner.
What is preventing them from making a tower I wondered? Fear of failure is part of it, but I sensed there was something else going on. Maybe it is a lack of imagination, a lack of initiative, a lack of life experience, a lack of motivation, something else or, most likely, a combination of all those factors. It became very clear that these kids will not just ‘figure it out as they go’. No amount of prodding or time will help because if the first step in a task is unclear to them, they simply won’t ‘go’ anywhere.
Reflecting on this experience, I think these young learners’ responses to challenging tasks can be mapped on two axes:
- Attitude to risk, and
- Sequencing skills, i.e. their ability to forecast the steps required to complete a task.
In these particular classes I roughly grouped kids into three sets when faced with any ambiguity:
- 20% are flying — they ‘just get it’ and will excel,
- 60% are forming — they will try and produce something with varying degrees of success, and
- 20% are frozen — they will really struggle to even start.
The goal is clearly to help those who are frozen start making progress, and at the other end, allow those who are flying to extend themselves even further.
Design activities that provide a clear path for those that need it, but are open-ended enough to excite and challenge those who will push a concept and ‘add their own spin’ to a task.
By the way, good teachers do this all the time, it’s called ‘differentiated learning’ — definitely try to hang out with teachers if you’re designing anything for kids!
3. Kids have tiny fingers
We were testing onboarding activities that we hoped would improve new users’ mastery of the basic camera controls required to use our app. We’d reduced the amount of text to a bare minimum, and we had a text-to-speech reader to help users with lower literacy levels. We had animated hands on-screen demonstrating the correct gestures; tap, drag, pinch. But new users were still struggling.
One of our developers observed that some of the kids were actually following the directions on screen perfectly well, but noticed that their fingers were just so tiny that sometimes a two-finger gesture registered as a one-finger gesture on a touch screen. Our one finger to rotate, two fingers to pan camera controls were never going to work. We made a simple adjustment to the on-screen hand icon; rather than having the pointer and middle fingers touching we have them slightly open in a V — and touch screens now recognise that it is in fact two little fingers dragging.
It’s easy to forget physical constraints when designing digital products. You have to perform real user tests! TEST, TEST, TEST!
4. Confirmed: icons don’t have to be literal to make sense (to kids)
If you’re designing an icon for “paintbrush” you should probably use an image of a paintbrush and “shopping cart” should probably be a shopping cart.
It gets a lot trickier when you need to represent more abstract concepts. How do you visually represent software functions like “import a file” to a first-grader? An arrow going into a box? Boring! Plus, it looks a lot like “download”, which also sometimes looks a lot like “save”. Speaking of “save”, these kids will never see a floppy disk outside of a museum, so that’s no good.
The problem with a lot of standard icons, besides being repetitive and ambiguous, is that they often rely on a mental library of visual metaphors that young users just don’t have. They’ve never used a Xerox machine, so why would two overlapping rectangles mean “copy” to them? They’re learning mathematics, so they’ve definitely seen a “+” sign before, but it means “add two things together” to them, not “add something new”.
If in doubt, I like to use what I call the Nintendo Approach. There is no literal reason why a red mushroom should make your kart go faster, nor why a green turtle shell would be a projectile while a red turtle shell is a homing projectile. But through context, we quickly learn, and never forget, the function of these distinctive icons.
With that in mind, I used a sheep to represent “copy”. Some adults remember Dolly the sheep, the first cloned animal. The kids have no idea about Dolly, but they know from experience that clicking the sheep makes a duplicate. This was confirmed most clearly when I overheard a student berate his classmate “hey — stop sheeping me!”
Sure, there is an argument for teaching standardized icons, but there is also a strong argument for having fun!
Icons create a visual language and like written language young students are still learning how to put it together. It is more important to be distinctive than literal.
Thanks for reading.
If you’re interested in building great learning products and/or have great tips of your own, let’s talk! email@example.com