​

Landing page section spec

This spec describes the section contract for apps/landing/src/app/page.tsx. The landing page should explain Clay as an opportunity platform built around intentions, personalities, consent, and action. It should not drift into a passive chatbot, resume parser, dating app, or generic marketplace.

​

On this page

• The five-step narrative arc
• The global design direction
• Section contracts for header, hero, problem, solution, experience, market, and footer
• The current known gaps
• Edit rules when changing the page

​

Narrative arc

​

Global design direction

Clay’s landing design should feel human, tactile, and decisive. Use the existing visual system: warm paper (cream), deep ink (almost-black), acid-lime for momentum and readiness, electric-purple for personality and opportunity paths, tomato-orange for human attention and expressive action, clay-pink for support and warmth, and warm-taupe for grounding and supportive context (see design language for canonical token names). Use the active theme accent for consent and safety, never color alone. Use the “plasticine” direction from the landing design system as a metaphor: personal context is moldable and living, while recommendations should feel crisp and useful. Avoid a page made only of repeated cards. Important sections should have distinct visual jobs. See Design language for the canonical token meanings, component behavior, and image-generation boundary.

​

Section contracts

​

Site header

Design ideas:

• Add visible focus states for links and CTA.
• Consider active-section state once the page has enough scroll depth to warrant it.
• Keep the mobile header simple, but make the primary action comfortably tappable.

Risk:

• The header still stays intentionally lightweight on mobile. If the page grows, consider a compact menu instead of adding more persistent chrome.

​

Hero

Meaning: The hero establishes the core argument: behavior is not enough. Clay should be framed as an intelligence layer that understands intention-level opportunity fit. Layer 1 is mascot-oriented: mascot profiles carry identity, presence, and handmade warmth, while labels and controls explain what can move next. Design ideas:

• Add a short supporting line if the hero needs more immediate clarity about “opportunity platform.”
• Use the mascot scene as the primary visual anchor. Keep UI chips and copy around it explicit so the mascot never carries consent, readiness, or fit meaning by itself.
• Keep the first viewport focused; do not crowd the thesis with implementation detail.

Risk:

• The hero depends on the mascot scene staying legible and not reading as a toy-first brand. If the asset changes, preserve equal mascot profile importance and explicit UI labels.

​

Problem

Meaning: This section contrasts activity-based systems with Clay’s intention-level model. It should make the reader feel the familiar failure: more options, weaker fit, repeated self-explanation, and suggestions that are technically relevant but personally wrong. Design ideas:

• Keep the platform cards as a comparison pattern: observed behavior versus missed intent.
• Use an editorial map or staggered layout if the five equal cards feel too generic.
• Keep the dark summary as the emotional landing point of the section.

Risk:

• Consent is introduced later in the page, so this section should stay focused on the failure of activity-based inference.

​

Solution

Meaning: This is the clearest explanation of Clay: it starts from intention, learns personality over time, and turns fit into action. It should make the product feel like a living context layer, not another search box. Design ideas:

• Treat the three cards as a fit pipeline: intention capture, personality learning, action.
• Make the signal chips feel like permissioned context tokens, not generic tags.
• Use the active theme accent deliberately where the design is communicating trust, consent, or safety, and pair it with explicit labels and reversible controls.

Risk:

• The consent panel is now visible, but it still summarizes policy rather than letting users exercise reversible controls. Product flows should handle the actual controls.

​

Experience

Meaning: The user should understand the emotional progression: curious, heard, understood, then confident. Clay asks timely questions, reflects the answer, builds memory, and suggests the next useful move when the context is strong enough. Design ideas:

• Progress bars may animate on entry, but they should feel directional rather than falsely quantitative.
• Keep code-native plasticine artifacts readable and verify contrast on desktop and mobile.
• Keep broad opportunity examples visible: community, local plans, self-understanding, projects, jobs, events, and collaborators.

Risk:

• Some examples are still lifestyle-led. Keep adding work, project, community, and partner examples as the product surface matures.

​

Business model and market

Meaning: This section should show that Clay’s opportunity is not one vertical. The business is the trusted context layer: users pay for deeper understanding and useful guidance, while partners pay for qualified moments that respect user permission. Design ideas:

• Keep the content grouped into lanes: user value, partner value, market proof.
• Give research links stronger link affordance and keyboard focus treatment.
• Preserve the permissioned handoff visualization: user gives permission, Clay translates context, partner improves the moment, Clay learns from the outcome.

Risk:

• This remains the longest section. If it feels heavy in rendered review, reduce the number of visible proof cards before adding new material.

​

Site footer

Design ideas:

• Keep the close simple.
• Make the CTA destination clearer if it remains external.
• Preserve separate CTAs for user interest, partner interest, and contact.

Risk:

• The external contact path is still founder-oriented, so keep the preceding CTAs Clay-specific.

​

Known gaps

​

Edit rules

• Keep Clay framed as an opportunity platform, not a chatbot or dating app.
• Keep public copy benefit-first and plain; technical stack details belong outside the landing hero.
• Preserve the arc: thesis, problem, solution, experience, market.
• When code behavior or section meaning changes, update this spec in the same change.
• Before claiming a visual iteration is done, verify desktop and mobile screenshots for text fit, contrast, artifact framing, and section rhythm.

​

Related