// CASE STUDY — UNITY GAME · ACCESSIBILITY DESIGN
A Unity-based music game and DAW hybrid designed for children with autism and other accessibility needs — where every player interaction produces a musical output and no failure states exist. Built with a team of 4+ and tested with real users aged 5-8.
Play on itch.io
// 01 — The Challenge
Music games typically reward speed, precision, and pattern recognition — skills that can be barriers rather than invitations for children with autism or other accessibility needs. BandBuilder was designed to flip that model entirely. The goal was a music experience where the process of playing felt rewarding regardless of technical skill — closer to a creative instrument than a performance test.
// How do you design a music game that feels like creative expression rather than a test of ability?
// 02 — Design Approach
The core design decision was to build BandBuilder as a hybrid between a game and a DAW — a digital audio workstation — giving players genuine creative agency rather than just reaction-based gameplay. This meant designing systems where every interaction produced satisfying audio output, not just correct or incorrect states.
Modular architecture was central to this approach. Audio logic, UI state, and gameplay systems were built as independent modules — each responsible for one thing and communicating through clear interfaces. This made it possible to adjust accessibility features like input sensitivity, visual contrast, and audio feedback volume without rewriting core gameplay logic.
Every layer of the design was built with accessibility in mind from the start — not as an afterthought. High contrast UI, adjustable audio feedback intensity, large touch targets, and predictable consistent interaction patterns were foundational decisions, not additions.
// 03 — User Research & Testing
BandBuilder was tested with children aged 5 to 8 across a range of accessibility needs. Observing real play sessions revealed how children naturally approached the instrument — which interactions felt intuitive, which caused frustration, and where the audio feedback needed adjustment to avoid sensory discomfort.
// Observed
Interaction Patterns
// Observed
Sensory Response
// Observed
Creative Engagement
// Observed
UI Clarity
Children don't perform for researchers — they simply play or they don't. That honesty made every testing session more valuable than any internal review. Each observation directly shaped the next iteration of the design, from visual contrast adjustments to audio intensity controls.
// 04 — What We Built
BandBuilder combines real-time audio interaction with gameplay systems designed from the ground up for accessibility. Players create music through interaction without needing prior musical knowledge or fine motor precision. The hybrid DAW model means outputs are always musical — there are no wrong answers, only different sounds.
// Feature
Real-Time Audio Interaction
// Feature
DAW Hybrid Gameplay
// Feature
No Failure States
// Feature
High Contrast UI
// Feature
Modular Architecture
// Users Tested
Children Ages 5–8
// 05 — Outcome & Reflection
BandBuilder was one of the most demanding projects I've worked on because the constraints were human constraints, not technical ones. Every system had to work for a child who might experience sound, light, and interaction completely differently from the person designing it.
That discipline — designing for the edges of the user spectrum rather than the assumed middle — is now baked into how I approach every project. When I design a product card, a navigation system, or a form flow, I think about the user who finds it hardest to use first. If it works for them, it works for everyone.
The no failure states principle that drove BandBuilder's design is something I carry into every UX decision. Error states, dead ends, and confusing feedback aren't just bad for accessibility — they're bad design. BandBuilder proved that removing them entirely makes the experience better for every user, regardless of ability.