Search for a command to run...
No comments yet. Be the first to comment.
A 12-part series on building a privacy-first, accessibility-first, offline-first health PWA.
After you ship, the most valuable lessons are rarely the technical ones. They’re the ones about what users actually need when life is hard. A retrospective is only useful if it names the tradeoffs. If you’re building anything “health-adjacent,” you w...
How I built a local first pain tracker around failure safety, user ownership, and the reality of chronic illness.
By CrisisCore Systems Pain Tracker is a private pain tracking app for logging symptoms, spotting flare patterns, and preparing for appointments without creating an account or sending daily records to the cloud. It is built for people who want practic...
Injury didn’t just break my back. It rewrote my personality.
Discovering the Reality of Creating from Survival and How It Can Help Others
When something goes wrong in a health tool, the user can lose trust and momentum. Your job is to fix problems without turning the app into surveillance. Shipping a health-adjacent tool is different from shipping a hobby app. Reliability is part of ca...
Most people don’t quit because an app is missing a feature. They quit because the tiny moments of friction add up—especially when they’re already in pain.
The best features in a chronic pain app are often not “new screens.” They’re the small interaction decisions that reduce effort, prevent mistakes, and preserve dignity.
These details matter because they show up in the moments when the user is already overloaded.
We’ll focus on three flows that define whether a pain tracker is usable in real life:
1) logging (capture) 2) reviewing history (sensemaking) 3) exporting (advocacy and clinical/workflow utility)
On a good day, almost any UI works.
On a bad day, the user has less energy, less tolerance for ambiguity, and less ability to recover from errors. So your UI should be optimized for:
The fastest path should always be available and always be meaningful.
Example minimum:
Everything else is additive.
This is how you respect variable energy: the app accepts the user’s best effort today.
Typing is expensive.
Use:
The goal isn’t to constrain the user. It’s to reduce cognitive load.
If you guess, make the guess safe.
Reversibility is accessibility.
Advanced fields should exist, but they shouldn’t block the primary task.
Keep them behind an explicit “Add details” step that never feels mandatory.
History views often fail because they ask users to do math with their pain.
Your goal is not to “prove” anything. Your goal is to help the user notice patterns and prepare for a conversation with a clinician, employer, or support person.
Start with:
Then allow drill-down to the full entry.
This supports brain fog: users can orient first, then explore.
If your UI implies causality (“weather caused flare”), you will harm trust.
Prefer language like:
This is more clinically honest and less emotionally loaded.
Charts are optional. Comparisons are useful.
Provide:
If you do show charts later, make them readable, labeled, and keyboard/screen-reader compatible.
Exports are where a pain tracker becomes an advocacy tool.
They’re also a major privacy risk because exports are designed to leave the device.
Treat export as a boundary crossing.
Avoid hidden background exports, autosync, or “share to cloud” defaults.
Start with:
Then allow opt-in detail:
This reduces accidental oversharing while still supporting clinical needs.
Exports should be:
If a report reads like a marketing brochure, it won’t be trusted.
Export UI must be accessible too:
For each primary flow (log, review, export), verify:
1) Fast path exists (under 30 seconds) 2) Partial completion is supported 3) Keyboard + screen reader works end-to-end 4) Errors are recoverable and non-shaming 5) No surprises at the export boundary
Next, Part 6 turns the offline-first promise into a practical checklist: what to cache, how to think about background sync (if any), and how to fail safely when storage, network, or updates go sideways.
