> ## Documentation Index
> Fetch the complete documentation index at: https://design.slingshotai.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> This site documents Sundial 2.0, the design system of the Ash mobile app (Flutter). For implementing UI: use the Design System pages — color/typography tokens (foundations/*), Flutter theming (theming/*), and component APIs (components/*) — as your reference; every value there mirrors the Dart source in lib/design_system/. The Philosophy pages (philosophy/*) are design rationale written for humans: consult them when making design decisions, not for API lookups. Golden rules: never hardcode colors or text styles — read tokens via context.colorTheme and context.textTheme; prefer the 2.0 semantic names (contentPrimary, surfaceComponent, accentSolid…) over legacy contrast*/surface* getters and over SundialRef primitives; the accent is a single pale lavender solid that takes dark content — never use accent fills as text, icons, or borders (use contentAccent / borderSelected); brand surfaces are mode-invariant and pair with the contentOnBrand* inks; check lib/design_system/components/ before building custom widgets.

# Design Philosophy

> Design rationale: the beliefs behind Sundial — essentialism, respect for the user, and earned expressiveness

> [!NOTE]
>
> **Who this section is for.** The Craft & Foundations pages explain *why* Ash looks and feels the way it does — the values and taste behind the [Design System](https://design.slingshotai.com/index.md). Humans: read this before designing anything new. Agents: for implementing UI, the Design System section (tokens, theming, components) is your reference; consult these pages when making *design decisions* — choosing layouts, adding elements, judging whether something belongs — not for API lookups.

## Core belief

People's time is precious. Your app has to earn the right to be on someone's phone. Every element on screen must justify its existence — not to the business, but to the person using it. If something is there to serve a metric rather than a human need, remove it.

This extends from **Self-Determination Theory**. Every design decision should support:

* **Autonomy** — Give users real choices and control. Never manipulate, trick, or funnel people into actions that serve the business at their expense. No dark patterns. Ever.
* **Competency** — Make users feel capable, not confused. Interfaces should be immediately legible. If someone has to “figure out” how to use a feature, the design has failed.
* **Relatedness** — The product should feel like it was made by someone who cares. Warmth, craft, and attention to detail communicate respect. Cold efficiency is not the goal.

## The tightrope: essentialism + humanity

The philosophy walks a deliberate line between two traditions.

**The essentialist side** — Dieter Rams, Victor Papanek, Don Norman. Solve the problem. Don't waste the user's time. Strip away everything that isn't serving a clear purpose. *Design for the Real World* is the foundational text.

**The human side** — Buck Design's narrative worldbuilding, Sekani Solomon's transition from motion graphics to product, Claudio Guglieri moving between 3D and software. Design should leave people with something memorable and meaningful — art, delight, personality. Flat and bland is not the same as minimal and focused.

How to navigate this in practice:

* **V0 releases prioritize structural soundness.** Get the UX right. Follow the design system. Use simple, proven patterns. A solid V0 should feel comfortable and correct even if it never gets a visual polish pass.
* **Expressive moments are earned, not sprinkled.** Don't add delight for its own sake. Identify the specific moments where personality, animation, or visual richness will meaningfully improve the experience — then invest deeply in those moments.
* **If forced to choose, choose function.** A sound UX with plain visuals is always preferable to a beautiful interface that confuses people.

## How to apply this

This is a permanent design context layer — it applies to every design task regardless of the specific PRD.

**1. Start from the design system**

Use existing components first — see [Quickstart](https://design.slingshotai.com/quickstart.md) and [Components](https://design.slingshotai.com/components/styled-card.md).

**2. Apply the essentialism test**

Does every element justify its existence to the user?

**3. Check typography and spacing**

These are the most common failure points — see [Typography](https://design.slingshotai.com/philosophy/craft/typography.md) and [Spacing & Layout](https://design.slingshotai.com/philosophy/craft/spacing-and-layout.md).

**4. Consider the emotional context**

Someone may be vulnerable when using Ash — see [Designing for Ash](https://design.slingshotai.com/philosophy/designing-for-ash.md).

**5. Add expressive elements only with purpose**

Decoration must serve a functional or emotional goal.

**6. When uncertain, choose simpler, warmer, more respectful**

Of two viable approaches, pick the one that respects the user's time most.

## Where to go next

> [card] [Process](https://design.slingshotai.com/philosophy/process.md)
>
> Reference-first design, building from parts, and spending your deepest thinking on unknown unknowns.

> [card] [Designing for Ash](https://design.slingshotai.com/philosophy/designing-for-ash.md)
>
> What designing for mental health demands of an interface.

> [card] [Craft rules](https://design.slingshotai.com/philosophy/craft/visual-hierarchy.md)
>
> Hierarchy, typography, spacing, color, depth — the concrete rules that make UI feel designed.

> [card] [Anti-patterns](https://design.slingshotai.com/philosophy/anti-patterns.md)
>
> The never-do-these list.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.