Our Design Manual

Daily Website Report started as a simple promise: tell site owners the truth about their site — security, SEO, performance, uptime — in plain language, once a day, without the anxiety-marketing that the rest of this industry runs on. This document is the visual and interaction language we use to keep that promise consistent everywhere the product shows up: the marketing site, the dashboard, the emails, the reports themselves. It's written for our own team, our contractors, and anyone integrating with us who wants their work to feel native to the product. We're publishing it because we'd rather be transparent about how we build than precious about it.

1. Principles

Four ideas steer every screen we ship. When a design decision is ambiguous, these are the tiebreakers, in order.

• Calm over alarming. A security scanner has a natural incentive to make everything look scary so people upgrade out of fear. We refuse that pattern. Red is reserved for things that are actually broken. Everything else is amber, green, or quiet gray.
• Plain language over jargon. If a finding needs a CVE number, it also gets a sentence a non-technical site owner can act on. The UI never assumes the reader is a security engineer.
• Warm on the outside, precise on the inside. The marketing site and news pages use a warm, human palette because that's where we're building trust with someone who hasn't signed up yet. The authenticated app uses a cooler, quieter palette because that's where people are reading data and need it to sit still.
• One system, two rooms. Marketing and product are visually distinct on purpose (see §2), but they share the same type family, the same radius logic, and the same motion rules, so moving from the landing page into the dashboard never feels like switching products.

2. Color

We run two coordinated palettes rather than one compromise palette. The Marketing palette is warm and used on the public-facing pages: the homepage, pricing, and this news section. The Product palette is cool and neutral and used everywhere behind login: the dashboard, scan reports, admin. Both share the same indigo family as the brand accent, so the transition between them still reads as one company.

2.1 Marketing palette

Warm cream backgrounds, near-black text, and a soft indigo accent paired with a peach and mint for illustration. Used on landing.blade.php, /news, and this page.

Rules of use: cream (--bg) is the page floor, white (--surface) is anything raised — cards, the nav, form fields. Indigo is reserved for calls to action, links inside interactive components, and the brand mark; it never fills large background areas. Peach and mint are accents for illustration and icon tiles only — they don't appear in body text or as button fills on their own.

2.2 Product palette

The authenticated app trades cream for a quiet neutral gray, defined in oklch() so contrast stays perceptually consistent as we adjust hue. Same indigo family, shifted slightly cooler and darker for AA contrast on white cards.

Status color is a promise, not a decoration. Green means the check passed. Amber means it needs attention but nothing is on fire. Red means something is actually broken or insecure right now. We never use red for "upgrade to see this" or other commercial nudges — mixing commercial urgency into the same color as a real security failure is exactly the manipulative pattern we're avoiding.

3. Typography

Two families, no more. Public Sans (weights 400–800) carries every UI label, heading, and paragraph across marketing and product. IBM Plex Mono is reserved for anything literal: URLs, hostnames, scan output, grades, timestamps — the moment text stops being prose and starts being data, it switches to mono so the reader's eye recognizes the shift instantly.

Scale, roughly geometric, tuned by eye rather than a strict ratio:

• Display / hero: clamp(36px, 5.6vw, 66px), weight 700, letter-spacing −0.028em — homepage headline only.
• H2: clamp(28px, 3.8vw, 46px) on marketing, 25px inside articles, weight 700, −0.02 to −0.025em tracking.
• H3 / H4: 17–19px, weight 700, little to no tracking adjustment.
• Body: 16–17px at 1.6–1.75 line-height on marketing and articles; 15px at 1.55 in the denser product app.
• Small / meta: 12.5–13.5px, often mono, used for dates, eyebrows, and captions.

Negative letter-spacing scales up with size — big display type is tracked tight (−0.028em), body text is left at 0. We never tighten body copy; it hurts legibility for no visual gain at that size.

4. Spacing, radius & elevation

Corners are one of the clearest brand signals in the product, so the rule is simple and applied everywhere, marketing and product alike: the bigger the surface, the bigger the round.

Elevation is done with soft, colored shadows rather than gray drop-shadows — a shadow tinted toward the accent color it's sitting under (e.g. 0 20px 40px rgba(107,92,255,.10)) reads as "lifted and warm" instead of "gray and flat." Shadow spread increases on hover, never on click — pressing a button should feel like it's settling down, not popping further up.

5. Components

5.1 Buttons

Three intents, one shape: full pill radius (999px) at every size.

• Primary: solid near-black (marketing) or solid accent gradient for the highest-priority action on a page — only one primary-gradient button per view.
• Accent gradient: linear-gradient(135deg, var(--accent), var(--accent-2)), used for the single most important conversion action (start a scan, subscribe, upgrade).
• Ghost: transparent fill, 1px border, used for every secondary action next to a primary one.

Hover lifts the button 1px and deepens the shadow over 150ms; nothing about a button's shape or padding changes on hover, only shade and elevation — the click target stays perfectly stable.

5.2 Cards & surfaces

Every card is white-on-tint: a light 1px border (never a shadow alone to define the edge), a soft shadow that only appears or strengthens on hover, and content padded generously — 26–34px on marketing, 18–20px in the denser app. Cards never nest inside other cards; if content needs a visual grouping inside a card, we use a plain bordered row, not a second card.

5.3 Forms & inputs

Inputs share the app's border and radius tokens, sit on the surface color (never on the page background), and take a visible 2px focus ring in the accent color — we do not rely on border-color-only focus states, since that fails for low-vision users. Placeholder text always uses the mono face when the expected input is a URL, domain, or code, so the field itself hints at the expected format before anyone reads the label.

5.4 Status badges & the eyebrow chip

Small pill-shaped, high-contrast labels used for scan results and plan tiers alike: pale tint background, saturated text of the same hue, thin border one step darker than the tint. The homepage "eyebrow" chip (e.g. "Live scanning" above the hero headline) uses this same shape with a small pulsing mint dot — the one piece of looping animation we allow above the fold, because it's communicating something genuinely live.

5.5 Icon tiles

Feature icons are never flat single-color glyphs — each sits in a 46×46px tile with its own two-stop diagonal gradient (indigo for security/SSL, orange for threat findings, gold for SEO, teal for performance, green for uptime, purple for fixes), a soft matching shadow, and a faint inset highlight along the top edge to suggest a light source. The gradient is the category's identity — once someone has seen a few reports, they recognize "orange tile" as security findings before reading the label.

6. Motion

Motion is used to explain, never to decorate. Every animation on the site maps to one of three jobs:

• State change feedback — a button lifting on hover, a FAQ chevron rotating 45° when it opens, a progress bar filling. Durations sit between 150–220ms with an ease curve; nothing linear, nothing longer than a quarter second for a direct-response interaction.
• "This is alive" signals — the pulsing dot on the live-scanning chip, the slow drifting gradient blobs behind the hero. These are slow (2s–22s), subtle, and always opacity/transform only so they're cheap and don't fight for attention.
• Gentle ambient float — the browser-mockup preview panel on the homepage drifts ±5px over 9 seconds. It's there so a static screenshot doesn't feel like a dead image, not to be noticed consciously.

We don't animate page transitions, list re-ordering, or anything that would delay a user from reading real data. If in doubt, the faster and stiller option wins.

7. Voice & tone

Copy follows the same "calm over alarming" principle as color. A few concrete rules:

• Lead with what's true, not with what's scary. "Your SSL certificate expires in 9 days" beats "Your site could be exposed!"
• Every finding gets a next step in the same sentence or the one right after it — never a bare warning with no action.
• No countdown timers, no fake scarcity, no "3 people are viewing this plan right now." Trust is the product; manufactured urgency undercuts it.
• Numbers over adjectives where we can: "14ms TTFB" instead of "blazing fast," a grade letter instead of "great score."

8. Accessibility

Baseline commitments, checked on every new screen before it ships:

• Text and interactive elements hold WCAG AA contrast (4.5:1 body, 3:1 large text) against their background in both the marketing and product palettes.
• Every interactive element gets a visible focus state — the 2px accent ring described in §5.3 — never outline: none without a replacement.
• Color is never the only signal: status uses an icon or label alongside the color (a checkmark glyph, the word "PASS"), so the page still reads correctly for color-blind users or in a black-and-white printout.
• The "live" pulse animation and hero blobs respect prefers-reduced-motion and drop to a static state when it's set.

9. Where this lives in code

The marketing palette and components live in landing.css under the .ln- prefix; the product palette lives in app.css as CSS custom properties on :root. Both load Public Sans and IBM Plex Mono from the same Google Fonts stylesheet, so a page never pays for the fonts twice. This manual will get updated in place as the system evolves — treat it as the current source of truth, not a historical snapshot.