Who Are We Really Designing Simple Interfaces For?

The Reality Check That Changed Everything

During one of our ActiveSG focus groups, my team asked what seemed like a reasonable question: "What's a good average steps goal for seniors? 5,000? 10,000?"

The room erupted in laughter.

The participants—all 50+—shared that they were walking far more than all of us "youngsters" in the room. Their average was 15,000 steps daily while we researchers were struggling to hit 5,000 between our desk jobs and coffee runs.

Here we were, designing "simple" fitness interfaces for people who were already outperforming us. The irony wasn't lost on us.

The Accessibility Theater

This got me thinking about all the times we've simplified designs "for accessibility." My client suggested we follow WCAG guidelines religiously, ensuring every new feature met strict contrast ratios and interaction patterns for vision-impaired users.

"We need inclusive design," they said earnestly.

It's a good thought, but I suggested we introduce accessibility features gradually rather than diving deep into color adjustments immediately—that would make everything look dramatically different from the established brand identity.

The challenge is balancing genuine accessibility needs with practical implementation. We want to build inclusive experiences without creating jarring visual inconsistencies that confuse all users. It's about finding the right approach to accessibility, not just checking compliance boxes.

The Constraint Spiral

The guidelines keep multiplying. Design for dementia suggests keeping everything within one scroll. Design for motor impairments requires larger touch targets. Design for cognitive load means minimal options per screen.

But wait—are we designing for the broad mass or are we creating another medical app targeting dementia specifically?

This thinking extends to content too. Do we adjust sodium intake recommendations that vary individually, or do we assume everyone can eat 2,000mg of sodium daily? Every day we need to remind ourselves: we are not a medical app.

A recent real-life scenario brought this home: we tied child information to parent profiles, but the feature lacked consideration for divorced families or deceased children. Do we add these as future enhancements, or do we think through all angles from the get-go?

Each well-intentioned guideline becomes another constraint, another assumption about limitations or family structures that may not reflect your actual users' reality. We're designing for edge cases while potentially creating awkward or painful experiences for others.

The Pokemon Go Reality

Meanwhile, those same "older users" we're protecting are walking around parks with multiple phones, simultaneously catching Pokemon and coordinating family WhatsApp groups. They're booking Grab rides, managing online banking, and somehow navigating Shopee's deliberately complex gamification without breaking a sweat.

Yet we're concerned they can't handle a slightly more sophisticated feature?

The Real Question

So who are we really designing simple interfaces for?

Ourselves? Simple designs are easier to build, test, and defend in meetings.

Our clients? "Accessible" sounds good in project presentations, regardless of whether it serves actual users.

Our assumptions? It's easier to design for imaginary limitations than research real capabilities.

Our guilt? Making things "simple" feels virtuous, even when it's condescending.

When Simple Becomes Insulting

Here's what I've learned: there's a difference between accessible design and assumptive design.

Accessible design serves users with actual needs—high contrast for vision impairment, keyboard navigation for motor limitations, clear language for cognitive processing.

Assumptive design serves our stereotypes about who needs help and why.

The 70-year-old managing 5 Pokemon balls doesn't need your dumbed-down interface. The working parent juggling kids and career doesn't need baby-simple navigation. The new immigrant learning English might prefer efficient interactions over patronizing simplicity.

A Better Approach

Instead of asking "how simple can we make this?" try asking:

• Who are our actual users and what are their actual capabilities?

• What specific barriers do individual users face?

• How can we offer choice between simple and sophisticated interactions?

• Are we solving real problems or imaginary ones?

I get it—designing for diverse capabilities is genuinely challenging. It's easier and feels safer to default to simple. But when we start with assumptions instead of research, we risk solving the wrong problems.

Some users genuinely benefit from simplified interfaces. Others are power users who want efficiency and control. Most want the option to choose their own level of complexity.