Beyond Compliance: What We Learned Building an App for Adults with Intellectual Disabilities

As a software agency, we regularly build products for clients serving specific populations, such as teachers, doctors, or children. Each has their own needs, and it’s best practice to design with those users in mind from the start. When a client asked us to build a financial literacy platform for users with intellectual disabilities, we realized that this population would force us to rethink our general assumptions about how people interact with technology more than other populations we’ve built for. We discovered that true accessibility is more than just checking compliance boxes, but instead about intentional design and creative feature choices. Many of those choices turned out to be more universally applicable than we’d expected. Here's some of what we learned.

Text can be a barrier, not a feature

One of the first things our client told us: "95% [of our participants] can't read. And if they can, it's very limited." This single insight changed our entire approach from how we would typically design a software product. We could no longer rely on labels, instructions, or error messages to guide users. Every interaction had to be visually intuitive. Images and icons had to carry meaning on their own, and text became supplementary, there primarily for the caregivers helping participants navigate the app. We learned to pair visual cues with minimal text, but the visuals always came first. One example: when a participant answers a question correctly, they are shown a confetti animation, along with the coin amount with emojis:

Designing for multiple users simultaneously

We also learned that the users for our app would be using the app from centers where they would be accompanied by Direct Support Professionals (DSPs). These DSPs would sit beside them, helping them navigate the app interface and, in certain cases, answering questions on their behalf. This created a dual-interface challenge. Participants needed large buttons, visual feedback, and gamified rewards. However, DSPs needed monitoring tools, the ability to see multiple participants' progress at once, and administrative controls. Our solution was to build for both user needs, splitting the app out into multiple logins. The participant view was designed to be engaging, interactive, and accessible. The DSP view was designed to be informative, streamlined, and straightforward. For example, DSPs could answer questions on behalf of the participants, while the participants still got to see and interact with the questions, too.

Overall, both users get the ideal user experience for their needs.

Gamification as Curriculum

For people with intellectual disabilities, the classroom experience isn’t just about information transfer, it’s about recognition. Our client described how their in-person financial literacy classes have typically functioned, before the creation of this app. When someone gets an answer right, the instructor celebrates publicly, everyone claps, and the participant feels seen. That moment of acknowledgement isn’t a nice-to-have. It’s what makes learning stick, which is why we needed to replicate that dopamine hit digitally.

How we did it:

• Coins for correct answers: Immediate, tangible rewards say “you did it.”
• Badges for milestones: Allow participants to track their progress over the course of time
• Visible progress bars: Clear visual indications of how far participants have come, and how close they are to their next achievement

Research shows that gamification improves engagement and retention for learners with intellectual disabilities (i.e. Kumar, 2025). Ideally, the visual progress indicators in our app would both reduce cognitive load around “how am I doing?” and the collectible elements would create intrinsic motivation to return to the app. Overall, our takeaway was that these features weren’t decorative, but instead primary features of our app.

What Went Wrong

Designing for multiple users simultaneously was a meaningful challenge, and we didn't get everything right the first time.

We successfully designed the app such that a DSP could answer questions on behalf of a participant, which was an important accommodation for users who needed more hands-on support. What we missed, however, was the login experience itself. We hadn't accounted for the fact that a DSP might also need to log a participant into the app for them, not just assist them once they were already inside it.

It was a gap that, in hindsight, revealed something important: truly understanding a user's workflow requires more than empathy in the abstract. It requires diligence at every step of the journey, especially for users whose day-to-day experience we don't have firsthand familiarity with. It's easy to design thoughtfully for the moments we can imagine clearly. The harder work is pressure-testing the full flow, including the parts that happen before a user ever reaches the first screen, and asking whether someone who relies on a caregiver for support can actually get there at all.

What We're Taking Forward

Building this app taught us that, when building for a certain population, accessibility is a lens through which every decision gets filtered. For example, we constantly found ourselves asking questions like: "Will this work for someone who can't read?" "Will this work for someone using it with a caregiver?" "Will this make someone feel motivated to learn?" The answers to those questions shaped an app that is potentially simpler, more visual, more celebratory, and more human than anything we would have built by default. A lot of these principles would make any software better: fewer screens, clearer feedback, celebration of progress. These are more than accommodations for disability, they're good design. We just happened to learn them by building for a population that made the stakes impossible to ignore.