Skip to content

Design Principles

Each principle follows a testable format:

[Principle name]: [One-sentence statement]. Test: [How would you know if a design decision violates this?]

These are working hypotheses, not finalised:

Every screen should feel like an editorial decision was made. If it could be auto-generated, it’s not curated enough. Family content submission must always be curated — never auto-populated into the museum. Test: Could this layout be produced by an algorithm? If yes, rethink it.

The interface recedes. Content — photos, audio, stories — comes forward. Chrome is minimal. Test: If you blur the UI, can you still tell what the content is about?

Every interaction should feel like being inside a museum — smooth transitions, considered pacing, spatial awareness. Login should feel like entering a building, not filling in a form. Non-functional requirements include smooth transition animations on login and between rooms. Test: Does this interaction feel like it belongs in a museum, or in a SaaS dashboard?

The exhibit experience should convey the passage of time — not just display dates, but feel like a journey through someone’s life. Test: Remove all dates and captions. Does the sequence still tell a story?

The brand promise is a “wow factor” that exceeds expectations. The content does the storytelling, but the UI can’t feel generic. The visual quality must match what a family expects from a commissioned experience. Test: Would a family be proud to show this to the people they love?

Every border-radius in the gallery surface comes from a tenant-aware token (var(--sk-radius-box) or var(--sk-radius-photo)). No hardcoded numeric literals. No rounded-* Tailwind utilities outside the capsule allowlist. This guarantees that a tenant who chose radius_variant: "none" actually gets zero rounded corners — not “almost zero,” not “mostly zero.” Enforced by lint, contract test, and visual snapshot. Test: For a tenant set to none, can you find a single rounded corner anywhere on their gallery surface? If yes, it’s a bug — open it.

List view at ≥ 1280px container is an exhibition register: single photographs earn one screen of viewport height (h-[80vh], width derived from aspect, centered with whitespace either side for portraits), and photosets prove their value by showing four photographs inline in an asymmetric constellation — not by hiding behind a thumbnail. A photoset that would render as a small tile in a list deserves to be seen as a coherent group. The corollary: never crop a single photograph to fit. A picture must be visible in one viewport at its full natural shape; if a portrait would be too tall, scale it down with width adjusting to maintain aspect — don’t cover-crop the head off. Test: Open the gallery at 1440. Can you see, at a glance, four photographs from each set without opening the lightbox? Is any single photograph cropped on either axis? If yes to the first or no to the second, it’s a bug — open it.


These will be refined as the design matures.