--- title: "Photography" description: "The narrow set of places a photograph belongs in a health product, the stock-photography failure mode, and the consent questions a design system cannot answer." url: "https://opsinjs.pensievelabs.org/foundations/imagery/photography" source: "https://opsinjs.pensievelabs.org/foundations/imagery/photography.md" section: "Foundations" kind: "foundation" reviewed: "2026-09-20" reviewer: "engineering" aliases: ["photos", "stock photography", "image selection"] --- > Elements written as `` below are opsinjs documentation > components. Their attributes are the content: the values they render are > generated from `tokens/*.json` and `registry/catalogue.ts` and are > published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference > section. > Nothing is missing from this page. The data simply does not live in > the prose. ## Overview [#overview] Photography has a narrower role in a consumer health product than in almost any other kind of interface. A photograph shows a specific person, in a specific body, at a specific moment, and every one of those specifics is a claim. There are three places a photograph genuinely helps: showing a physical object so somebody can recognise it, whether that is a device, a meter or a test kit; showing a real place or a real person where the product is genuinely about them, such as a named clinician a reader is about to meet; and a photograph the reader took themselves, of a symptom, a meal or a reading. Everywhere else, the honest options are an illustration or nothing. opsinjs ships no photography and no photographic guidance beyond the rules below. A product using photography is making brand decisions that a design system should not be making for it. ## How it works [#how-it-works] **The stock-photography failure.** The default stock health image is a young, slim, able-bodied, usually white person doing something wholesome in good light. Used once it is unremarkable; used throughout a product it is a statement about who the product imagines its reader to be, and the reader who is not that person notices. This is the concrete failure that [Skin-tone representation](./skin-tone-representation.mdx) exists to address, and it applies to age, body size and visible disability just as much as to skin tone. **Photographs of people carry consent obligations.** Model releases and licensing terms are two of them. Informed consent is a third, required where an image comes from a real patient, a real clinician or a real setting, and it must be specific about the context of use. These are legal and ethical questions, they vary by jurisdiction, and they are the product's to answer. **Clinical photography is a different discipline entirely.** A photograph of a rash, a wound or a symptom used to help somebody compare their own is a clinical image. It needs clinical review, it needs to exist across a range of skin tones or it is useless to most readers, and it needs a warning before it is shown. That is a product decision with clinical governance behind it, not an image-selection decision. **Photographs do not go behind text.** A photographic backdrop under a health value is the case the [material ladder](../materials/the-contrast-floor.mdx) exists to handle, and the only reliable answer is a scrim heavy enough that the contrast floor is met against the worst region of the image. Where a value is involved, do not put it over a photograph at all. **Photographs taken by the reader are content, not decoration**, and they belong to the reader. They are shown at the size and orientation they were taken, never cropped in a way that changes what they show, and they are covered by the product's privacy posture. See [On-screen privacy](../../health/on-screen-privacy.mdx). ## Using it [#using-it] **Ask whether the photograph is doing recognition work.** "Will the reader recognise a physical thing because of this?" is the question that separates a useful photograph from a mood board. A plain photograph of the blood-pressure monitor the product supports, on a neutral background, so a reader can tell whether the one in their drawer is the right one. A lifestyle photograph of somebody smiling at a monitor, used as a header on the same screen. It shows nothing recognisable, it takes the space the instructions needed, and it tells a reader who does not look like the model something nobody intended to say. **Do not use a photograph to set a mood on a results screen.** Mood is the wrong thing to be setting when somebody is reading a number about their own body. **Never put a value over a photograph.** No scrim makes a photographic background a reliable surface for a measurement, and the reading is the one thing on the screen that must be legible in every condition. **Do not crop a symptom photograph.** Cropping changes what an image shows, and for anything a reader might compare against their own body that is a correctness issue rather than a layout one. **Show a warning before clinical imagery.** A reader who has arrived at a page about a symptom has not consented to seeing a photograph of it. An interstitial with a plain description and an explicit control to view is the minimum. ## Tokens [#tokens] Photography consumes the shape scale for corners and the material ladder for any surface over an image, in particular the scrim rung. It owns nothing. ## Accessibility impact [#accessibility-impact] * **A photograph's alternative text depends entirely on its job.** A device photograph is described so it can be recognised; a decorative one is hidden; a clinical one needs a description written by somebody qualified to write it. * **Text over photography is a contrast problem with no general solution**, because the background varies across the image. The scrim rule and the measured floor are on [The contrast floor](../materials/the-contrast-floor.mdx). * **Distressing imagery is an accessibility barrier.** Clinical photographs, needles, blood and wounds cause avoidance in a substantial number of readers, including many with the conditions the product serves. A warning and an explicit control to reveal is the accommodation. * **Photographs are heavy**, and weight is an accessibility issue for readers on limited data or slow connections. Those readers correlate with the readers a health product most needs to reach. * **A reader's own photographs are personal data on screen**, subject to the same hide-and-blur posture as any other health value. ## Related [#related] * [Skin-tone representation](./skin-tone-representation.mdx) is the requirement that applies to any photographic set showing people. * [Materials → The contrast floor](../materials/the-contrast-floor.mdx) has the scrim rule for anything over an image. * [On-screen privacy](../../health/on-screen-privacy.mdx) says what happens to a reader's own images when the app goes to the background.