A safety app with few controls for real tasks
Reducing controls does not guarantee simplicity. A safety app must support different real tasks, show consequences and status, and work with the accessibility settings of the person using it.
Few controls are not enough
Two large buttons may be easy to find, but they do not automatically explain recipients, location, confirmation, or status. Simplicity is observable, not a count of elements.
Review the whole path: opening, choosing, permission, sending, response, and error recovery. One control hiding five decisions can be harder than an explicit sequence.
Define different tasks
List concrete tasks such as sending an SOS, saying “I’m OK”, answering a request, or checking a contact. Each has its own urgency, recipients, and consequences.
Do not call an app simple after one trial. Check what happens when intent changes, a recipient needs correction, or another channel is needed.
Choose observable criteria
A useful criterion is whether someone finds the action without help, names who receives it, understands shared location, recognises status, and can cancel before sending.
Record hesitation, mistakes, requests for help, and message interpretations. Do not turn the result into a judgement of the person; use it to improve the path.
Test accessibility and context
Try large text, contrast, speech output, keyboard focus, orientation, low light, noise, and one-handed use. A short interface still needs to make sense in these conditions.
Check that labels and accessible names describe the same action. Colour, icons, or position cannot be the only way to distinguish SOS, OK, and cancel.
Include real cases and limits
Try slow network, locked phone, low battery, denied permission, and unavailable recipient. Few controls do not remove authentication, network, or the need to call.
Separate what the app shows from what a person will do. Delivered content does not guarantee reading, understanding, or intervention; emergency numbers remain separate.
Repeat, compare, improve
Repeat tasks with different people and devices using the same criteria. If a change reduces errors but hides a consequence, make the trade-off explicit.
Record version, settings, and test context. Recheck after updates and agree a simple fallback such as call, SMS, or printed instruction.
Frequently asked questions
Do fewer buttons always mean more simplicity?
No. Simplicity depends on the complete task, visible consequences, and the ability to correct.
How do you measure accessible interaction?
Use observable trials on real devices and settings: finding, understanding, using, correcting, and recognising status.
Does a simple app replace an emergency number?
No. In immediate danger, call the relevant local service; apps have network, device, and human-response limits.
Sources consulted
Technical and safety information was checked against the following official sources.
- W3C — clear labels
- W3C — label in name
- W3C — consistent identification
- W3C — accessibility principles
- W3C — cognitive accessibility
- Nielsen Norman Group — heuristics
- European Commission — 112
- My Safe Circle — app features
Editorial note: this guide applies W3C principles and Nielsen Norman Group heuristics to app evaluation. Sources were checked on 8 September 2026; capabilities are not inferred from button count.
TEST REAL TASKS
Evaluate the path, not the button count
Measure finding, understanding, correction, and status on real devices.
Explore My Safe CircleThis guide covers evaluation and accessibility; it does not replace emergency services. For immediate danger, call the relevant local number.
