# LAYR redesign proposal

5 September 2026 · Revision 2 · Chosen direction: Cloud Dancer + Quiet Violet · Apple HIG governs platform behavior

**Chosen direction:** Cloud Dancer, Quiet Violet, and Obsidian. Use Pantone’s 2026 palette as the brand reference and Apple’s Human Interface Guidelines as the authority for platform behavior, navigation, controls, accessibility, and materials. The intended feeling is a soft, refined fashion editorial experience with familiar iOS interaction.

The user has selected Cloud Dancer + Quiet Violet and explicitly requested Apple HIG alignment. This supersedes the earlier Oxblood recommendation. Detailed digital tokens and navigation changes below remain proposed implementation specifications. This document and its companion [interactive visual board](index.html) are planning artifacts; they do not change the app or supersede the current canonical design contract yet. Screen content on the board is illustrative.

**1. What the redesign needs to fix**

The existing system has valuable foundations: Bricolage Grotesque, the actual LAYR wordmark, Obsidian primary actions, garment cutouts, Hugeicons, and a central ComponentsKit facade. Keep these assets and architecture while improving their use.

The code audit found five high-impact problems:

- **The accent has a usability problem as well as a style problem.** Denim measures 3.94:1 against white. White small text on Denim and Denim small text on white fall below a 4.5:1 target. The 58% Obsidian metadata token also measures only 3.77:1 on white.
- **The closet is harder to find than it should be.** Production navigation is Home / Search / You, with Create as an action. Search searches only the closet; the actual wardrobe and saved looks live inside You. An empty search can present an upgrade banner before useful content.
- **The UI has competing visual languages.** Source and historical captures show a combination of large display headings, 3D chrome, gray and blue image wells, pill rows, cards, glass treatments, and prominent upgrade/progress banners. An editorial system should give garment imagery priority and reduce the number of elements competing with it.
- **Tokens do not always describe the rendered component.** PrimaryCTA requests an outer 56pt frame, but the underlying large button is 52pt with a 14pt label. Selection treatments and corner rules vary. Fixed font sizes do not provide a complete Dynamic Type policy.
- **Layouts are solved repeatedly within screens.** Large fixed artwork sizes, local bottom-clearance additions, duplicate controls, and a non-scrolling item-detail composition make compact screens and large text harder to support.

This is a source audit with selected historical screenshot review, not a fresh end-to-end visual certification. Before implementation, capture the current build using known fixture routes. Existing screenshot filenames and the August UX handoff do not reliably describe today's routes.

**2. Pantone direction and accessible color roles**

Pantone identifies its 2026 Color of the Year as **PANTONE 11-4201 Cloud Dancer**. Its “Light & Shadow” palette includes **PANTONE 16-3610 Quiet Violet** and **PANTONE 17-5800 Hematite**. “Powdered Pastels” includes **PANTONE 13-6006 Almost Aqua**. The user selected Cloud Dancer + Quiet Violet; retain Obsidian as LAYR’s contrasting brand anchor. [Pantone’s 2026 reference](https://www.pantone.com/na/en-us/color-of-the-year/2026)

Use the three **brand families** consistently, with semantic tonal variants. This is not a limit of three literal rendered RGB values. System colors, real clothing colors, official brand marks, and native destructive/status treatments are outside the brand-palette count. Do not recolor iOS’s destructive controls or permission interfaces to fit a marketing palette. [Apple Color](https://developer.apple.com/design/human-interface-guidelines/color), [Apple Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons)

| Brand reference | Provisional screen value | Role |
|---|---|---|
| **Cloud Dancer · 11-4201** | **`#F0EEE9`** | Soft light canvas and inverse text |
| **Obsidian · retained LAYR color** | **`#2A2A2A`** | Primary light-mode text/actions and dark-mode canvas |
| **Quiet Violet · 16-3610** | **`#A693AC`** | Soft editorial accents, selected surfaces, brand details |

Pantone names and identifiers come from the reference page. These RGB values are **provisional screen interpretations**, not asserted official Pantone conversions. Confirm the intended Pantone digital reference before treating them as final brand specifications. All darker/lighter functional variants below are LAYR-created accessibility adaptations, not additional named Pantone colors.

The soft violet swatch has only **2.45:1** contrast against the proposed Cloud Dancer canvas. It must not be used for ordinary small text or the sole required selection indicator. Use dark Violet Ink `#66516F` for those roles in light appearance: it measures **6.10:1** against Cloud Dancer. Obsidian on Cloud Dancer measures **12.38:1**. These figures are calculated from opaque sRGB pairs using WCAG relative luminance and rounded for display; they do not certify the whole interface.

**Proposed semantic mapping**

| Role | Light preview | Dark preview | Native app rule |
|---|---|---|---|
| `canvas` | Cloud Dancer `#F0EEE9` | Obsidian `#2A2A2A` | Semantic adaptive background; system sheets retain native materials |
| `textPrimary` | Obsidian `#2A2A2A` | Cloud Dancer `#F0EEE9` | High contrast reading text |
| `textSecondary` | `#625D66` | `#CAC4CD` | Supporting copy; validate against every containing surface |
| `actionPrimary` / label | Obsidian / Cloud Dancer | Cloud Dancer / Obsidian | Primary content action; native toolbar styles stay system-owned |
| `brandAccent` | Quiet Violet interpretation `#A693AC` | Same reference family | Soft brand treatment, never assumed accessible foreground |
| `accentForeground` | Violet Ink `#66516F` | Light Violet Ink `#D1B9DC` | Text/checks/essential indicators; 6.10:1 / 7.99:1 on respective canvases |
| `accentSurface` | Soft Quiet Violet/Cloud Dancer blend | Restrained Violet/Obsidian blend | Selected row background; always paired with explicit check and contrasting label |
| `controlBoundary` | `#79737D` when a custom outline is essential | A sufficiently light neutral variant | Validate required boundaries at 3:1; do not override standard input styling globally |
| `surface`, `surfaceInset`, `separator` | Named neutral tone variants | Named neutral tone variants | Distinguish content levels; decorative separators may be softer than essential boundaries |
| `statusError`, `actionDestructive` | Native semantic role | Native semantic role | Familiar system rendering, explicit label/icon and recovery; not violet by default |

Resolve custom content colors as explicit opaque values per appearance so app code, preview, and exported tokens agree. Define separate Increased Contrast variants where needed. Native system colors and materials remain dynamic; do not flatten them into screenshot samples.

Inline colored links also need an underline or other non-color affordance. A checkmark and label must communicate selection in grayscale. True garment and personal color-analysis swatches remain unchanged, with accessible text equivalents.

The comparison board retains **Almost Aqua** and **Hematite** as alternatives only. Their provisional screen swatches are `#CAD3C1` and `#756F6B`; their darker light-appearance functional inks are `#4D6346` and `#625C58` (both approximately 5.68:1 on Cloud Dancer). The chosen app palette uses Quiet Violet, not a combination of all three alternatives.

**Apple HIG is the platform contract**

Apply [the detailed HIG checklist](APPLE-HIG.md) to every component and screen family. Native tabs, navigation bars, toolbars, sheets, alerts, menus, text fields, switches, and pickers retain platform behavior and geometry. The Pantone identity lives primarily in content, imagery presentation, and semantic accent roles. LAYR’s proposed 20pt gutters, 14pt content-card corners, 4pt spacing scale, and 56pt custom CTA are design choices, **not Apple-mandated constants**.

**3. Typography and voice**

Keep Bricolage Grotesque Bold/ExtraBold for the brand voice and San Francisco for reading and interaction. Retain the actual wordmark asset. Remove the one-off handwritten onboarding annotation in this direction, leaving two typefaces.

| Semantic role | Default size / suggested line height | Face and weight |
|---|---|---|
| `displayHero` | 48 / 52pt; compact variant 40 / 44 | Bricolage ExtraBold; welcome or major editorial moment only |
| `pageTitle` | 32 / 36pt | Bricolage Bold |
| `featureTitle` | 28 / 32pt | Bricolage Bold |
| `sectionTitle` | 24 / 29pt | SF semibold |
| `rowTitle` | 17 / 22pt | SF semibold |
| `body` | 17 / 24pt | SF regular |
| `bodySmall` | 15 / 21pt | SF regular |
| `controlLabel` | 17 / 22pt | SF semibold |
| `compactLabel` | 15 / 20pt | SF medium |
| `metadata` | 13 / 18pt | SF regular/medium |
| `metric` | 32 / 36pt | Bricolage Bold; paired with a clear unit and explanation |

These are LAYR base-size targets, not fixed text boxes or Apple-prescribed sizes. Use semantic system text styles for native chrome, reading, and controls. Implement Dynamic Type and Bold Text behavior across SwiftUI and ComponentsKit/UIKit; custom Bricolage headings scale with their semantic role. Grow controls and rows as text grows. At accessibility sizes, stack side-by-side actions and replace dense grids with accessible rows. Preserve all meaningful content; do not shrink text to force it into a fixed frame. Avoid tight negative line spacing, synthetic weights on Bricolage, all-caps paragraphs, and oversized titles on routine utility screens.

Copy should be specific and conversational: “Add clothes,” “Wear this,” “Save look,” “Review 2 items,” “Try again.” Reserve brand language for a few editorial moments. Explain AI processing, photo use, subscriptions, and failures accurately using the implemented behavior.

**4. Layout, padding, and sizing**

For custom content layout, use a 4pt spacing scale: **4, 8, 12, 16, 20, 24, 32, 48, 64**. Values express relationships; a section gap and an inner-card gap should not share a token merely because they happened to be equal previously.

| Layout rule | Proposed value |
|---|---|
| Phone page gutter | 20pt default; 16pt at widths ≤375pt; 24pt at widths ≥430pt |
| Major section gap | 32pt |
| Header to first content | 24pt |
| Title to supporting copy | 8pt |
| Supporting copy to controls/media | 20–24pt, through a shared pattern |
| Related row/item gap | 8–12pt |
| Card padding | 16pt compact; 20pt standard; 24pt for spacious introduction surfaces |
| Grid gutter | 12pt |
| Label to input | 8pt |
| Field group gap | 20pt |
| Bottom action area | Page gutter horizontally; 12pt above controls; 12pt plus actual bottom safe area below |
| Icon artwork | 20/24pt by role; 16pt for trailing/supporting icons |
| Minimum interactive target | 44 × 44pt; visible glyph/chip may be smaller |

These are initial content-layout metrics. Native navigation bars and controls keep system margins. Respect safe areas, the keyboard, layout direction, and supported orientations. Align custom page titles, section labels, media, and footers to the same gutter. Make image height respond to aspect ratio and available space. Use one scroll owner for ordinary pages. Every sticky action reserves its actual space in the content; remove screen-local guesses such as extra 88/120pt bottom padding.

Define seven shared layouts: **content page, searchable library, detail page, form, capture flow, canvas editor, and onboarding step**. Each owns header behavior, scroll behavior, safe areas, loading placement, and footer composition. The canvas editor may have independent scrolling in its item picker, with explicit ownership.

For the wardrobe, use 2-column garment and saved-look grids at normal text sizes, with a list alternative for accessibility text. This trades some density for more legible garment imagery and names; removing the large profile block gives the wardrobe more room. Garments use neutral 1:1 stages with `contain`-style fitting and optical size balancing. Outfit/model photographs generally use 3:4 stages with an explicit crop policy; full-body instructional imagery must preserve the whole person.

**5. Shape, components, and interaction states**

Use native control shapes by default. For LAYR custom content components, retain **14pt card/media corners** and a **pill primary CTA** where appropriate. Do not force this geometry onto native inputs, sheets, toolbars, alerts, or pickers. A tappable garment tile or multiline selection row can have a rectangular content shape. The current inner 52pt versus outer 56pt CTA mismatch is a consistency defect, not evidence that a 52pt button violates Apple HIG.

| Component | Proposed contract |
|---|---|
| Primary content action | Adaptive Obsidian/Cloud Dancer pairing, 17pt base label, pill; minimum actual rendered height 56pt for the custom facade; native button styles retain system metrics; one dominant action per screen/task |
| Secondary action | Outlined pill; minimum 48pt; match 56pt when alongside the primary |
| Tertiary action | Plain or underlined label as appropriate; minimum 44pt target |
| Icon action | 44pt target; 20/24pt glyph; explicit accessible label |
| Filter chip | Pill, 36pt visual minimum, 44pt target; selected check/weight plus accent treatment; targets must not overlap |
| Single/multiple choice row | 14pt radius, minimum 64pt, 16pt inner padding; selected accent outline, subtle wash, explicit check; grow with copy |
| Text input/search | Prefer native text fields/search. Preserve focus, text editing, keyboard, dictation, clear/cancel and validation behaviors. A custom content field can target 52pt and 16pt insets; do not impose its radius on system fields |
| Multiline input | Native text editing inside a branded content container where appropriate; grows with content; maintain access to submit when the keyboard is visible |
| List/disclosure row | Minimum 56pt, full-row target, shared leading/trailing slots and divider alignment |
| Card/media tile | 14pt radius, no custom shadow; border only when separation is useful; avoid enclosing every section in a card |
| Progress | 4pt linear track for measured progress; indeterminate indicator when completion is unknown; text announces the actual stage |
| Badge | Noninteractive label with icon where meaningful; never mistake a passive badge for a chip |
| Sheet/dialog | Native sheets and alerts, platform geometry, appropriate detents and dismissal; shared content spacing, scrolling, and keyboard-safe actions; confirm only when the action warrants it |
| Switch/picker | Native interaction semantics, approved theme treatment, visible label and state; no custom gesture-only replacement |
| Feedback banner | Stable inline placement; icon, concise explanation, specific action; announce significant changes accessibly |

Every interactive component needs **default, pressed, focused, disabled, loading, and relevant selected/error states**. Press feedback should be subtle; loading preserves geometry and prevents duplicate submission. Disabled actions explain unmet requirements where necessary. Selection state must remain clear in grayscale.

Motion tokens: roughly 120ms for press feedback, 180–220ms for selection, and 250–320ms for contextual transitions. Use these as prototype starting points, not arbitrary delays. Follow the system for navigation and keyboard transitions. Reduce Motion replaces large movement with immediate updates or subtle fades. Avoid perpetual floating decorations and fake processing percentages.

**6. Appearance, native materials, icons, and imagery**

Recommend following the user’s **system Light/Dark appearance** for the full redesign, with light and dark prototypes in the board. This expands the earlier light-first scope. It is a product recommendation, not a claim that Apple forbids every light-only app. Apple explicitly asks for adaptable custom color definitions even in a single-appearance app because Liquid Glass can adapt locally. Include Increased Contrast color variants and test text over actual materials. [Apple Color](https://developer.apple.com/design/human-interface-guidelines/color)

Use standard iOS navigation/control surfaces so they adopt **Liquid Glass where supported**, with native behavior on older supported systems. Keep glass in the navigation/control layer and ordinary content surfaces calm. Avoid hand-built glass imitations, decorative content gradients, and additional shadows behind clothing cards. System materials retain their accessibility adaptations, including Reduce Transparency. A web concept can demonstrate hierarchy and color; it cannot verify native material rendering. [Apple Materials](https://developer.apple.com/design/human-interface-guidelines/materials)

Prefer **SF Symbols** for familiar system actions and navigation. Custom fashion icons remain valid when visually consistent, scalable, and labeled. Review the Hugeicons facade case by case rather than mechanically deleting or mixing icon sets. Keep official brand marks. Limit 3D Thiings imagery to intentional education or empty states so garment imagery leads. SF Symbols adoption and the refined illustration policy deliberately revise the current icon contract. [Apple Icons](https://developer.apple.com/design/human-interface-guidelines/icons)

Standardize cutout cleanup, fit/crop behavior, loading placeholders, failed images, and outfit composition in both appearances. Test white garments, black garments, patterns, irregular accessories, and full-body photos. Preserve the garment pixels; change their surrounding stage for visibility. Removing Denim as a UI pigment must not recolor real denim clothing.

**7. Navigation and screen-by-screen redesign**

Recommended navigation: **three native destination tabs — Home / Closet / You**. Put **Create in a trailing toolbar button/menu**, not a fourth tab or tab-shaped modal trigger. Preserve each tab’s navigation/scroll state and native Back/Close semantics. [Apple Tab bars](https://developer.apple.com/design/human-interface-guidelines/tab-bars), [Apple Toolbars](https://developer.apple.com/design/human-interface-guidelines/toolbars)

Home answers “What can I wear?” Closet answers “What do I own?” You contains personal settings and preferences. Search becomes a persistent Closet capability; preserve search matching and make item taps consistently open details, with an explicit “Style this” action.

| Screen family | Proposed layout and behavior |
|---|---|
| Home | Quiet wordmark/header; one compact date/weather context; one featured look; a clear Wear/Plan action appropriate to the selected date; secondary save/edit; Ask LAYR and more looks below. Make wardrobe-completion prompts dismissible/in-flow so they do not obscure outfit actions. |
| Closet and saved looks | Title and Add action; search; Items/Looks switch; compact filters/sort; image-first grid. Move the large profile block to You. Preserve selection, bulk actions, empty/no-result states, and import access. |
| Item detail | Scrollable image-led detail; concise metadata; primary “Style this”; edit/share secondary; delete in overflow with a clear confirmation/recovery policy. Remove duplicate action rows. |
| Outfit detail | Shared image stage, optional garment/avatar view, pieces list, and Save/Wear/Plan context. Keep try-on, edit, and share discoverable with a stable hierarchy. |
| Create Look | Generous adaptive canvas, clear selected-item state, expandable wardrobe picker, one save control; compact-height mode lets the picker expand/collapse without hiding Save or obscuring the canvas. |
| Create menu | Preserve Add clothes, Create look, Outfit Check, Color Analysis, and Item Finder. Use consistent labels/icons and short descriptions where needed. Create opens from a toolbar/menu action, never a fourth tab. |
| Camera/photos/import | One sequence: choose source → capture/select → process → saved/needs review/retry. Keep batch status and queued work visible after dismissal. Design permission-denied, partial failure, offline, and cancellation explicitly. |
| Import Inbox, website/email handoffs | Shared review card, source context, clear save/skip/retry decisions, and one place to find work needing attention. Preserve existing entry routes and feature gates. |
| Calendar and Style Journey | Distinguish selected, planned, worn, and today with shapes/labels as well as color. Show the selected day's details below the grid. Keep charts restrained, labeled, and backed by an accessible text summary. |
| Outfit Check, Color Analysis, Item Finder | Shared introduction/upload/processing/result/retry framework; tool-specific result presentation. Photos and color-analysis results keep real content colors. Avoid a separate visual language for each AI feature. |
| AI Chat | Calm transcript, clear role separation, accessible composer, explicit pending/failed response behavior, readable product/wardrobe suggestions; consistent actions with the rest of the app. |
| Avatar and try-on | Shared photo collection instructions, preview/review, readiness, generation, failure/retry, and results. Keep photo requirements understandable and footer actions keyboard/safe-area aware. |
| You/settings | Compact identity header; account, style preferences, membership/credits, notifications, imports, support, privacy/data. Label read-only style information truthfully until editing is implemented. |
| Paywall/authentication | Match first-party spacing and typography within supported hosted UI controls. Preserve visible pricing/terms, restore, dismissal, purchase recovery, provider identity, and return to the requested task. Audit remote paywall configuration separately from local theme changes. |
| Launch/onboarding | One scaffold, consistent progress, left-aligned questions, aligned choices and bottom action. Replace oversized centered marketing sequences with concise editorial composition. |

The active onboarding plan currently has **39 entries**, including marketing, processing, purchase, sign-in, and avatar steps. This does not mean every person manually completes 39 questions. First migrate all reachable steps to the new scaffold. Separately prototype a shorter path centered on style intent → a few references → first clothes → first useful look, with optional assessments/avatar setup introduced at relevant moments. Defer acquisition/habit surveys where possible. Any change to required data, consent, entitlement, authentication, or paywall sequencing must be reviewed as a product-flow change and evaluated against completion and first-value metrics.

Scope exclusions: the preview-only Studio tab and its Style Training, Glow Up, Mix & Match, and AI Outfit routes are not production navigation. Whole-library face-matching scan is disabled. Do not turn these on as a side effect of redesigning screens. If they return later, they must adopt the shared patterns.

**8. Code and design-system migration**

Retain `LAYRComponentsKit` as the branded component facade, using the customized ComponentsKit layer where it supports the required behavior. Prefer native platform components for system chrome and standard interactions. Extend the facade or wrap the native implementation when necessary; do not distort native behavior solely to route every control through a third-party widget. Organize the system as **primitives → semantic roles → component specifications → screen patterns**. Keep unique artwork geometry in feature-pattern definitions; move business constants out of visual foundation tokens.

1. Record the selected direction and update `DESIGN.md` and `AGENTS.md` together to replace Denim with Cloud Dancer/Quiet Violet branding; define native semantic-color exceptions; clarify native versus custom geometry, typography, adaptive appearance, materials, and icon use. The old rules remain canonical until this deliberate update.
2. Introduce semantic accent and surface aliases. Migrate direct `denim`, `sage`, `denimDark`, and `keyboardTan` usages by purpose; temporarily deprecate old aliases if needed. Avoid blindly renaming clothing assets or content color labels.
3. Correct actual button sizing, typography, hit areas, scaling, and state behavior inside the shared component path. Use documented extension points; inspect vendor instructions before any necessary local ComponentsKit changes.
4. Add reusable chips, choice rows, icon actions, disclosure rows, media stages, feedback states, and page scaffolds through the canonical layer. Specialized canvas/camera controls may remain specialized, with explicit contracts.
5. Migrate one complete vertical journey and verify it before broad propagation. Extract screen families from the large `TodayView.swift` composition as needed to keep responsibilities clear.
6. Update the design-system exporter, JSON, preview, and Figma-import recipes together. Remove stale Inter substitutions and outgoing palette assumptions; generated artifacts should match source tokens. Update the UX handoff to match real production navigation.
7. Remove redundant raw component implementations, obsolete aliases, and conflicting documentation once all consumers migrate. Do not remove unrelated work or inactive features merely because a redesign is underway.

**9. Delivery plan and review gates**

| Phase | Deliverable | Exit condition |
|---|---|---|
| 1 — Direction and baseline | Current route/capture inventory; chosen Pantone direction; Home, Closet, onboarding concepts in light/dark; native navigation decisions | A selected direction and concrete reference screens; current behavior and scope documented |
| 2 — Foundations and component kit | Updated canonical rules plus HIG checklist; adaptive color/type/layout tokens; native and branded component/state specimen | Actual dimensions, contrast, hit areas, and text scaling verified in the rendered kit |
| 3 — Core wardrobe journey | Home → Closet → item → Create Look → save/wear; shared navigation and page patterns | End-to-end fixture journey works at compact and large sizes; primary actions remain visible |
| 4 — Capture and tools | Camera/photos/import recovery, calendar, chat, assessments, avatar/try-on | Shared states behave consistently; dismissal/offline/pending work does not lose context |
| 5 — Onboarding and account | All active onboarding entries, authentication/paywall integration, You/settings/privacy/notifications | Purchase recovery, permissions, account flows, and every reachable onboarding step verified |
| 6 — System completion | Exported design library, refreshed handoff, visual/functional/accessibility review | No unresolved critical flow or accessibility regressions; screenshots and known limitations recorded |

Design can proceed one screen family ahead of implementation. Phase reviews should compare real screens and behavior, not approve isolated color swatches. Estimate calendar time after the component and route inventory is locked; a color swap alone is not a useful estimate for this scope.

**10. Validation and success criteria**

For every migrated family, build and capture supported compact and large iPhone configurations. Include a short-height device where supported, widths around 375/390/402/430/440pt as applicable, the lowest supported iOS version, and the current iOS appearance. Check Light/Dark and Increased Contrast appearances, default text and largest accessibility sizes, VoiceOver, Bold Text, Reduce Motion, Reduce Transparency, keyboard presentation, and long/localized content. Verify native navigation/material behavior on iOS 17 and the current supported OS rather than treating the HTML board as evidence of native compliance.

Verify 4.5:1 for ordinary text and 3:1 for meaningful non-text state indicators where applicable. Decorative dividers do not have to be as strong as essential input boundaries. Check actual filled/tinted/pressed states, not only hex swatches. Ensure 44pt targets without overlapping neighbors, logical reading order, announced errors/loading, and no clipped or inaccessible bottom actions.

Exercise empty, populated, no search results, loading, success, partial success, error/retry, offline queue, denied permission, needs review, free/Pro, exhausted credits, cancelled purchase, and destructive-action recovery wherever relevant. Keep existing functional tests, add targeted component contract checks for the sizing/scaling defects, and use focused screenshot checks rather than blanket brittle snapshots of every pixel.

Visual acceptance: garments lead the page; the main action is identifiable quickly; title/media/action alignment is consistent; the accent has a clear role; no content is hidden by overlays; no new local color/spacing/component system appears. Track onboarding completion, time to first saved garment, time to first useful outfit, save/wear completion, import recovery, and return use against a measured baseline. Do not promise numeric improvement before observing users.

**Decisions now recorded:** Cloud Dancer + Quiet Violet is selected; Obsidian provides contrast; Apple HIG governs platform behavior. The prior Oxblood recommendation is superseded. The next review should focus on the exact digital palette, native three-tab navigation with toolbar Create, and system-following appearance. Shortening onboarding remains a separate flow decision; update its visuals within this redesign while preserving current gates until that decision is made.

**Audit references**

- [Current design contract](../../../DESIGN.md), [design tokens](../../../ios/LAYR/DesignSystem/LAYRDesign.swift), [component facade/theme](../../../ios/LAYR/DesignSystem/LAYRComponentsKit.swift).
- [Production shell, libraries, search, settings](../../../ios/LAYR/Views/TodayView.swift), [Home and outfit details](../../../ios/LAYR/Views/HomeFeedScreen.swift), [Create Look](../../../ios/LAYR/Views/CreateLookScreen.swift).
- [Active onboarding plan](../../../ios/LAYR/Models/OnboardingCoordinator.swift), [feature availability](../../../ios/LAYR/Services/AppConfiguration.swift), [route/debug harnesses](../../../ios/LAYR/RootView.swift).
- Contrast targets and interpretation: [W3C text contrast](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) and [W3C non-text contrast](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html). Platform design references: [Apple accessibility](https://developer.apple.com/design/human-interface-guidelines/accessibility) and [Apple typography](https://developer.apple.com/design/human-interface-guidelines/typography).

- Governing platform reference: [Apple Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines); detailed application and review gates: [APPLE-HIG.md](APPLE-HIG.md).