---
inclusion: always
---

# Audience: Gearious (Web)

A working example of an audience steering file. Abridged for sharing.

Who uses the app, what they care about, and how much complexity they can absorb. When a design choice involves how much to show, what to call something, or what to default to, this file is the reference.

**Scope & context:** The web app is the **planning** surface — used at home, before a trip, deliberately, most often on a laptop or desktop (but it must stay responsive). It is *not* a field/ride tool. Don't optimize the web UI for gloves, bright sunlight, or glanceability.

## Who They Are

Adventure motorcycle riders, spanning a wide spectrum of experience:

- **New ADV riders** — just got the bike and the bags. Don't yet know what a balanced setup looks like.
- **Weekend ADV riders** — two or three days out; want a balanced load without overpacking. The primary audience.
- **Long-distance / touring riders** — multi-week trips; value reusing setups they ride more than once.
- **Dual-sport / off-road riders** — light bikes, tight panniers, real payload limits.
- **Expedition and group riders** — more complex loads and coordination; still not the design center.

Adjacent users (overlanders, backpackers) apply the same weight-and-balance thinking, but design for the **adventure motorcycle rider first**.

## Domain Expertise vs. Software Expertise

These two are not the same, and the gap between them drives most UX decisions:

- **High domain fluency.** Riders know their world. Use their vocabulary directly: panniers, tank bag, tail bag, ADV, payload, tare weight. Don't over-explain these or wrap them in tooltips.
- **Mixed software fluency.** They are not necessarily technical users. Assume no patience for software friction, jargon, or multi-step configuration. The interface must feel obvious without a manual.

The rule of thumb: **be sophisticated about gear, simple about software.**

## What They Care About

| They care about… | So the app should… |
| --- | --- |
| **Trusting the numbers.** | Show weights consistently, label any approximation explicitly, and never present a figure that could be silently wrong. |
| **Handling & safety.** | Make the live balance indicator the visual center of the planner; make imbalance impossible to miss. |
| **Not overpacking, not forgetting.** | Surface total load vs. payload clearly; make it easy to see what's packed where. |
| **Getting to value fast.** | Keep first-run setup short. Don't block the first balance view on optional data. |
| **Privacy, especially body weight.** | Treat body weight as sensitive: never displayed publicly, used only for the rider's own math. |
| **Reuse.** | Make saved kit feel first-class for returning users. |

## Complexity Tolerance & Progressive Disclosure

Riders can handle real **domain** complexity. They cannot handle **software** complexity dumped on them all at once. Progressive disclosure is the core UX principle:

- Lead with the minimum required; hide non-essential fields.
- Make optional steps genuinely skippable, and say what is lost by skipping.
- **Degrade gracefully.** A missing optional input should never break a screen.

## Tone & Terminology

Confident, plain, rider-to-rider — outdoorsy and technical without being corporate. Use domain terms freely. Reserve inline guidance for places where even an experienced rider is genuinely uncertain.

## Accessibility Expectations

Balance state and capacity warnings must communicate through **color, icon, and text — never color alone.** A safety-relevant signal can't depend on hue. This is a hard requirement.

## Who This Is *Not* For

- Not a generic packing checklist — the weight-and-balance intelligence is the point.
- Not a social network — the core value has to stand alone without social features.
- Not a field/on-trail tool — resist building ride-context affordances into the web app.
- Not for users who want zero setup — some kit entry is inherent to the value. Make that setup fast and forgiving, not absent.