skip to Main Content

Best Practices for Designing iPad Apps for kids

A recent project for one of our clients required us to design and develop an iPad App aimed at kids from the ages 5 to 12 years old. This has been an interesting project, as we needed to consider the differences between how a child a uses an iPad compared to an adult or even a teenager.

During the initial stages of the project we researched into the best practices of designing an iPad for kids, below are some of the more important things we discovered.

  • From our research on the Web, we find that younger children, who have less experience with the Web, tend to read instructions more than children who are older.
  • Although many usability guidelines are the same as 9 years ago, we did find one major change since the first study: children today are much more experienced in using computers and the Internet. As a result, they’re not as subject to many of the prevalent, beginning-user problems we found in our first study. These days, kids are on computers almost as soon as they can sit up and move a mouse or tap a screen. It’s now common for a 7-year-old kid to be a seasoned Internet user with several years’ experience.
  • Readability level Each user’s grade level 8th to 10th grade text for broad consumer audiences
  • Font size 14 point (young kids) 12 point (older kids) 10 point (up to 14 point for seniors)
  • Physical limitations Slow typists / Poor mouse control
  • Animation and sound Liked
  • Advertising and promotions Can’t distinguish from real content
  • At a minimum, you must distinguish between young (3–5), mid-range (6–8), and older (9–12) children.
  • Each group has different behaviors, and the users get substantially more web-savvy as they get older. And, those different needs range far beyond the obvious imperative to design differently for pre-readers, beginning readers, and moderately skilled readers.
  • We found that young users reacted negatively to content designed for kids that were even one school grade below or above their own level. Children are acutely aware of age differences: at one website, a 6-year-old said, “This website is for babies, maybe 4 or 5 years old. You can tell because of the cartoons and trains.” (Although you might view both 5- and 6-year olds as “little kids,” in the mind of a 6-year-old, the difference between them is vast.)
  • it’s important to retain a consistent user experience rather than bounce users among pages targeting different age groups
  • lack the skills needed to identify advertising
  • The main predictor of children’s ability to use websites is their amount of prior experience.

GUI’s not for kids -

  • The contrast between these components and the rest of the app couldn’t be more stark. Every other page of the book features large images kids can tap and and full pages they can swipe to turn like a book.
  • Press and hold to tap - In order to better accommodate the dexterity of small children, applications designed for kids should consider treating press and tap gestures the same as tap gestures. Chances are a kid inadvertently has another finger touching the screen most of the time.
  • Hold the encore - Many applications designed for kids don’t check to see if an action is in progress before they start it anew. So when a child taps an image that plays a sounds then taps it again, the same sound will play over itself. Tap the image a few times and you have the same sound overlapping and echoing to the point of distortion.

  • If possible, apps should check to see if an action is already in progress rather than running multiple instances of the action at once. Another example of some forgiveness in the UI.
  • So instead of referencing a pattern that has only come about through software development, look around and see what real-world interactions can map naturally to your product. This doesn’t just apply to kids either. By referencing a real-life experience faithfully enough you can make on-screen interactions feel as natural and familiar as the real thing.

  • When designing for toddlers and preschoolers I recommend creating a “childproof” navigation interface to prevent children accidentally brushing or touching the menu while using the application.
  •  If the child presses once without any rewarding feedback, he is not likely to press again.
  • Another example is a banner type graphic that you must “pull” (swipe down) in order to see a menu, or even basic linear navigation flow without a menu to allow a focus on the tasks at hand with no unwanted interruptions.
  • For an inquisitive child, a swipe is sometimes a clumsy press or an attempt to move things around the screen; “next” and “back” buttons to change a page would be more effective in this case especially when combining other interactive elements on the page.
  • Additionally, the iPad Home button and the Android Menu Bar are not childproof, as they are always visible and invite a curious touch. Apps for kids should allow a quick return to the application in case these buttons are pressed. For easy recovery, avoid displaying a logo splash screen and menu each time the application starts.

  • Affordance Is King - Give the elements in question a characteristic that indicates they are touchable. The Disney Puzzle Book apps do this really well. For example, in the Winnie the Pooh Puzzle Book app, the honey pots wiggle around to show the user that they need to touch them in order to collect them.
  • Both of these interactions are valid solutions, but because swipes can be tricky for tiny fingers and the gestures usually require some precision, the arrow approach is much better for kids.
  • Also, the entire bottom part of the screen is a hot area and needs to be avoided. Kids constantly touch that part of the tablet by accident, which makes accidental pagination inevitable if the controls are placed there.
  • Speaking of the bottom part of the screen: don’t put any interactive elements in the bottom part of the screen — especially menu actions, which are not important anyway once a child gets going with the app.
  • More importantly, it uses a two-touch method to bring up the menu. The menu icon is semi-transparent in its normal state. One tap removes the transparency, and a second tap brings up the menu. Although not foolproof, it’s an excellent way to avoid accidental taps.
  • I’m looking at you, Talking Tom Cat. A lot of apps do this, but Talking Tom Cat is the absolute worst. The screen is a landmine of carefully placed icons that lead to accidental purchases

  • Barriers to use and learning - App’s unclear, unfriendly or unresponsive user interface, game play that lacks reward or feedback, obscure game objectives,  too many distractions, Apps that lack “palm rest”, where buttons trigger themselves if accidentally touched within play area
  • Appeal derives from - No-fail environment, Child determines pace, Learning by doing, Tool use, Endless possibilities & outcomes, Children can build on what they like to do, Children’s interest determines use.
Back To Top