Building for everyone: why accessibility is a product decision, not a checkbox
Most software is built for an imaginary 'average user.' We think that's a mistake - and here's why designing for the edges makes better products for everyone.
When we sat down to define what AskiNox would build, we kept coming back to the same question: who is this actually for?
It sounds obvious. Every product team claims to be "user-focused." But dig a little deeper and you'll find that most digital products are built for a very specific kind of user - someone with a fast device, a reliable connection, disposable income, and enough tech fluency to forgive a confusing interface.
That's not most people.
The invisible majority
The majority of people who could benefit from great fintech, education, or health software aren't being well served by it. Not because the technology doesn't exist - it does. But because the product teams building it optimized for the users who were already in the room.
This is a pattern we call the visible majority problem: the users who are easiest to serve are the ones who already have resources. They're articulate, technically confident, and willing to push through rough edges. They give feedback. They show up in user research. They look like the people making the product.
Everyone else - the 3G user in a rural area, the first-time smartphone owner, the person who gets anxious when an app moves too fast - gets left behind.
Why accessibility improves everything
Here's the counterintuitive part: when you design for those edge cases, your product gets better for everyone.
Consider constraints:
- Low bandwidth forces you to load less, which makes your app faster for everyone.
- Small screens force you to prioritize ruthlessly, which clarifies your interface for everyone.
- Cognitive simplicity for new users means less support overhead and faster onboarding for experienced ones too.
Designing for the edges isn't charity. It's good product thinking.
How this shapes what we build
At AskiNox, accessibility isn't a compliance checklist we work through before launch. It's a product constraint we set at the beginning.
That means:
- Designing for slow connections before we design for fast ones
- Testing with users who aren't developers or product managers
- Writing interfaces in plain language, not product-speak
- Making core functionality work without JavaScript when possible
- Treating screen-reader support as a first-class requirement, not an afterthought
It also means slowing down occasionally. A feature that works for 80% of users in 2 weeks might take 3 weeks if we build it for 95%. We think that's usually the right trade.
The bigger picture
There's a business case here too. The users most underserved by current software are often the fastest-growing markets. People in emerging economies are getting smartphones for the first time. Older adults are embracing digital tools they were skeptical of a decade ago. First-generation learners are entering higher education.
These aren't edge cases. They're the next billion users.
We'd rather build for them from day one than retrofit accessibility into products that were never designed with them in mind.
At AskiNox, we're building digital products across fintech, edtech, health, and e-commerce. If this resonates with how you think about product, we'd love to hear from you.