Designing for children can seem daunting enough. Designing software for use in a classroom brings an additional challenge, as there may be children in that class with special needs. For example, children with non-extreme cases of Attention Deficit Hyperactivity Disorder (ADHD) are normally placed in mainstream education rather than special schools, meaning they often have to use the same learning materials and technologies as the other students. In other words, whenever we design software for use in schools, we have to remember that students like these may need to use our software as well, and they need to not be disadvantaged by it.
Recently, I was given the task of designing software for use in a classroom that may contain children with ADHD. That meant I needed to explore the needs of this group in more depth. It proved to be a challenge, and I was surprised by what I found.
Attention Deficit Hyperactivity Disorder: Understanding the Users
ADHD has been cited as the most commonly diagnosed behavioral disorder in children, with estimates suggesting that it affects between 3-5 percent of all children worldwide. It is often characterized by a difficulty in holding attention to a task or in controlling impulsive behavior. Because of the impact that attention difficulties can have on academic performance, ADHD can also be classed by some as a learning disorder. Diagnosis is usually performed by a healthcare professional such as a child psychologist, and it would be easy for casual observers to dismiss ADHD symptoms as misbehavior, day dreaming, or lack of attention—which are already common in young children. In fact, children with this condition may be receiving a range of treatments, such as specialist support, behavior management practices, psychotherapy, and in some cases, medication.
The first step towards learning how to design software for children with ADHD, therefore, should surely be to build a relationship with them; to learn more about them and their needs. In practice though, this is difficult. Gathering useful requirements and performing valid evaluations is already a significant challenge with any children, and one that the Child-Computer Interaction field still struggles to find solutions to. Also, when each class in a school rarely contains more than one or two children with ADHD, this means either spending the time to build relationships with a large number of classes across several schools, or singling out the children with special needs. Understandably, many schools are reluctant to identify their special educational needs children to visitors. Finally, children with ADHD are particularly difficult for visitors to work with—teachers often feel it can be unhelpful to introduce these children to too many new faces or break their routine with a visit from outsiders.
The Search for Guidelines
So how can usability experts begin to design for groups such as these when it is so difficult to find out more about them? As it turns out, there is a wealth of information on supporting ADHD, if you know where to look. Government health advice, parenting forums, mental health support sites, and sites such as ADDISS (the National Attention Deficit Disorder Information and Support Service) all provide recommendations for parents and caregivers on how to support children with the condition. Of course, none of these relate to the design of software. However, by sifting through this information and finding advice that could relate to software design, I began to build a picture of the children’s needs. What surprised me was how closely this information often related to what I already knew about designing for usability. Here are the guidelines that I derived from the advice that I found. All of these guidelines are based on recommendations from several sources, and on what I think they could mean in the context of software design.
Guideline 1: Design materials so the layout is neat and uncluttered.
Although intended for paper materials, this guideline could easily apply to software interfaces. Indeed, it is already in line with usability guidelines on uncluttered interfaces and minimalist design, in order to reduce confusion and search times needed to find information. This guideline therefore seems appropriate not only for children with ADHD, but for all users.
Guideline 2: Provide a calm environment with soothing colors, free of decorations and distractions.
Again, although intended for designing a home or classroom environment, this suggestion could apply to a software environment. The advice on minimal distractions is in line with standard usability guidelines and seems suitable for all users since it helps avoid confusing displays and unnecessary attention-grabbing features. The advice on “calm” and “soothing colors” may be of note to graphical designers, particularly for the design of children’s software where bright colors are often used.
Guideline 3: Provide a high-reinforcement environment; reward good behavior and completion of all tasks using positive language.
The use of reward structures and congratulations on task completion is often seen in children’s games and seems to be a common feature that is likely to be suitable for all users. However, reward structures are seen far less in software tools—for example word processors, drawing packages, calendars, or planners. Designers could consider building these features into software, but there is a risk of the tools becoming patronizing for other users if overused.
Guideline 4: Organize items in an orderly way.
The need for organization and consistency is one of the most common mantras of interface design and one of Ben Shneiderman’s classic “Eight Golden Rules.” This helps users to find information more easily without distractions or confusion. This guideline therefore seems highly appropriate for all users.
Guideline 5: Distinguish important information by putting it in bold or color. Signpost sections and group related information into panels.
This guideline relates to Guidelines 1 and 4 on organization and consistency. Important information should be easiest to find, and users should be able to identify the key features of an interface quickly.
Guideline 6: Use large print and a clear font.
While sans-serif fonts are often used for children, research has not shown any reliable benefit of this form of typeface over serif fonts for readability. In terms of size, 12-point type is often suggested for use on a screen. While the literature on this topic is divided, it is important to keep in mind the readability of any fonts that are used, and ensure that they are clear on the type of display they are designed for.
Guideline 7: Help students follow text by writing/highlighting alternate lines in different colors.
”Zebra tables” are often recommended where lists are used. However, designers should be cautious about conflicting with other guidelines about simple displays without too much color and distraction. Where possible, long lists of information should be avoided.
Guideline 8: If the student needs to work through a series of questions, help them keep their place by using a marker.
Users often need to work through a series of screens or a sequence of tasks. Making it clear at what point in the process they are helps them keep track of their progress through a game or long activity. This sort of indication could benefit all users.
Guideline 9: Use brief and clear instructions.
Simple and unambiguous language is undoubtedly best for all users and particularly children. Familiar words, clarity, and conciseness will help users understand instructions, and keep the interface uncomplicated and uncluttered.
Guideline 10: Allow ample rest periods and exercise breaks.
This guideline may seem out of the control of software designers, and more for parents, teachers, or other caregivers. However, software could aim to encourage rest, if desirable, by prompting users to take a break after long periods of usage or by limiting usage to a certain length of time per day. Another suggestion might simply be that designers should support the desire of their users to take breaks by allowing quick and easy saving and exiting from the software, and resuming without hassle. This is likely to prove beneficial to all users, particularly children who need to stick to a strict timetable within school hours.
Guideline 11: Have a workstation that is enclosed in a soundproof environment and free of distractions.
Related to Guideline 2, the key issue here is minimizing distractions. It is important for designers to be aware of the context in which their software will be used; for example, audio output may require the use of headphones. In particular, software for mobile devices does not tend to assume this sort of isolated, static environment. However, there is no reason why users could not work in an enclosed space with a mobile device. In fact, portable devices could enable users to move to private locations or a space that is most suitable for their needs, rather than being constrained by the layout of desktop machines.
Guideline 12: Keep technology shut away unless it’s being used.
Related to Guideline 10, designers should be aware that teachers or parents may not want children playing for long periods of time, or may need them to finish a task at the end of a lesson. Work or games should be easy to save and finish at any point and resume easily later. As a suggestion, mobile devices may be more suitable for this user group, as they can be physically put away in a cupboard or drawer more easily than a desktop computer.
Guideline 13: Stick to a routine.
Again, this seems more of an issue for caregivers and educators than designers. However, sensitivity needs to be used in introducing new faces and new technologies. Frequent updates and changes to software may be undesirable, and the implications of taking technology away at the end of studies should also be carefully considered. Appreciating the need for routines may help in gaining cooperation from parents and teachers.
Guideline 14: Minimize surprises.
This guideline is linked to those on maintaining routine and providing consistency. Unexpected behavior is usually undesirable in software and is generally linked to lower task efficiency. However, this may cause difficulties with game design, where a lack of surprise could easily lead to tedious game play. Designers should avoid unwelcome surprises and where they are aiming to surprise users, they should consider why they wish to do so and whether it is an essential feature for engagement or simply a distraction.
Guideline 15: Maintain eye contact.
Obviously this is difficult for software to achieve! However, eye contact is an important strategy in maintaining attention. While software could use eye-tracking techniques, or on-screen characters who look directly at the child, there may be simpler methods for determining if the child’s attention has wandered. For example, software could detect a long delay on input or repeated input that is irrelevant to the task. On detecting a lack of attention, software could ask for input or suggest tasks to attempt instead. Such features should be considered for all users, as such delays may also indicate boredom or confusion.
The most useful discovery from this exercise has been in noting how many of these guidelines relate closely to established usability guidelines. An expert designer who is sensitive to usability issues should be capable of designing a product that is, at least, not damaging for children with ADHD. More importantly, it should also be possible to design a system that is suitable for both ADHD and non-ADHD children, thereby reducing the risk of marginalization of ADHD children through unsuitable software. All that is needed is an understanding that usability principles may become more critical to follow in this instance. For example, a cluttered interface is not recommended for anyone but is usually tolerated. However, if the user suffers from attention difficulties, clutter becomes a much more serious issue. Designers should also be aware that features added purely for entertainment value may in fact be damaging to usability. They must consider the value of all features being added to an interface.