​
Components

Components should never compete with the mascot. Buttons stay simple, cards stay spacious, inputs stay quiet. The mascot carries the emotion; the UI carries the clarity. Product controls remain familiar and shadcn-inspired even when brand surfaces become expressive. This page is the live contract behind the component behaviors documented in the design language and the surfaces that implement them in apps/landing, apps/mobile, and future Clay surfaces.
Components are precision tools. Texture, mascot expression, and accent color are layered on top — they are not the structure of the interface itself.

​
On this page

  • Buttons (eight types and a state matrix)
  • Inputs, including permission controls
  • Cards — anatomy and the Card Purpose Rule
  • Dialogs for consent and irreversible actions
  • Navigation and the seven destinations
  • The sidebar as a workbench
  • Profile surfaces (not resumes)
  • Chat as a feeder for cards and drafts
  • The five-question dashboard
  • The feed as a stream of meaning

​
Buttons

Clay uses eight button types. Each one has a clear purpose, a color vocabulary, and a state matrix.

Primary

clay-ink background with clay-paper text, 8px radius, 12px 18px padding, and a clear hover lift. The default workhorse button for high-trust actions.

Momentum

acid-lime background with clay-ink text. Use only for action moments that move the user forward — readiness, discovery, and review-ready recommendations.

Editorial action

tomato-orange accent or background. Expressive story, community, profile, event, or campaign actions — never for serious consent moments.

Personality

electric-purple accent or chip. Reserved for rhythm, creative identity, and style signals.

Support

clay-pink accent. Warmth, empathy, friendship, and mascot-led encouragement.

Consent

Explicit label, visible state, reversible action, and never icon-only. Uses the active theme accent only when paired with text and a clear permission affordance.

Ghost

Transparent background, hairline border, and a visible hover tint. For secondary paths that must stay quiet.

Danger

Clear destructive color vocabulary with a text confirmation step before destructive sharing or memory deletion.

​
State matrix

Every button — regardless of type — must implement the full state matrix. Skipping a state weakens the product because users notice inconsistency long before they notice the missing affordance.
1

Default

Resting appearance with the type’s color, radius, padding, and typography.
2

Hover

Subtle lift or tint change. Compress slightly on press. Cards gently lift; buttons press inward.
3

Focus-visible

2px outline plus 2px offset using the active theme accent. Always visible when keyboard focus lands on the control.
4

Active

Pressed state. Buttons compress by 2-4px and reduce shadow intensity.
5

Disabled

Reduced opacity, muted label color, cursor: not-allowed, and no hover or focus ring animation.
6

Loading

Inline spinner with the same color weight as the label. The button stays the same width so the surrounding layout does not shift.
Never icon-only a consent, danger, or irreversible action button. The label is the permission.

​
Inputs

Inputs should feel calm and nonjudgmental. They collect private context, so the visual tone must stay quiet and the focus treatment must stay unmistakable.
  • Radius: 8px to match cards and dialogs.
  • Background: clay-panel or a lightly tinted neutral — never a saturated accent.
  • Border: clay-line at rest.
  • Focus ring: the active theme accent at 2px outline with 2px offset, identical to buttons so users learn one focus language.
  • Padding: 12px vertical and 14px horizontal for normal text fields.
  • Error copy: plain and helpful, never dramatic. Tell the user what to do next.
Permission controls — switches, consent toggles, share-scope selectors — need explicit copy, a visible state, and a stronger focus treatment than ordinary fields. Their focus ring may use the active theme accent, paired with text and a clear permission affordance so the user knows the control affects shareability.
ControlTreatment
Text input8px radius, 1px clay-line border, theme-accent focus ring.
TextareaSame as text input, min-height 96px, resizable only vertically.
SelectNative-feeling select with chevron icon and 8px radius.
SwitchPermission control. Show on/off labels, current state, and a stronger ring.
SliderTrack + thumb with the active theme accent. Always show the current value.
SearchCalm, no border at rest. Surface a clear focus state on interaction.
Permission toggleActive theme accent, visible label, reversible state, and a dedicated focus ring.

​
Cards

Cards represent discrete objects: people, projects, jobs, events, communities, signals, or drafts. They are the most repeated surface in Clay, so the anatomy must stay consistent.
  • Standard radius: 8px.
  • Padding: 24px inside the card.
  • Border: 1px solid clay-line for resting cards.
  • Shadow: shadow-card only when the card is actionable or elevated. Resting cards rely on the hairline border so they stay calm.

​
Anatomy

1

Header row

Icon or avatar on the left, title beside it, a fit or status chip on the right, and an optional bookmark or quick action.
2

Body

One clear reason — not a wall of text. The card should answer “why this fits” in a sentence or two.
3

Footer

The next action plus the consent or share state when the card touches private context. Never hide the share state inside the header chrome.
The Card Purpose Rule. If a card is not actionable, comparable, or state-bearing, it should probably be a row, list item, or plain section. Reserve cards for objects that need comparison or follow-up action.
Do not nest cards inside cards. Use dividers, spacing, and tinted regions inside a single card to group related content.

​
Dialogs

Dialogs are for decisions that need attention — especially consent, sharing, introductions, and irreversible changes. A dialog is a contract with the user; every field should make that contract obvious.
  • Title that names the decision in plain language.
  • One sentence of consequence immediately below the title.
  • Exact list of what will be shared, changed, or deleted.
  • Primary action on the right, secondary on the left.
  • Never hide consent details behind vague Continue copy. Say what happens.
If a dialog cannot name what will change in one sentence, it is hiding a consequence. Rewrite until the consequence fits.

​
Required affordances

Reversibility

Every destructive or sharing action must show how to undo it, or be explicit that it cannot be undone.

Scope

Show the exact data, person, or opportunity the action touches. Generic confirmations hide scope.

Reason

If Clay is suggesting the action, the dialog explains why. The user can accept or override.

Escape hatch

A clear secondary path that does not punish the user for not acting now.
Navigation should make the opportunity workflow obvious. The seven primary destinations are the backbone of the product surface.
1

Home

The dashboard. What is ready, what changed, what needs consent.
2

Intentions

The user’s active goals, constraints, timing, and readiness.
3

Signals

Personality, working rhythm, taste, and the patterns Clay has learned.
4

Opportunities

The opportunity taxonomy — people, teams, projects, jobs, events, communities, partners.
5

Network

Relationships, intros in flight, recent collaborators, and active conversations.
6

Drafts

Intros, fit briefs, application drafts, and follow-ups Clay has prepared.
7

Settings

Consent, sharing scope, quiet hours, memory review, and theme preferences.
Use simple icons. Active state uses an underline or a filled chip. Labels stay visible.
Icon-only navigation is allowed only when there is a tooltip on hover and a persistent selected label nearby. Never ship a navigation bar where the only signal of selection is a color change.
The sidebar is a workbench, not a decoration strip. It should orient the user and surface the controls that change decision quality.
  • Group items by workflow: Context, Opportunity, Coordination, Settings.
  • Show the current mode — Light, Editorial, or Private Plum — so the user always knows which atmosphere they are in.
  • Include a small consent status area when the current surface touches private context.
  • Collapse to icons on tablet only when labels remain accessible through tooltips and a persistent selected label.
The sidebar earns its width by carrying decision-changing information. If it only mirrors navigation, it is decoration. Replace it with a rail.

​
Profile

Profiles are not resumes. They are living fit summaries. The profile surface should make a viewer oriented in seconds and respectful of consent throughout.

​
Required regions

Identity

Name, role, project, community, or company. The smallest unit that says “who this person is right now.”

Intention

What they are trying to do now. Active goal, timing, and readiness.

Personality signals

Communication style, working rhythm, taste, and social energy. Translated into readable signals, not raw trait labels.

Fit explanation

Why this opportunity might work for both sides. One to three readable reasons.

Consent line

What the viewer is allowed to know, and what remains private. Always visible.
Profiles are the surface where the “fresh but serious” rule is most visible. Personality can be expressive; consent must be exact.

​
Chat

Chat collects and clarifies context. It should not dominate the product. Chat exists to feed the surfaces that actually move the user forward.
  • Use chat for reflection, clarification, drafting, and consent questions.
  • Convert long chat output into cards, drafts, checklists, or next actions.
  • Keep private reflections visually distinct from shareable summaries — different surfaces, different labels, different share defaults.
  • Mascot expression can appear in chat, but it must not clutter every message. Reserve expression for state changes and meaningful responses.
A chat reply that ends in a card or draft is more Clay than a chat reply that ends in another chat reply. The product contract is to convert reflection into action.

​
Dashboard

The dashboard should answer five questions, in this order. If a section does not answer one of them, it should not be on the dashboard.
1

What is ready?

High-confidence opportunities, draft-ready intros, and timing windows the user can act on now.
2

What changed?

New fit signals, shifts in readiness, communities or events that just opened, or replies the user owes.
3

What needs consent?

Permission gates, sharing decisions, memory updates, and review items.
4

Which opportunities deserve attention?

The medium-confidence queue — opportunities that need one more signal or one user decision.
5

What draft can Clay prepare?

Intro drafts, fit briefs, follow-ups, and applications Clay can write on the user’s behalf.
Use dashboard density carefully. A dashboard that is empty feels broken; a dashboard that is full feels oppressive. Aim for one strong signal per question.

​
Feed

The feed is a signal stream, not an infinite dopamine loop. It should help the user notice what matters, then step away.

​
Grouping

New fit

A new opportunity, person, project, or community that appears relevant to an active intention.

Timing changed

A window opened, a deadline moved, or a previous opportunity became relevant again.

Consent needed

A sharing decision, a memory update, or a permission gate that requires the user’s call.

Draft ready

An intro, application, fit brief, or follow-up Clay has prepared and the user can review.

Network signal

Someone the user knows joined, accepted, moved, or responded in a way that affects fit.

​
Required affordances

  • Show why an item appears — one line that names the visible signal behind the recommendation.
  • Let the user dismiss, tune, or mute the signal. Mute is per-category, never global-only.
  • Avoid endless scroll as the default product shape. The feed should reach a stop and let the user return later.
The feed is a stream of meaning, not a stream of activity. Empty feed is a feature when nothing has changed.

​
Acceptance Criteria

A Clay surface satisfies this contract when:
  1. Buttons follow the eight-type vocabulary and the full state matrix.
  2. Inputs feel calm, focused, and unmistakably accessible.
  3. Cards represent actionable or comparable objects, not arbitrary groupings.
  4. Dialogs name their consequence in one sentence and show scope, reversibility, and escape hatches.
  5. Navigation makes the seven destinations obvious with labels and accessible icon states.
  6. The sidebar carries decision-changing information and shows current mode plus consent status.
  7. Profiles show identity, intention, personality signals, fit explanation, and consent line.
  8. Chat collects context and converts it into cards, drafts, or next actions.
  9. Dashboards answer the five questions in order, one strong signal per question.
  10. The feed groups by meaning, explains why each item appears, and never defaults to endless scroll.

Design language

Tokens, shape language, and component behavior that ground every Clay surface.

Themes

Acid Lime, Editorial, and Dark Plum mood packs that change atmosphere without changing layout.

Mascot

The mascot system that carries emotion without competing with the components.

Motion

Pacing, easing, and stateful motion that keep components alive without slowing work.

Introduction

The product contract behind intentions, personalities, opportunity, consent, and action.

Mobile capture flow

The first Clay mobile workflow that uses these components on iOS.