Voice reminders changed everything.

Design · 6 min read

One of the most powerful features we designed for an NDIS life management app wasn't a screen or a button. It was a voice. A recorded voice reminder from someone the user trusts, playing at the right moment to help them complete a daily task.

For the participant this app was designed for, text reminders weren't enough. Standard push notifications were easy to dismiss or ignore. But hearing a familiar voice, a family member saying "time to take your medication" or "don't forget to eat lunch," that changed the whole dynamic. It turned an impersonal notification into a personal moment of support.

Why voice matters for accessibility

Not everyone processes text the same way. For users with cognitive disabilities, intellectual disabilities, or low literacy, a text-based notification can be meaningless. The ABS Disability, Ageing and Carers Survey (2022) reports that 5.5 million Australians have a disability. Many of them interact with technology differently than the "typical" user that most apps are designed for.

The WebAIM Screen Reader User Survey found that 72.4% of screen reader users are using mobile devices. Audio-based interactions aren't an edge case. They're a primary mode of engagement for a significant number of users.

Voice reminders take this a step further. Instead of a robotic text-to-speech notification, the user hears an actual human voice. Someone they know. Someone they trust. The emotional and practical impact of that distinction is enormous, especially for users in the NDIS and aged care spaces.

Then we hit the platform wall

Designing the feature was the easy part. Implementing it within the constraints of iOS and Android was where things got complicated.

Apple's notification framework has strict limitations on what notifications can do. Audio playback from a notification is limited. Background audio requires specific entitlements and has battery and privacy implications. Playing a custom audio file at a scheduled time, reliably, every time, isn't as simple as it sounds. Android's background task restrictions, introduced to preserve battery life, add similar challenges.

Both platforms have good reasons for these restrictions. They protect users from apps that drain battery, play unwanted audio, or run unchecked in the background. But those same protections mean that a feature which seems simple from a user's perspective, "play this audio at 8am every day," requires careful engineering to deliver reliably.

Constraints drive better design

Here's what I've learned over fifteen years: platform constraints almost always lead to better design, not worse. When you can't do the obvious thing, you're forced to think harder about what the user actually needs and find a smarter way to deliver it.

In this case, the constraints forced us to think more carefully about the entire reminder experience. Instead of just blasting audio at a scheduled time, we designed a reminder flow that accounts for different scenarios. What if the user's phone is on silent? What if they're in a meeting? What if the reminder fires but the user doesn't respond?

The result was a more thoughtful system than what we would have built if there were no constraints. The notification arrives first as a gentle prompt. The voice plays when the user engages with it. There's a follow-up if the task isn't marked complete. And the carer or family member gets a summary of which reminders were acknowledged and which were missed.

Why this matters for your app

You don't have to be building an NDIS app for this lesson to apply. Every app project hits platform limitations. iOS and Android each have rules about what you can do with the camera, location data, background processing, push notifications, biometric data, and more. Apple's App Store Review Guidelines and Google's Play Store policies add additional constraints depending on your app's audience and functionality.

A designer who understands these constraints designs within them from the start. They don't promise features that can't be reliably delivered. They don't design flows that look beautiful in a mockup but break when they hit the reality of what the platform allows.

This is one of the reasons the hidden cost of a designer who doesn't think about development is so real. If your designer doesn't know about platform limitations, the developer will discover them during the build, and that discovery costs time and money.

The feature that nearly didn't happen

Voice reminders could have been cut from the scope. When we hit the platform limitations, that was a real option. It would have been simpler, cheaper, and faster to ship without them.

But we kept them because they solved a real problem for a real person. The participant this app was designed for genuinely needed that auditory prompt. Text wasn't enough. A generic alert sound wasn't enough. The familiar voice was the solution, not just a feature.

That's the question to ask about any feature that's proving difficult to implement: is this a genuine need, or is it a nice-to-have? If it's genuine, find a way. If it's a nice-to-have, save it for later.

Sources
Disability, Ageing and Carers Survey 2022 (Australian Bureau of Statistics) - 5.5 million Australians (21.4%) have a disability.
Screen Reader User Survey #10 (WebAIM) - 72.4% of screen reader users use mobile devices.
UserNotifications Framework (Apple Developer) - iOS notification framework with audio and background processing constraints.
Background Tasks (Android Developer) - Android background processing restrictions for battery and performance optimisation.

Related blog posts:

Case study: NDIS life management app →

Designing for the person who can't read your app →

One app or two? iOS, Android, or both →