# Lightning Bolts brand & website guide

**Version 1 · October 2026**

A shared visual system for the Lightning Bolts main website and trip microsites. It combines Mammoth’s compact, practical organization, Pali’s day-by-day guide, O’Neill’s crew photography and useful schedules, and BoltChella’s rich amenity imagery.

This is the proposed v1 standard for future builds and deliberate updates. The existing sites have not all been retrofitted to these exact colors, fonts, or components.

## The idea

Make it feel like our crew, then make it easy to use. Families should quickly find the dates, plan, RSVP, packing list, and person to contact. The site should create excitement through real experiences and good photography, without making parents dig through slogans.

Keep the same logo, core colors, typography roles, navigation behavior, and component structure across the year. Give each trip its own atmosphere through photography and a restrained accent palette.

## Logo

Use the original standalone Lightning Bolts bolt artwork. Do not redraw it, substitute a generic lightning icon, stretch it, or recolor its internal shapes. The original file is 718 × 1129 pixels; preserve that proportion with `height: auto` or `object-fit: contain`.

The same original artwork is already used by O’Neill, Pali, and BoltChella. In the source sites it appears as `assets/bolts.png`, `bolts-standalone.png`, and `assets/lightning-bolts.png`, respectively. Those files are identical. BoltChella’s separate `bolt.svg` is not the master artwork.

- Leave clear space around the mark equal to at least one quarter of its displayed height.
- Aim for a displayed mark height of 40–52 px on desktop and 40–48 px on phones.
- Pair it with “Lightning Bolts” when the club’s name is not already clear. Do not stack a second trip title beneath it merely to fill the header.
- Keep the mark legible on a plain light or dark surface. If a photo is too busy, use a solid header.
- If adjacent text already names the club, give the mark empty alt text and give the home link a clear accessible name. Otherwise use “Lightning Bolts” as its alt text.
- Use a matching favicon derived from the original artwork, not a new lightning symbol.

## Color

### Core palette

| Role | Color | Use |
|---|---|---|
| Navy | `#112C3E` | Mastheads, dark feature bands, strong emphasis |
| Ink | `#142D3D` | Default text, headings, icons |
| Bolt yellow | `#FBD643` | Primary action, selected indicator, small highlight |
| Cream | `#F6F3EA` | Main page background |
| Paper | `#FFFEF9` | Cards and light content surfaces |
| Muted | `#526773` | Supporting text that still needs to be read |

Use cream and paper for most of the page. Navy gives structure; yellow directs attention. Avoid placing every section in a colored box. The red in the original logo stays in the logo; it does not need to become a competing page accent.

### Event accents

| Theme value | Event use | Soft surface | Deep accent |
|---|---|---|---|
| `crew` | Main site, general club pages | Core cream/paper | Core navy |
| `snow` | Mammoth | Ice `#DCEBF0` | Alpine `#2D6678` |
| `camp` | Pali and O’Neill | Sage `#E6EAD8` | Forest `#3D5547` |
| `river` | BoltChella / Lazy River | Sand `#F4E4CE` | Pool `#006C70` |

Accents can identify tabs, subtle card backgrounds, borders, and trip-specific details. Keep the main RSVP action yellow across every trip. Do not invent a new yellow or change the logo colors for each event.

### Contrast-safe pairs

The following ratios were calculated from the exact solid colors above. They meet the WCAG AA 4.5:1 text contrast threshold, including normal-sized text.

| Text / background | Ratio |
|---|---:|
| Ink / paper | 14.12:1 |
| Ink / cream | 12.85:1 |
| Navy / yellow | 10.18:1 |
| Paper / navy | 14.31:1 |
| Muted / cream | 5.34:1 |
| Muted / paper | 5.86:1 |
| Alpine / paper | 6.33:1 |
| Forest / paper | 8.03:1 |
| Pool / paper | 6.15:1 |

Yellow on paper is only 1.41:1. Do not use yellow for small text or a stand-alone focus indicator on light surfaces. Use navy text on yellow buttons. Images, transparency, gradients, hover states, and disabled states need their own contrast checks; a palette alone does not guarantee an accessible page.

## Typography

Use **Caveat Brush** for trip display headlines and **DM Sans** for body copy and interface text. Self-host the supplied fonts, preserve their license files, and use `font-display: swap`.

- **Main website mode:** a clean DM Sans hero and heading treatment.
- **Trip mode:** Caveat Brush for the single event title and selected major section headings.
- **Every mode:** DM Sans for navigation, dates, countdown numbers, buttons, facts, timeline entries, contact details, packing lists, forms, and helper text.
- Caveat Brush is a regular-weight display face. Use its real weight rather than synthesizing bold.
- Do not turn every heading into a brush headline. Dense practical sections should feel calm and readable.

### Working type scale

| Element | Desktop | Phone | Treatment |
|---|---:|---:|---|
| Trip hero title | 80–112 px | 56–72 px | Caveat Brush, tight but unclipped line height |
| Main site hero title | 52–72 px | 38–48 px | DM Sans, bold |
| Major section heading | 36–48 px | 30–36 px | Mode-appropriate display face |
| Card / subsection heading | 20–24 px | 20–22 px | DM Sans, semibold or bold |
| Intro paragraph | 18–20 px | 17–18 px | DM Sans, 1.5–1.65 line height |
| Body / practical details | 16–18 px | 16–17 px | DM Sans, 1.5–1.65 line height |
| Navigation / buttons | 15–16 px | 14–16 px | DM Sans, semibold or bold |
| Supporting label | 13–14 px | 13–14 px | DM Sans; never the only home of essential information |

Use fluid sizes inside these ranges. Let long event names wrap naturally rather than shrinking them to unreadable text. Keep body lines near 45–75 characters. Sentence case is the default; reserve short uppercase labels for dates or meaningful categories.

## Space, shape, and page rhythm

Use a simple 4 px spacing system: **4, 8, 12, 16, 24, 32, 48, 64, 72, 96**.

- Content width: 1160 px maximum, centered.
- Outer gutters: 20 px minimum, expanding naturally when the centered 1160 px content width is reached.
- Section padding: 72 px desktop and 44 px phone. Use 24–32 px between closely related sections.
- Card padding: 24–32 px desktop and 20–24 px phone.
- Use small 4–8 px radii, thin borders, and mostly flat surfaces. Avoid making the page a wall of pill shapes or floating cards.
- Use a dark band when it creates a useful change of pace, such as RSVP. Do not alternate backgrounds mechanically.
- Avoid tall, sparse sidebars and large blank spaces opposite dense text. Essential facts should precede secondary photos on phones.

## Headings and navigation

**One page title. One useful heading per section.** A heading should tell a family what they can find there.

Preferred labels: “The plan,” “The weekend,” “On the mountain,” “What to pack,” and “RSVP.” Do not add an eyebrow, a decorative slogan, and another heading above the same information. A short supporting sentence is enough when context is needed.

Keep the main header compact. Aim for four or five useful in-page links and the primary action. Use plain labels and visible keyboard focus. A mobile header can wrap into a deliberate second row or use a properly labeled menu; do not squeeze labels until they are hard to tap.

Each trip is self-contained. The brand link can return to the trip’s top. Put the main club home and other event links at the very bottom of the footer, after the current trip’s content. Do not add a season-wide navigation bar above a trip.

## Photography

- Feature real crew photos whenever suitable images exist. They are the identity of the club, not a separate historical appendix.
- Use venue photography to explain a specific activity, amenity, lodging option, or destination.
- Give each image a purpose. A hero, an activity detail, and a gallery can use different photographs instead of repeating one decorative shot.
- Preserve people’s faces on desktop and mobile. Choose focal points deliberately and review the actual crops.
- Prefer text beside or below a photo when an overlay would cover the people. If using overlay text, test the busiest and lightest areas behind it.
- Use a gallery for large photo sets. Provide labeled previous, next, and close controls; keyboard navigation; Escape to close; and focus restoration.
- Avoid visible “official photography” labels or unnecessary credit banners. Preserve attribution required by the image’s license or permission in an appropriate location.
- Keep useful alt text concise. Use empty alt text for images that are genuinely decorative or repeat adjacent content.

## Standard trip structure

1. **Hero:** date, event name, one short invitation, primary action, and a meaningful image.
2. **The plan:** departure/arrival, return, destination, cost basis, and essential trip facts.
3. **Schedule:** compact day tabs or a short linked timeline. Choose the format that fits the trip.
4. **Experience and resources:** photos paired with useful links, such as lessons, trail maps, cabins, or amenities.
5. **Packing:** grouped checklist with saved progress, a visible reset, and an optional print/download version.
6. **Planning team and practical details:** relevant contacts, confirmed booking information, and a concise note for what remains pending.
7. **Calendar and footer:** add-to-calendar links, trip sharing, then links to other events at the bottom.

An RSVP band can appear after the plan or near the end where it serves the page. Do not force every event into every section. A simple evening event needs a shorter page than a three-night trip.

## Buttons, RSVPs, and trip status

Use **RSVP** for an open attendance form. The header, hero, and RSVP section should point directly to the same current form. Avoid adding another intermediary click or changing the label to “Family RSVP” without a reason.

When sign-up is not open, use **Save the dates** and state that RSVP details will follow once. Do not show a button that looks live but cannot complete its action.

Real RSVPs should support updates when the form platform allows it. Verify response editing and the confirmation/edit-link flow before saying families can edit. Do not claim a form reserves a room or purchases lessons unless that is what the underlying workflow actually does.

Present the cost basis clearly:

- **Included in Bolts dues** when confirmed.
- **À la carte — not included in Bolts dues** when applicable.

Do not publish prior-year prices or vendor terms as this year’s confirmed arrangements. Put pending details in one clear note, not repeated across every card.

## Countdown and calendars

A countdown should help a parent plan. Display the event’s actual confirmed departure or arrival target beside it, with the timezone.

For Mammoth 2027, the agreed target is **Thursday, January 28, 2027 at 8 a.m. Pacific** (`2027-01-28T08:00:00-08:00`). This is a trip-specific decision, not a default time for every event.

If only the date is known, use a calendar-day countdown and say the arrival time will follow. Do not invent a midnight check-in. Handle “today,” “underway,” and “finished” states without negative numbers. Avoid screen readers announcing a changing timer every second.

Keep the calendar event’s date range and description consistent with the site. An all-day weekend calendar entry can still state the exact departure time in its description. Check Google Calendar and downloaded ICS separately.

## Voice and factual standards

Write like a helpful parent organizing a great weekend: warm, direct, specific, and brief. Lead with what families need to do or can look forward to.

Use real activities instead of vague promises. “Ski, ride, or book a lesson” is more useful than “Endless adventure awaits.” A little personality belongs in the hero; the schedule and packing list should be practical.

- Use the exact event names: **Mammoth**, **Pali**, **O’Neill**, and **BoltChella**.
- Use current-year plans. Previous trips can inform logistics without becoming the page’s subject.
- Confirm dates, addresses, contacts, availability, and links against their sources.
- Label unconfirmed information simply. Do not turn assumptions into instructions.
- Include a teacher-notification reminder once when a trip requires missing school or leaving early.
- Do not publish private roster, contact, or response data without the applicable authorization.

## Accessibility and interaction rules

- Use semantic headings, landmarks, labels, and a skip link.
- Keep normal text at least 4.5:1 contrast and large text at least 3:1. Check controls and focus against their actual surroundings.
- Make interactive targets at least 44 × 44 px where practical. Do not rely on color alone to show selection or status.
- Tabs must support click, arrow keys, Home/End, `aria-selected`, and a clear relationship to their panels.
- Keep essential content available if JavaScript fails. Do not ship all schedule panels hidden before enhancement initializes.
- Respect reduced-motion settings. Avoid unnecessary autoplay and scroll animation.
- Preserve a sensible reading and keyboard order; do not visually rearrange the hero into a different logical order.
- Use stable packing-item IDs so edits do not shift a family’s saved checkmarks to different items. Provide honest behavior if storage is unavailable.
- Validate desktop plus 390 px and 320 px widths: no horizontal overflow, clipped headings, hidden faces, or overlapping controls.
- Print views should show every schedule day and a useful packing list.

## Adopt the shared styles

Load the tokens first, then the components. Adjust the paths to match the host project:

```html
<link rel="stylesheet" href="/brand/tokens.css">
<link rel="stylesheet" href="/brand/components.css">

<body class="lb-site" data-lb-theme="snow" data-lb-mode="trip">
  <!-- Use the supplied starter and component patterns here. -->
</body>
```

Use these combinations:

| Page | `data-lb-theme` | `data-lb-mode` |
|---|---|---|
| Main Lightning Bolts website | `crew` | `main` |
| Mammoth | `snow` | `trip` |
| Pali / O’Neill | `camp` | `trip` |
| BoltChella | `river` | `trip` |

The shared styles are scoped to `.lb-site`. Keep the data attributes on the body as shown. Reuse the supplied components and token names rather than copying legacy site CSS into the new page. Load only the needed self-hosted font files and preserve their licenses.

For an existing site, migrate deliberately: first the shared tokens and typography roles, then navigation/buttons, then section spacing and components. Compare the result against the current working page before release. A brand update must preserve RSVP destinations, response editing, calendar files, countdown targets, saved packing state, and useful trip content.

Use scoped page-specific CSS only for a real event need, such as a photo focal point or a lodging comparison. Do not create another near-identical yellow, a second heading system, or a long chain of late overrides.

## Release check

Before publishing a new trip or a major update:

- One title, direct section headings, no repeated date/location/header clutter.
- Original logo, shared font roles, correct event theme, readable contrast.
- Current verified dates and logistics; one clear pending-details note if needed.
- Working RSVP destination, verified edit behavior, consistent button labels.
- Correct Pacific countdown target and matching calendar details.
- Crew/venue photos crop well on desktop and phones; gallery keyboard flow works.
- Packing persistence and reset behave correctly; all schedule days remain accessible.
- Contacts and links work; no private response data has leaked into the page.
- Other event links appear only at the footer’s end.
- Published page checked on its actual public URL after deployment.