HomePortfolioServicesSolutionsStryde(opens in a new tab)MedID(opens in a new tab)PackagesBlog
Get in touch

Designing for the Worst-Case User: What Building an Emergency Medical ID Card Taught Us About Accessibility

Read article
Designing for the Worst-Case User: What Building an Emergency Medical ID Card Taught Us About Accessibility
INDUSTRY / HEALTHCARE & ACCESSIBILITY
April 2026

Designing for the Worst-Case User: What Building an Emergency Medical ID Card Taught Us About Accessibility

Most websites are designed for a best-case user: good connection, familiar with the product, reading in their first language, with time to figure things out. MedID, a free emergency medical ID card we designed and built in-house at DEEESIGN;, had to be designed for the opposite of all four. It is our clearest example of what accessible, multilingual design actually requires when it isn't optional.

The Problem: An ID Card That Tells You Nothing Useful

An NIC or driving licence proves who someone is, but tells a first responder nothing about how to treat them, and in an emergency the patient is often the one person who cannot answer questions. MedID solves this with a printed wallet card carrying a QR code and a PIN: a paramedic or doctor scans it at the roadside and immediately sees blood type, allergies, medications, conditions, and emergency contacts.

Designing for a Stranger, Not a User

Almost every product design process assumes the person interacting with your interface is the person who chose to be there. MedID's actual user in the moment that matters — a first responder scanning the card — is a stranger who has never seen the product before, has seconds to act, and cannot be expected to install an app or create an account first.

That constraint shaped everything: a scan-and-PIN flow that any phone camera can start, no app, no account for the responder. If a design pattern required explanation, it was the wrong pattern.

Sri Lanka Is Not a One-Language Design Problem

Any product built for Sri Lankan road users has to work in Sinhala, Tamil, and English simultaneously, not as an afterthought language switcher but as a core requirement. MedID runs in all three languages, and the printed card itself repeats its instructions in all three, because the responder reading the card may not share a language with the cardholder.

This is the piece most Sri Lankan business websites skip entirely. If your customers are genuinely trilingual, a single-language website is quietly excluding a meaningful share of the people trying to reach you, particularly outside Colombo.

Design for the Network You Actually Have, Not the One You Want

MedID had to assume a weak or nonexistent connection at the exact moment it mattered most: the roadside. Blood type can be printed directly on the physical card as a fallback for when there is no mobile signal at all. This is a useful discipline for any Sri Lankan business website too: mobile networks outside major urban centres are inconsistent, and a site that only performs well on fast, stable connections is failing a real portion of its audience, not a hypothetical edge case.

Privacy by Design, Not by Policy

Every field in a MedID health record carries its own Emergency, Private, or Only-me visibility setting, so the cardholder decides exactly what a scan reveals. This is what earning medical-grade trust actually looks like in an interface: not a privacy policy document nobody reads, but control built directly into the product itself.

The Broader Lesson

Most businesses will never build something as high-stakes as an emergency medical product. But the underlying discipline — design for the user with the worst connection, the least context, and the least patience, not the ideal one — makes every website better, not just accessibility-critical ones. It is a large part of why we build on Next.js with performance and accessibility treated as defaults rather than a final pass.

See the full MedID case study, or visit MedID to see it live.