Most "mobile-first" advice is written for an imaginary user: a 28-year-old with perfect eyesight, a flagship phone, fast fingers, and a fiber connection. That user does not represent the audience for the platform I work on. A large share of the people playing card games like Buraco, Canastra, and Tranca on Jogos do Rei are 60 years and older. The platform has been around since 2010 and has grown to 3M+ registered players, and a meaningful chunk of that base did not grow up with touchscreens.
Building for that audience forces you to unlearn a lot of habits. Here are the constraints we kept running into and the tradeoffs we made.
Touch targets are not a "nice to have"
The WCAG guidance of a 44×44px minimum touch target is treated as a floor by most teams and quietly ignored in dense UIs. For older users it's closer to a hard requirement, and honestly 44px is on the small side. Reduced fine-motor precision and, in some cases, mild tremor mean that a mistap isn't a minor annoyance — it's a wrong card played in a live match, which feels catastrophic to the player.
Concrete things that helped:
- Generous hit areas that extend beyond the visible control. The tappable region can be larger than what the eye sees, and that padding absorbs imprecise taps.
- Spacing between interactive elements so adjacent taps don't fire the wrong action. In a hand of cards this is the hard part — cards naturally overlap. We lean on fanning out the active card and enlarging the one under the finger rather than cramming more cards into the same width.
- No destructive action one tap away from a common action. "Leave table" next to "Play card" is a trap. Confirmation dialogs are annoying for power users but they save older players from actions they didn't intend.
Font size, contrast, and the zoom problem
Older eyes need larger type and higher contrast, and this is where a lot of well-meaning responsive design breaks.
The first instinct is to bump base font sizes. Good. But the second-order effect is that many senior users also set their OS or browser zoom to 150–200% on top of your already-large type. If your layout assumes a fixed viewport and uses absolute positioning or overflow: hidden to look tidy, that zoom shatters it — buttons disappear off-screen, text clips, modals become unusable.
Lessons:
- Design so the layout survives 200% zoom. Use relative units (
rem/em), let containers grow, and test with the browser zoomed rather than only with responsive dev-tools breakpoints. - Don't ship contrast that only passes on your calibrated monitor. Older displays, glare, and age-related contrast sensitivity loss all eat into your margin. We aim comfortably past the WCAG AA 4.5:1 ratio for body text rather than sitting right on it.
- Avoid thin/light font weights for anything the user must read. They look elegant and they're hard to read.
The connection you don't have
The "mobile-first" persona assumes a fast, stable connection. A big portion of real traffic is on older Android devices over spotty mobile networks, sometimes on a phone that's four or five years old with limited RAM. That reframes a lot of decisions:
- Ship less JavaScript. A heavy SPA that's snappy on a MacBook can jank badly on a budget Android from 2019. Every KB of parse/execute time is felt. We're aggressive about not pulling in a framework where plain HTML, CSS, and a bit of vanilla JS will do — the same philosophy behind our public card-game glossary, which is static HTML precisely so it loads instantly on weak devices.
- Assume reconnection is normal, not exceptional. In a real-time card game the network will drop mid-match. The interesting UX work isn't preventing disconnects (you can't) — it's making reconnection graceful so the player rejoins the table where they left off instead of being kicked and losing the game. For an older player, being dropped from a game they were winning is the kind of frustration that makes them churn.
- Optimistic UI has to be handled carefully. Showing an action as "done" before the server confirms feels fast, but if it later has to roll back, a confused senior player reads it as a bug or as cheating. We prefer honest, immediate feedback ("sending…") over an optimistic state that might reverse.
Copy and iconography
A pattern we've had to correct repeatedly: designers love icon-only buttons. A gear, a hamburger, three dots. For a 30-year-old these are learned universal symbols. For a 65-year-old who came to the internet later, many of them are not obvious at all.
- Pair icons with text labels wherever space allows. "☰ Menu" beats "☰".
- Prefer plain, literal wording over clever product-speak. "Sair da mesa" (Leave table), not "Encerrar sessão".
- Be careful with gestures. Swipe-to-do-X and long-press menus are effectively invisible to users who don't know to try them. Anything important needs a visible, tappable path.
Where "mobile-first" and "senior-first" actually conflict
It's worth being honest: these two goals pull against each other sometimes.
Mobile-first pushes you toward compact, gesture-driven, minimal-chrome interfaces. Senior-first pushes toward larger elements, explicit labels, visible controls, and confirmations. You cannot fully satisfy both on a small screen.
Our resolution is that the desktop experience remains a first-class citizen rather than an afterthought — a genuinely large share of our older players are on desktop, where screen real estate lets us give elements the size and spacing they need without cramming. That runs against the industry reflex to treat desktop as a scaled-up phone. For this audience, "mobile-first" is a technique for performance and resilience on weak devices, not a mandate to shove everything into a 360px column.
What I'd tell another team
- Test with actual older users, not a simulator. Watching a 70-year-old try to play one hand teaches you more than a dozen accessibility lint passes. You'll see the mistaps, the squinting, the abandoned gestures.
- Treat undo/confirm as core UX, not friction. For this audience, reversibility beats speed.
- Budget for the low end. Performance is accessibility. A slow, janky page excludes older users on old hardware just as surely as poor contrast does.
- Don't hide function behind cleverness. Visible, labeled, generously-sized, and forgiving beats sleek every time.
None of this is exotic — it's mostly WCAG fundamentals plus taking your real audience seriously instead of the imaginary median user. But the discipline of building for people who are 60+ and on modest hardware has a nice side effect: it makes the product better for everyone. Larger targets, clearer copy, faster loads, and graceful reconnection are things a 28-year-old on a flagship phone appreciates too — they just won't churn if you get them wrong.
Top comments (0)