Simplify, then add delightness: On designing for children

I’ve been building Kidz Fun Art (web, iPad & Windows) since 2021, so 4 years at time of writing. It’s a tablet optimized application intended to be used by children of all ages – my daughters were 3 and 5 when I started, and are 7 and 9 now, so I’ve seen how they use it almost daily at various ages. I’ve learned a few things about designing for their usability and how it differs from some more common patterns found in adult focused applications. Topics Covered Minimize Text Use If you want kids under 8 to use your app, find a way to communicate all its primary functions with as little text as possible. Text does not actually provide guidance to a large percentage of your user base as they can’t read it Text takes up valuable space that could be used for better graphics or aesthetically pleasing empty space Text is visually unattractive and off-putting to most children. In the image below, note that there is not a single piece of text. While secondary and tertiary features sometimes require text, do what you can to make all primary controls text-free. Adult focused apps often have menus where the user must know to hunt and peck for the features they need. This is not well suited to younger users. I’ve found that it works much better to design ways to co-locate tools with the objects on which they are to be used. For example, if a user wants to select and rotate part of the image, place the control for rotating directly on or next to the selected area, not far away in a control bar or menu. Place tools for manipulating objects directly on top of the objects, with large and obvious hit targets. Feedback from my in-house testers was that putting things like rotation controls on the border of a selected area (like most paint apps) was not a good affordance, whereas overlaying a circle on top of the object to be rotated was immediately obvious. If the available controls cannot be shown due to space constraints, find a way to hint at their existence in a way that does not require reading or tool tips. The image above shows my attempt at gently suggesting to the user that there is a menu hidden under each of these buttons if they click a second time. A key point for avoiding a messy UI that is overly noisy is to only show any given hint a small number of times, ideally just once. Mistakes should be easy to fix Kids make mistakes, they mess around and generally use the app in every way you never thought of. They are naturally inquisitive and will tap, drag, slap, spit on and high five the screen at any given moment. In all cases, but especially if they are creating content, you should try at all times to make any actions quick and easy to reverse (I need to better here, and my next mini-project is aimed at improving this for Kidz Fun Art). Some ideas: Have an undo button placed prominently, and a redo button of course. This means building to support a stack of states, which definitely complicates things, but your app will be far less frustrating with these. Use soft deletes, so the user can undo an accidental deletion. Nothing is more likely to make a kid never come back to your app than accidentally hard deleting something they’d spent hours creating and were about to proudly show their parents. This happened a year ago to one of my daughters, full on tears ensued and if it wasn’t their dad building the app that would’ve been the end of their usage of it. Safe to say I was up until 2am working on the fix, feeling like an absolute piece of shit. Don’t be that person. Clean up the soft deletes at some point. I tend to do this after a few days, by which time the child has likely forgotten all about it. No need to keep the data forever. It bloats local storage and is just better for privacy all round. Know when to involve an adult If you have features aimed at older kids, your app will likely have stronger retention and usage of more advanced features if you encourage the child to involve the parent at the right times. Use graphics as much as possible for these prompts, like in the example below. Once the user confirms that they are able to handle what comes next, it’s OK to use a bit more text than you normally would. To reduce frustration for the user, for any single feature, only request the help of an adult once. This will require you to store the fact that you did so on a per-feature basis either locally, remotely or both. Reduce the need for fine motor control Younger children’s motor control is not as developed as that of older children, meaning that if you want them to get as much value from your app as possible, you should try to find ways to provide that value without perfect finger and pen control. Some ways I’ve found effective to achieve this are: Large hit targets This is a pretty obvious one, all buttons and links should be plenty big enough for a child to tap with their finger. If you’re working on the Web, you can easily make the hit target on a button (or anchor tag) larger using CSS, without visually increasing its size. See this code example for one method of achieving this. There are other methods of achieving the same on other platforms, go forth and Google/Claude/ChatGPT (is that a verb?) them. Long press is your friend Children naturally long press on touch devices. If your feature can work via long press rather than dragging from one precise point to another, do so, even if it means losing some accuracy. I’ve seen it spark delight in children and adults alike. For example, if inserting an image, like above, the common way to do this is to insert it with a size chosen using some heuristic, with resize handles for modifying it later. I found that kids much preferred the long press approach above, especially with the added sound effects. I’ve even had a few of their parents email me calling out their delight at this approach. Try to solve Palm Rejection I personally never rest my hand on a tablet when using a pen, and so worked on solving this later than I should have. Palm Rejection is the effort by the app to identify which touches represent a command from the user, and which are spurious connections with the skin, like the heel of a hand. It’s a notoriously difficult problem to solve well, but is critical when building apps for children, and they frequently rest their little hands on the tablet, just as they would on a piece of paper (or their bedroom walls with a crayon….). Depending on the technology you’re building your app with, there are various approaches to solving this, which I encourage you to research. I found the best that I could do was to use the touchType attribute on touch Event on iOS Safari (read more here) or the pointerType attribute on Pointer Events , which tells you if the user is using a stylus or not. If they are, I remember that for all future interactions and ignore all future events that are not from the stylus. I tried to use a number of different heuristics for the size of the contact area, the pressure applied and more, but when tested with my kids they always got different, less reliable results than I did in my testing. So, the simpler approach seems to work better. The user may sometimes want to switch back to using a finger, so how best to allow this? My solution is to float this icon near any non-stylus touch point for a short time, two seconds or so, then automatically hide it. When resting a hand on the screen it usually covers it, but it makes it simply to toggle between modes, and follows the previous guidance of keeping controls near to the location where they are needed, in this case, a few pixels away from the finger or palm (not directly under it). If you’re aware of solid palm rejection techniques that work in other browsers, please let me know! See chofter.com for my contact info. Simplify, then add delight(ness) (with apologies to Colin Chapman for butchering his wonderful line) Even more so than with older users, designing small moments of delight are critical to the retention, both short and long term, of users. When testing some little touches intended to delight users, I’ve seen my kids laugh out loud, and gotten emails from parents stating the same. This is what you’re aiming for. So what kind of things are we talking about? Well, that’s specific to your app. In the artistic sphere, I’ve found that kids love bright colours, and especially rainbows. The rainbow pen and gradient fill you see above easily get the most positive reaction, and are relatively simple to build. Adding sound can be another great way to add delight. When adding an emoji, as shown earlier, there is a nice growing sound that plays. Kids also love tactility, and the more your 2D app can feel like a real physical object the better. Adding sound to interactions with real-seeming objects is even better. For example, I added the ability to grow and pop bubbles, which is something I used to do as a kid with washing up liquid and a straw (try it, you’ll lose hours of your life, seriously). The bubbles make a satisfying popping sound, and splash out as if you’re making a paint related mess. Not much artistic merit in this, but all kids giggle when they use it. Adding sparkle effects is another easy way to add delight. These can happen when tapping a button, dragging something around or anywhere you like – kids are just happy to see them. For example, when adding the greeting card feature, I thought my kids would like it if I made rainbow coloured particles fly off the corners of the card when it was rotated. They agreed with loud giggles and “whoa” noises. Find ways to make kids say that fairly regularly and your app will go down well. Maintain visual context when changing state For some adults and most kids, if they interact with a visual element and it immediately disappears to be replaced with something else, they can lose context of where they were and what they were doing. You should always try to make it extremely obvious to the user how they got where they are, and how they can get back to where they were. There are a number of approaches that can help with this. Some that I’ve used include: Dialogs with a semi-opaque background . Popping these up when the user must make a choice makes it very clear what is needed from them, and dismissing them to get back to where they were previously is really simply. A mistake that some people make is to force people to tap a button to close a dialog. Some people struggle with this, so always make the dialog dismiss when the background is tapped too. . Popping these up when the user must make a choice makes it very clear what is needed from them, and dismissing them to get back to where they were previously is really simply. A mistake that some people make is to force people to tap a button to close a dialog. Some people struggle with this, so always make the dialog dismiss when the background is tapped too. Only use one dialog at a time . It’s ideal to design flows where no dialog opens another dialog, but if you find yourself in this situation, it can be very confusing for younger users that by dismissing the second dialog, they are still in another dialog. If you must open a second dialog, close the first immediately. . It’s ideal to design flows where no dialog opens another dialog, but if you find yourself in this situation, it can be very confusing for younger users that by dismissing the second dialog, they are still in another dialog. If you must open a second dialog, close the first immediately. Use tasteful animated transitions. It is very possible to overuse animated transitions, so be careful here, but animating from one state to the next is a great way to bring a user along with you. This is particularly important if you’re introducing your user to more complex ideas or objects. For example, when building a comic in Kidz Fun Art, when the user clicked a comic panel to zoom in, I initially just immediately swapped out the view for the zoomed in view, but my kids told me it made no sense at all. This led to me spending a lot (and I mean a lot) of time figuring out the exact way to play with pixels and CSS transitions to enable the zoom in and out effects you see below. It also makes it more clear when moving up, down, left and right between panels. This ended up ballooning the time to build the Comics feature by 300% or so, but it just wasn’t shippable to younger users (the main demographic) without this level of effort. Building for kids is hard, you’ve got to own this fact before you start, or you’ll ship sub-par products. Monetize without ads, or not at all To ethically ship an app intended for young children, there is no safe strategy to show 3rd party ads. Children with either be shown inappropriate content, or be tricked into clicking out of the app, which is the beginning of a slippery slope to inappropriate content. Even if the ads are non-click and display only, they are designed to trick and manipulate minds that are not ready for it (are any of us, really?). If you plan to monetize, find another way. With Kidz Fun Art, I chose freemium + optional yearly subscription, what you choose should best suit your product. But save yourself time and don’t even consider ads – take it from someone who at one point led a decent sized chunk of the Facebook Ads org, ads work too well and should never be shown to children. A small caveat to this ultimatum can be email related advertising. If you get the parent to sign up with their email, you can potentially use that as a surface for advertising or pushing content not intended for children. I’ve never done this, but you’re probably a lot safer taking this approach than showing ads in the app itself. Plan for app growth without social sharing Most apps these days turbo charge their growth by sharing user information or user generated content with others online. For apps with young users, there is almost no safe way to do this. If a young person writes, draws, colours, and uses media on their phone in your app, this opens them up to abuse the moment it is shared outside the app. This makes it much more difficult to achieve explosive growth with child focused apps, which it partly why so few companies focus on building them – Roblox being an obvious exception, and their approach is more than questionable, I certainly don’t allow my children anywhere near it. In Kidz Fun Art, the only sharing I found to be safe is: Direct email to the owning account email whenever a new drawing is shared. This is obviously OK, as the parent can see anything the child wants them to . AI generated images created by choosing pre-populated tokens, like “unicorn” or “spaceship” are shared with all users, even non-subscribers. This is safe as the user cannot provide any personal information, and they cannot create any content that might be inappropriate for others. Outside of these, I’ve avoided any and all sharing: the safety and privacy of the user must be the foremost design principle at all times. If you find yourself straying from this, it’s time to do a hard reset and think about either achieving your growth goals another way, or deciding to abandon the project as a money making concern. Children should never spend money This is obvious enough if you’re building ethically, but children should never directly spend their parent’s money, so design your app to enforce this. If you have in app purchases, require proof that it is the adult making the purchase decision. The pin for the tablet is not sufficient, as the person using the app almost certainly knows it. In Kidz Fun Art I use Stripe for subscription payments, which makes the last 4 digits of the credit card knowable, so I use this as a pin for any in app purchases (only AI image generation credits as of 2025, nothing else planned). Of course this is validated server side and never sent to the client. I figure that if the child has the parent’s credit card literally in hand, spending a little in our app is the least damage they’re likely to be doing that day. If you have better solutions, I’d love to hear them! Epilogue Thanks for reading all this, I hope it was of use and didn’t scare you away from building delightful apps for children. I’m still very much fumbling my way through this, so if you have any good tips, feel free to comment, or reach out to me on Threads, X or any other contact method you see on my personal site chofter.com .