One of the trickier parts of designing interfaces for kids is that “expertise” goes out the window every 2-3 years. A 10-year-old today that has grown up navigating the Web via mouse has drastically different expectations from a 4-year-old trained on iPad games, let alone a 30-year-old designer reared on 14.4K modems and dial-up bulletin boards. This makes UI/UX design quite challenging – one has to be able to look beyond their own (broad and outdated) expectations and understand how a digital native might see their interface, all while identifying the visual metaphors and conventions relevant to an audience with very limited experience/memory.
Example: Toontastic is built around the simple idea of recording your stories through play. As such, the early UI designs featured a big red RECORD button and a big green PLAY button, which we (having grown up with Fisher-Price tapedecks and recordable VCRs) took for granted to be universal conventions. WRONG. Through play-testing a wide range of ages, we observed a pattern: kids roughly 9+ had no problems navigating the UI, but younger children had no idea what a “record button” was – the first wave of a generation of kids raised on DVDs, CDs and other non-recordable media. We quickly swapped out the “conventional” buttons for what you see today, giant blinking green/red START/STOP buttons at the top of the page. Crisis averted.
Question: So if there are no real “experts” or “gurus”, then how do I create a great kids product?
Answer: Test it. Relentlessly… and here are 5 tips we’ve learned along the way:
1. Beware Kitchen Research: Partner with a Children’s Museum. Designers should be testing at every turn, but beware the appealing convenience of testing with your kids, your neighbors, or the local school. Repeated exposure breeds familiarity, which in turn leads to false positives (i.e. last week your kid couldn’t figure it out, but it’s ok this week thanks to that change you made… or so you think). Conversely, museums have new visitors every day! Build a symbiotic partnership with a local children’s museum and test there – your “first time user experience” will improve dramatically.
2. Paper Prototypes: Not For Kids. Conventional wisdom has it that designers should burn through as many iterations as they can as quickly as possible, which makes paper prototyping a very helpful tool for User Testing. Young children, however, lack the A) experience/reference and B) cognitive ability to grasp the abstraction of paper prototypes, which can lead to hazardous testing results. A good alternative (still fairly low-fidelity, but far less abstract) is to mockup interactive wireframes on-device using tools like PictureLink and InVision.
3. Dyads = Collaboration = Chatty Kids. The “Talk Aloud Protocol” is an old User Testing standby and a wonderful tool for getting users to explain their actions, expectations, and questions as they navigate through an interface. Asking a kid to do this, of course, is a lot like getting them to tap their head and rub their belly – tricky to say the least. Thankfully, there’s an easy workaround: group kids in pairs to test your software and you’ll find that they work through it collaboratively, chatting it up as they go.
4. Zip it. No, seriously, don’t say a word. There are few things harder for a designer to do than stand back and watch a user stumble through his/her interface. You’ll be tempted to gesture, provide a few hints, maybe even prompt with a question. Don’t. Let ‘em squirm – and take copious notes on every inclination, misstep, and dead-end along the way. As painful as it is, this is BY FAR the most valuable information you’ll get from user testing. Barring miraculous advancements in cloning and/or teleportation technologies, you won’t be there to help the user once your product ships, so it’s better that you’re not there now.
5. Make ‘em cry. Yes, you read that correctly… now let me explain. One of the hardest questions in any development cycle is “when is the product ready to ship?” You could go on forever trimming and tweaking, of course, but the law of diminishing returns (and microeconomics) dictates that you ship your product once you achieve maximum UX through minimal development. How can you tell when you’ve hit your UX goal? It’s actually quite easy: 1) estimate the timeframe for your ideal User Experience (5 minutes? 10 minutes? A half-hour?), 2) cut the user test short just a few minutes shy of that goal. If the kid walks away ambivalent, keep building. If he/she seems upset, you know you’re on to something. If, as sadistic as this may sound, a tear is shed… well, my friend, it’s time to shut ‘er down and SHIP IT!