The product lens

A practice that fits on one laptop

No server. No account. No internet.

  1. One doctor, one device, every record
    01One doctor, one device, every record — A practice companion designed around the constraint that nothing leaves the machine.Full size ↗
  2. The doctor hospital software ignores
    02The doctor hospital software ignores — Six user types, each one a specific person the product is shaped around.Full size ↗
  3. The feature that says when it cannot work
    03The feature that says when it cannot work — Audio is always captured. Transcription is not always available, and the app admits it.Full size ↗
  4. A latch, not encryption
    04A latch, not encryption — The security boundary stated in the words a doctor can act on.Full size ↗
  5. Six load-bearing decisions in the data model
    05Six load-bearing decisions in the data model — Each one exists because of something that happens in a real consulting room.Full size ↗
  6. A day queue, not a calendar grid
    06A day queue, not a calendar grid — The single clearest case of modelling what happens rather than what software usually does.Full size ↗
  7. When the device holds the only copy
    07When the device holds the only copy — Offline is a promise with a consequence, and the consequence is a feature.Full size ↗
  8. The features deliberately left out
    08The features deliberately left out — Four v0.1 limits the project states about itself, each with its reason.Full size ↗
  9. What this artifact does not establish
    09What this artifact does not establish — The stated-limits section. Every artifact in this set ends with one.Full size ↗

Concept, product design and implementation — executed. Written from the repository and the README. No doctor has used it: every user type described is a designed-for user, not an observed one.

Back to the written studyAll case studies

B-SIDEOff the record
A practice that fits on one laptop — the document — Ashish Narayan