SeansaNote · The design system underneath

None of the screens in that product were drawn one at a time. They come out of a token set and a small group of primitives, and the rules holding those together had four things to survive at once.

One codebase, three targets. Expo: React Native on iOS and Android, React Native Web at the desk. Not three design languages, and not one scaled three ways.

Two densities with opposite jobs. The phone optimises for a single record at speed; the desk optimises for many records at a glance. A system that only knows how to shrink produces a phone that is a cramped desk.

A runtime missing tools most systems assume. React Native has no CSS grid and no pseudo-elements. Every layout is flexbox and every decorative mark is a real element.

One person. There was nobody to hand a spec to, which cuts both ways: no translation loss, and no second opinion either. Every rule below exists because a screen forced it, not because a document said so in advance.

Colour here is not a matter of taste and it is not checked by eye. The palette has its own audit, and the build fails if a pair drops below its floor:

The script’s own comment says why it exists: guessing hex values that look about right fails this reliably, so the palette is checked instead. Placeholder text is in the audit deliberately. It is the contrast people most often let slide, and it is the text somebody reads while deciding what a field wants from them.

The scale is fixed rather than fluid, which is a deliberate break from how most web systems are built now. A caseload read at a consistent distance on a consistent screen is not served by headings that clamp with the viewport; growing the window should earn more columns, not bigger type. Past 1024px that is exactly what happens — the register widens and gains columns, and the type does not move.

Three structural primitives carry nearly every screen. Section is an 11px uppercase label over a hairline-ruled group, with more space above a heading than below it. Row is a 56px minimum target with a hairline under it, and it is the primary content unit everywhere. Panel is a bordered block used only where content genuinely needs a boundary, and never inside another one.

One worked example of the rule paying off. The client register at desk width used to carry a phone column, which left roughly 650px of dead space between the name and anything useful. Phone came out; last session and next appointment went in, because a therapist scanning the register wants to know when they last saw someone and when they next will. Status became a 6px dot inside the name cell rather than a filled badge, since status is not an action and a column of saturated pills was contradicting the rule that the only saturated pixels on screen are the ones meant to be pressed.

Lists ship loading, empty and error alongside their normal state. Loading uses skeleton rows that match the real row rhythm rather than a centred spinner, so nothing jumps when the data lands. Empty states teach the interface instead of reporting absence.

Motion is 150 to 250ms, ease-out, and conveys state only. There is exactly one authored moment in the product: while dictation is recording, seven bars track the live input level with the centre bars reacting most, so it reads as a voice rather than as a progress bar. The microphone is solid accent at rest and solid danger while recording — the same two colours the rest of the system already uses, doing a job nobody has to learn.

A system is easiest to judge on a single component that had to change. The booking sheet went through three shapes, and every problem with the first two was found by watching it used rather than by looking at it.

The first version was a form: six labelled fields down the sheet, which is how you draw a screen when you are thinking about the row you are about to insert rather than about the person filling it in. Booking a session is not six equal decisions. It is one client, one time, and some details, so the second version dropped the labels for a denser composer with icons and chips.

That bought density and lost clarity. The title field and the client field ended up four rows apart, each silently clearing the other, with nothing to say they were alternatives. Asking the question outright surfaced a bug the ambiguity had been hiding: validation used to catch a missing client by accident, because an empty client meant “this is a hold” and the title check fired instead. With the kind declared up front the two cases stopped covering for each other, and a session with no client would have reached the database and been refused by a constraint. It now fails in the sheet, in Serbian.

Two more problems followed, both about the sheet refusing to stand still.

Switching between the two kinds moved every row below the toggle, because the title field appeared above the time chips while the client row disappeared below them. They are the same question, who or what is this, so they became one row that swaps in place.

Then removing the delivery row for a personal hold made the sheet a row shorter. A bottom sheet is anchored to its bottom edge, so everything above it slid down, including the toggle the finger had just pressed: measured in the browser, it sat at y=1094 as a session and y=1185 as a hold. The fix was not to pad the gap. A hold now takes that slot with a line explaining what a hold is — it blocks the therapist’s own schedule, clients never see it, and the public link cannot book over it. That needed saying anyway, because Lično does not explain itself, and it means the toggle, the chips, the room and the save button sit at identical positions in both states.

app.seansanote.rs

Working without CSS grid and without pseudo-elements sounds like a tax, and for the first month it was. A focus ring cannot be an ::after; it is a border and a shadow on the component itself. A decorative rule cannot be a ::before; it is a View with a height of one.

What that produces, though, is a visual language that leans on hairlines, row rhythm and spacing rather than on clever boxes — and those are the things that were load-bearing anyway. Every effect that survived the constraint survived because it was doing structural work. The ones that did not survive were decoration I would have kept if the platform had let me.

Shadows went the same way. Nothing has a resting shadow; only an overlay gets one, and it is a real offset with a soft blur rather than a halo at zero. A uniform radius everywhere is a costume for the same reason: sixteen pixels is wrong on a 32px button and right on a full page plate, which is the actual reason current interfaces read as current. Their controls are no rounder than these. Their surfaces are simply bigger.

I built the system alongside the product rather than ahead of it. That is the right order for one person — a spec written first would have described screens I had not met yet — but it cost me two things.

The dashboard was the one screen that contradicted my own structural rule, and I only saw it once it was in front of me. Half a day of rough layouts would have caught that before a week of code did.

And the contrast audit arrived late. It passes now, but it passed because I went back and moved values, not because the palette was built against the floor from the start. A system that gates its own build is worth having; a system that gates it from day one is worth more, and costs less.