UPDATE — iOS 27-inspired Liquid Glass + pill control geometryLegacy format
iOS 27-inspired Liquid Glass + pill control geometry for a calm, intelligent personal workspace UI
Color Palette
Typography
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Every letter tells a story worth reading, and every typeface gives that story a new voice waiting to be heard.
Spacing
Base: 4pxiOS 27-inspired Liquid Glass + pill control geometry for a calm, intelligent personal workspace UI
Components
Buttons
Cards
Card Title
Sample body text for the card component.
Card Title
Sample body text for the card component.
Inputs
Chips
Elevation & Depth
Do's & Don'ts
Do
Don't
- Keep screens predominantly white and neutral.
- Use Outfit consistently.
- Apply blue accents with intention.
- Preserve generous whitespace.
- Use consistent radii and spacing.
- Prefer subtle surface contrast over heavy borders.
- Make active navigation clear with icon and label.
- Keep AI visuals distinctive but restrained.
- Reuse shared components and design tokens.
- Overuse blue gradients.
- Add shadows to every element.
- Apply glass effects to every card.
- Use excessive decorative patterns.
- Mix illustration styles.
- Crowd screens with information.
- Use multiple competing accent colors.
- Introduce arbitrary one-off radii, spacing, or typography values.
- Redesign unrelated parts of a screen during a focused change.
1. Button and input geometry: height ÷ 2
Every standard button and every single-line text input must use a pill radius equal to half its rendered height. Buttons and text inputs must use the same radius value when they share the same height.
Use CSS rather than hardcoded guesses:
```css
.button,
.text-input {
border-radius: calc(var(--control-height) / 2);
}
```
Set a shared control height so the button and input geometry remains consistent:
```css
:root {
--control-height: 52px;
--control-radius: calc(var(--control-height) / 2); / 26px /
}
.button,
.text-input,
.search-input {
min-height: var(--control-height);
border-radius: var(--control-radius);
}
```
If a control intentionally uses a different height, calculate its radius as half of its actual rendered height. Do not stretch or distort a control merely to force a fixed radius.
### Required geometry
| Component | Height | Border radius |
|---|---:|---:|
| Standard button | 52 px | 26 px |
| Standard text input | 52 px | 26 px |
| Search input | 52 px | 26 px |
| AI command input | 52 px minimum | 26 px minimum; expand naturally for multiline |
| Compact button | 44 px | 22 px |
| Large button | 56 px | 28 px |
| Icon-only circular button | 44 × 44 px | 50% |
| Chip | 32 px | 16 px or full pill (999px) |
| Standard card | — | 24 px |
| Feature card | — | 28 px |
| Floating navigation shell | — | 999 px |
| Active navigation capsule | — | 999 px |
For multiline text areas, retain the same top-level control radius as the standard input where practical, but allow the component to grow vertically without clipping text. The height / 2 rule applies to fixed-height controls; a multiline field may use a stable rounded-rectangle radius of 26 px.
Do not use the old 18 px button radius or 20 px input radius for standard 52 px controls.
2. iOS 27-inspired visual language
Interpret “iOS 27 style” as a forward-looking, native-feeling Liquid Glass interface: translucent material, layered depth, soft reflections, fluid pill controls, and clear content hierarchy. This is a design direction, not a claim to reproduce Apple's proprietary implementation.
### Liquid Glass material
Use glass effects selectively on:
• Primary floating controls and action buttons.
• Secondary and outlined buttons.
• Filter chips and selected chips.
• Floating bottom navigation and its active capsule.
• Floating assistant controls.
• Search and command surfaces when they sit over a gradient or image.
Material characteristics:
• Translucent white or pale-blue fill.
• Background blur around 16–24 px where supported.
• Saturation around 140–180%.
• Fine white highlight edge.
• Very subtle inner top highlight.
• Soft ambient shadow rather than a hard drop shadow.
• Text and icons must remain high contrast.
• Use a solid or near-solid fallback when blur is unsupported.
### Glass should respond to context
• On blue gradient surfaces: use a translucent white glass layer with white highlights.
• On white surfaces: use a very light cool-gray/white material with a visible but subtle edge so the control does not disappear.
• On dark surfaces: use a translucent dark material with a restrained light edge.
• Do not apply strong blur to every content card. Keep cards primarily solid white for legibility.
### iOS-inspired interaction behavior
• Buttons should have a quick, subtle press response (approximately 0.98 scale).
• Glass controls may brighten slightly on press.
• Selected chips should gain a soft blue tint and a clear selected indicator.
• Navigation selection should transition smoothly between capsules.
• Sheets and floating controls should feel layered above the content.
• Respect reduced-motion preferences.
• Never sacrifice readability or touch-target size for visual effects.
3. Reference CSS for shared controls
```css
:root {
--control-height: 52px;
--control-radius: calc(var(--control-height) / 2);
--glass-white: rgba(255, 255, 255, 0.68);
--glass-border: rgba(255, 255, 255, 0.78);
--glass-shadow: 0 6px 20px rgba(30, 65, 105, 0.09);
--glass-highlight: inset 0 1px 0 rgba(255, 255, 255, 0.85);
}
.button,
.text-input,
.search-input {
box-sizing: border-box;
min-height: var(--control-height);
border-radius: var(--control-radius);
font-family: "Outfit", sans-serif;
}
.button {
display: inline-flex;
align-items: center;
justify-content: center;
gap: 8px;
padding: 0 22px;
border: 1px solid transparent;
font-size: 15px;
font-weight: 500;
line-height: 1;
transition:
transform 160ms ease,
background-color 160ms ease,
box-shadow 160ms ease,
border-color 160ms ease;
-webkit-tap-highlight-color: transparent;
}
.button:active {
transform: scale(0.98);
}
.button--primary {
color: #fff;
background: #438BEF;
box-shadow: 0 5px 16px rgba(67, 139, 239, 0.20);
}
.button--glass {
color: #111318;
background: var(--glass-white);
border-color: var(--glass-border);
backdrop-filter: blur(20px) saturate(160%);
-webkit-backdrop-filter: blur(20px) saturate(160%);
box-shadow: var(--glass-shadow), var(--glass-highlight);
}
.text-input,
.search-input {
width: 100%;
padding: 0 18px;
border: 1px solid rgba(128, 128, 129, 0.22);
background: rgba(255, 255, 255, 0.82);
color: #111318;
font-size: 16px;
font-weight: 400;
outline: none;
}
.text-input:focus,
.search-input:focus {
border-color: rgba(67, 139, 239, 0.75);
box-shadow: 0 0 0 3px rgba(67, 139, 239, 0.12);
}
```
If the project uses Tailwind, React Native, Flutter, or another styling system, translate the same tokens and behavior into that system rather than introducing a second styling architecture.
4. Final visual checks
• [ ] Standard buttons are 52 px high with 26 px radius.
• [ ] Standard text and search inputs are 52 px high with the exact same 26 px radius.
• [ ] Compact and large controls calculate radius from their own height.
• [ ] No standard button or input has a square or 18/20 px corner treatment.
• [ ] Glass materials are translucent, softly blurred, and legible.
• [ ] Cards remain solid, spacious, and padded—not glassy by default.
• [ ] Brand accents remain blue, white, black, and cool neutrals.
• [ ] No decorative purple, lavender, mustard, gold, or olive is introduced.
• [ ] The interface feels fluid and native-inspired without sacrificing clarity.
---
# IMPORTANT — Visual fidelity override (read this first)
This section is the highest-priority visual specification for the project. It corrects inconsistencies in earlier previews and supersedes any conflicting component values later in this document.
The target is the supplied Mindly mobile-app reference: a clean white interface, Outfit typography, confident blue accents, soft cool-gray surfaces, rounded geometry, and restrained iOS-style Liquid Glass details. Do not copy the lavender/purple or mustard/gold colors from the component preview. They are not part of the Mindly palette.
A. Non-negotiable visual corrections
1. Cards must have real internal padding. Card content must never touch the card edge. Use 20 px default padding (minimum 16 px on compact cards). Apply padding to the card container itself, not just to selected children.
2. All buttons must be visibly rounded. Never render square-corner buttons. Use the shared button component and explicit radius tokens. Do not rely on browser/platform defaults.
3. All text inputs must share one corner radius. Use 20 px for text fields, search fields, and prompt inputs. Do not create a different radius for email, search, password, or other input types.
4. Buttons and chips use restrained Liquid Glass styling. Use translucent white/blue surfaces, subtle backdrop blur where supported, a fine highlight border, and a soft shadow. The effect must remain light and legible—not glossy, metallic, or skeuomorphic-heavy.
5. No gold, mustard, yellow, or olive UI color. Remove the mustard/gold Inverted button treatment shown in the incorrect preview. Use the approved blue/white/black/neutral palette. Semantic warning colors are allowed only for actual warning states, never as a decorative theme.
6. Do not introduce purple/lavender as a brand accent. The reference uses blue #438BEF, not violet.
7. Do not create one-off component radii. Use the exact shared tokens below.
8. Do not flatten components into square rectangles. Check that CSS resets, utility classes, native controls, or parent styles are not overriding border-radius, padding, overflow, or backdrop effects.
B. Canonical component geometry
Use these values consistently across the application:
| Component | Canonical value |
|---|---:|
| Primary / secondary / outlined button | 18 px radius |
| Compact icon button | 16 px radius or circular |
| Chip / badge | 999 px pill |
| Text input / search input / prompt field | 20 px radius |
| Standard card | 24 px radius |
| Feature card | 28 px radius |
| Bottom navigation outer shell | 999 px pill |
| Active navigation capsule | 999 px pill |
| Bottom sheet / modal top corners | 28 px |
| Avatar | 50% circle |
Do not vary these values by input type or button variant. Variants change color/material, not geometry.
C. Canonical button system
Every button must use one of these variants. All variants share the same height, typography, horizontal padding, and 18 px corner radius unless it is an icon-only circular control.
### Primary
• Background: #438BEF.
• Text/icon: #FFFFFF.
• Radius: 18 px.
• Height: 48–52 px.
• Horizontal padding: 20–24 px.
• Outfit Medium, 14–16 px.
• Subtle blue shadow only when the button floats above a surface.
### Secondary glass
• Background: translucent white, approximately rgba(255,255,255,0.68).
• Text/icon: #111318.
• Radius: 18 px.
• Thin translucent white border.
• backdrop-filter: blur(16px) saturate(150%) where supported.
• Soft neutral shadow.
• On a white background, provide enough surface contrast to remain visible.
### Tertiary
• Transparent background.
• Text/icon: #438BEF or #111318, based on hierarchy.
• Radius remains 18 px for its hit-area container.
• No visible border unless needed for focus.
### Outlined
• Transparent or translucent white background.
• 1 px border in rgba(67,139,239,0.35).
• Text/icon: #438BEF.
• Radius: 18 px.
• Do not use a sharp rectangular outline.
### Inverted / dark
• Background: #000203.
• Text/icon: #FFFFFF.
• Radius: 18 px.
• This is the only inverted treatment. Never use mustard, gold, or olive.
### Icon-only button
• Minimum touch target: 44 × 44 px.
• Visual shape: circular or 16 px rounded square, chosen consistently for the component family.
• Liquid Glass neutral treatment or primary blue fill.
• Center the icon optically.
### Button CSS reference
```css
.button {
min-height: 48px;
padding: 0 22px;
border: 1px solid transparent;
border-radius: 18px;
display: inline-flex;
align-items: center;
justify-content: center;
gap: 8px;
font-family: "Outfit", sans-serif;
font-size: 15px;
font-weight: 500;
line-height: 1;
cursor: pointer;
-webkit-tap-highlight-color: transparent;
transition:
background-color 160ms ease,
border-color 160ms ease,
box-shadow 160ms ease,
transform 160ms ease;
}
.button:active {
transform: scale(0.98);
}
.button--primary {
color: #fff;
background: #438BEF;
box-shadow: 0 4px 12px rgba(67, 139, 239, 0.18);
}
.button--secondary {
color: #111318;
background: rgba(255, 255, 255, 0.68);
border-color: rgba(255, 255, 255, 0.72);
backdrop-filter: blur(16px) saturate(150%);
-webkit-backdrop-filter: blur(16px) saturate(150%);
box-shadow: 0 4px 16px rgba(30, 65, 105, 0.07);
}
.button--outlined {
color: #438BEF;
background: rgba(255, 255, 255, 0.42);
border-color: rgba(67, 139, 239, 0.35);
}
.button--inverted {
color: #fff;
background: #000203;
}
```
Use the project's existing styling approach if it is not CSS, but preserve these visual results.
D. Canonical card system — padding is mandatory
Cards must look like distinct, intentionally padded containers. The incorrect preview shows text sitting against the card edge; this must not happen.
### Standard content card
• Background: #FFFFFF.
• Radius: 24 px.
• Padding: 20 px.
• Gap between card children: 8–12 px.
• Optional subtle shadow: 0 4px 16px rgba(30,65,105,0.045).
• No border by default; use a very subtle border only when the card needs separation.
### Compact card
• Background: #FFFFFF.
• Radius: 24 px.
• Padding: 16 px minimum.
• Content remains inset on every side.
### Feature card
• Background: white or a very subtle blue tint.
• Radius: 28 px.
• Padding: 20–24 px.
• Illustration/icon, title, description, and action must have clear internal spacing.
### Event/task card
• Background: white.
• Radius: 24 px.
• Padding: 16–20 px.
• Use a deliberate content grid for time, title, location, avatars, and action.
• Keep all content inside the card's padding boundary.
### Card CSS reference
```css
.card {
box-sizing: border-box;
width: 100%;
padding: 20px;
border: 1px solid rgba(17, 19, 24, 0.035);
border-radius: 24px;
background: #fff;
box-shadow: 0 4px 16px rgba(30, 65, 105, 0.045);
overflow: hidden;
}
.card__content {
display: flex;
flex-direction: column;
gap: 10px;
min-width: 0;
}
```
Do not remove the card padding to make content align with the outer screen grid. If a card spans the full available width, its content must still remain inset.
F. Liquid Glass treatment for chips and selected controls
Use an iOS-inspired Liquid Glass interpretation—not a literal imitation of any proprietary operating-system component.
### Glass material
• Translucent white or pale-blue fill.
• Background blur: 12–18 px where supported.
• Saturation: 140–160%.
• Fine translucent highlight border.
• Soft, diffused shadow.
• Maintain text contrast and legibility.
• Provide an opaque fallback when backdrop blur is unsupported.
### Chips
• Always pill-shaped: border-radius: 999px.
• Height: 30–36 px depending on density.
• Horizontal padding: 12–14 px.
• Outfit Medium, 12–13 px.
• Default: translucent neutral glass.
• Selected: light blue glass/tint with blue text or icon.
• Avoid rectangular chips and sharp corners.
• Do not give every chip a strong shadow.
### Glass CSS reference
```css
.glass-surface {
background: rgba(255, 255, 255, 0.66);
border: 1px solid rgba(255, 255, 255, 0.78);
border-radius: 999px;
backdrop-filter: blur(16px) saturate(150%);
-webkit-backdrop-filter: blur(16px) saturate(150%);
box-shadow:
0 4px 14px rgba(30, 65, 105, 0.07),
inset 0 1px 0 rgba(255, 255, 255, 0.72);
}
.chip {
min-height: 32px;
padding: 0 13px;
border-radius: 999px;
display: inline-flex;
align-items: center;
gap: 6px;
font: 500 12px/1 "Outfit", sans-serif;
}
```
Use glass styling for chips, floating controls, and selected navigation surfaces. Keep regular content cards mostly solid white so the interface does not become visually foggy.
H. Visual QA — mandatory before calling a screen complete
Check the rendered UI, not just the component code.
• [ ] Every card has visible internal padding on all four sides.
• [ ] No card title, body text, icon, or action touches the card boundary.
• [ ] All buttons have visibly rounded corners (18 px).
• [ ] No button appears as a square rectangle.
• [ ] All text inputs, including search and email, use the same 20 px radius.
• [ ] Chips are pill-shaped and use a subtle Liquid Glass material.
• [ ] Selected/floating controls use restrained glass effects, not heavy blur.
• [ ] No gold/mustard/olive or purple/lavender accent has appeared.
• [ ] The original blue #438BEF remains the primary accent.
• [ ] The interface is still predominantly white, clean, and spacious.
• [ ] Text and icons remain legible over translucent surfaces.
• [ ] Blur has a readable fallback on unsupported browsers/devices.
• [ ] Safe areas, keyboard behavior, and scroll insets are correct.
• [ ] Buttons and chips have default, pressed, focused, and disabled states.
• [ ] No unrelated parts of an existing screen were redesigned.
If any item fails, fix the shared component or token rather than patching individual screens with one-off overrides.
---
# Mindly --- Design System & UI Implementation Guide
> Purpose: This document is the source of truth for implementing
> Mindly's mobile UI in Claude Code. Follow these rules for every
> screen, component, interaction, and visual refinement.
>
> Design direction: Minimal, AI-first, modern iOS-inspired UI with
> subtle neumorphic depth.
>
> Typography: Outfit\
> Primary accent: Blue #438BEF\
> Core surfaces: White and cool off-white
------------------------------------------------------------------------
1. Product UI principles
Mindly should feel like a calm, intelligent personal workspace---not a
generic dashboard or a heavily decorated AI app.
The interface combines: - The clarity and familiarity of modern iOS
interfaces. - Spacious layouts and strong typographic hierarchy. -
Softly rounded cards and pill-shaped controls. - Restrained, tactile
depth through subtle shadows. - A distinctive blue visual language for
AI features.
### Non-negotiable principles
1. Content first: Prioritize useful information and actions over
decoration.
2. Whitespace is intentional: Never compress a screen just to fit
more content.
3. Blue is an accent, not a background default: Keep most everyday
screens white or neutral.
4. Depth must be subtle: Prefer a faint shadow or surface contrast
over thick borders and dramatic neumorphism.
5. Consistent geometry: Reuse the same radius, spacing, and
component rules throughout the app.
6. Native-feeling interactions: Controls should feel responsive,
predictable, and comfortable to use.
7. No arbitrary redesigns: When modifying an existing screen,
preserve its established structure and change only what the task
requires.
2. Visual identity
### Personality
• Intelligent
• Calm
• Approachable
• Premium
• Minimal
• Helpful
### Overall visual balance
Use this as a directional guide, not a rigid measurement:
• 70% white and near-white surfaces
• 20% soft neutral surfaces
• 10% blue accents and AI visual elements
Do not introduce additional accent colors without a clear functional
reason.
------------------------------------------------------------------------
3. Color tokens
### Core palette
-----------------------------------------------------------------------
Token Hex Intended use
----------------------- ----------------------- -----------------------
primary #438BEF Primary actions, links,
active accents, AI
controls
primaryPressed #246FD5 Pressed/active primary
controls
black #000203 Strong icons, dark
navigation,
high-emphasis text
white #FFFFFF Main background, cards,
elevated surfaces
surface #F2F6F9 Secondary backgrounds
and grouped content
gray #808081 Neutral supporting
elements
-----------------------------------------------------------------------
### Extended semantic palette
-----------------------------------------------------------------------
Token Hex Intended use
----------------------- ----------------------- -----------------------
blueLight #DCEBFF Selected or highlighted
backgrounds
blueTint #EEF5FF Subtle AI or
informational
backgrounds
textPrimary #111318 Headings and primary
body text
textSecondary #737B86 Descriptions and
metadata
textTertiary #A0A7B0 Placeholders and
low-emphasis metadata
borderSubtle #E9EEF3 Dividers and optional
outlines
surfaceSecondary #F6F8FA Secondary cards and
grouped sections
success #28A66A Successful/completed
states
warning #E9A23B Attention and warning
states
error #E05252 Errors and destructive
states
-----------------------------------------------------------------------
### Color rules
• Use #FFFFFF as the default screen background.
• Use #F2F6F9 or #F6F8FA to separate grouped content from the main
canvas.
• Use #438BEF for the primary action and meaningful AI emphasis.
• Use near-black for primary text; do not use pure black for every
text element.
• Use semantic colors only when their meaning is clear.
• Do not use blue for every icon, label, card, or decorative element.
• Never communicate status through color alone; pair it with text or
an icon.
### Signature AI gradient
Use sparingly for the AI home/hero experience, onboarding, or a clearly
AI-focused interaction.
``` css
linear-gradient(180deg, #438BEF 0%, #77B3FF 55%, #EAF3FF 100%)
```
Avoid applying this gradient to ordinary content cards, lists, or every
primary button.
------------------------------------------------------------------------
6. Shape language and corner radii
Rounded geometry is a defining part of Mindly's identity.
Token / component Radius
---------------------- --------
Small control 12 px
Input field 18 px
Standard card 22 px
Large feature card 28 px
Modal / bottom sheet 28 px
Pill control 999 px
Avatar 50%
### Rules
• Prefer rounded rectangles and pills.
• Use the same radius for components of the same category.
• Do not mix sharp-cornered cards with very rounded cards without a
functional reason.
• Avoid excessive nested rounded containers; not every element inside
a card needs its own background.
------------------------------------------------------------------------
8. Component specifications
### Buttons
Primary button - Background: primary - Foreground: white - Height:
48–52 px - Radius: 16–24 px - Label: Outfit Medium, 14 px - No
heavy shadow
Secondary button - Background: surface - Foreground:
textPrimary - Same height and typography as primary - No heavy outline
Tertiary/text button - Transparent background - Primary or
text-secondary foreground according to importance - No unnecessary
container
Icon button - Minimum touch target: 44 × 44 px - Visual icon size:
20–24 px - Circular or softly rounded background when needed - Use
consistent outline iconography
States - Default: primary blue. - Pressed: primaryPressed. -
Disabled: muted neutral treatment with reduced emphasis. - Loading:
preserve button dimensions and replace or accompany the label with a
clear progress indicator.
### Cards
Standard card - White background. - Radius: 24 px. - Padding:
16–20 px. - Subtle card shadow only when needed. - No decorative
border by default.
Task/event card - Clear title and information hierarchy. - Metadata
in secondary gray. - Optional status chip or avatar group. - One obvious
contextual action. - Avoid unnecessary dividers and redundant labels.
Feature card - Clear title. - Short description. - Optional simple
icon or illustration. - One clear action. - Use a tinted background only
when it helps identify the feature.
AI feature card - White or subtle blue-tinted surface. - Blue icon
or restrained illustration. - Concise explanatory copy. - Avoid turning
every AI card into a large gradient panel.
### Inputs and search
• Height should be comfortable for one-line entry.
• Use the shared 20 px input radius.
• Use white or soft-gray backgrounds.
• Use 16 px input text.
• Use textTertiary for placeholder text.
• Use a subtle blue focus treatment.
• Keep labels visible where needed; do not rely only on placeholders.
AI command bar - Leading attachment/add action where applicable. -
Flexible text-entry area. - Optional voice input. - Circular blue submit
action. - Clear disabled, focused, listening, and sending states.
### Chips and badges
• Use compact pills for filters, status, and metadata.
• Keep labels short.
• Use a light neutral background by default.
• Reserve blue tint for selected or AI-related states.
• Do not use colored chips for decoration.
### Avatars
• Circular crop.
• Consistent size within a group.
• Use a subtle neutral outline only when needed against a similar
background.
• Support initials or a neutral placeholder when no image is
available.
### Dividers
• Use borderSubtle.
• Keep them thin and low contrast.
• Prefer whitespace over dividers when grouping is already clear.
------------------------------------------------------------------------
9. Navigation
### Floating bottom navigation
The reference direction uses a dark floating pill with a white selected
capsule.
• Outer container: black or near-black.
• Selected item: white capsule.
• Selected icon and label: arranged horizontally in the same layout.
• Inactive items: simple light outline icons.
• Use consistent spacing and alignment.
• Apply a restrained floating shadow.
• Keep the navigation clear of the device home indicator and safe
area.
The selected destination must be identifiable through both icon and
text, not color alone.
### Iconography
• Use one consistent outline icon family, preferably Lucide-style.
• Default stroke width: 1.8–2 px.
• Typical icon size: 20–24 px.
• Align icons optically with text.
• Do not mix filled and outlined icon families without a deliberate
semantic reason.
• Avoid emoji as interface icons.
------------------------------------------------------------------------
10. AI visual language
AI is a core part of Mindly and should have a recognizable but
restrained visual identity.
### Visual treatment
• Primary signature color: blue.
• Soft blue gradients for prominent AI experiences.
• Gentle lighting and subtle depth.
• Rounded geometric forms.
• Minimal 3D or frosted-glass illustrations when useful.
• Small warm yellow highlights may be used sparingly.
### Interaction treatment
• Subtle pulse or glow during active AI processing.
• Clear progress or streaming feedback.
• Smooth transitions between idle, listening, thinking, and
responding.
• Keep generated content structured, readable, and visually consistent
with normal app content.
Avoid excessive neon, sci-fi effects, random sparkles, or decorative
motion that does not communicate state.
------------------------------------------------------------------------
11. Illustration and image direction
When illustrations are needed, use a consistent style:
• Soft 3D forms.
• White and blue as the dominant colors.
• Frosted or translucent materials used selectively.
• Rounded geometry.
• Soft ambient shadows.
• Minimal surface detail.
• Occasional restrained yellow accents.
Illustrations should explain or reinforce a feature. Do not add
decorative images to screens that work better with typography and
whitespace.
------------------------------------------------------------------------
12. Motion and interaction
Motion should feel responsive and natural, not playful or distracting.
Interaction Suggested duration
------------------------- --------------------
Button press 120 ms
Card feedback 160 ms
Modal appearance 220 ms
Bottom sheet 260 ms
Page transition 250--300 ms
AI ambient/loading loop 1.5--2 s
### Motion rules
• Use ease-out for entrances.
• Use ease-in-out for state transitions.
• Keep press feedback quick and subtle.
• Avoid large scaling, exaggerated bounce, or unnecessary parallax.
• Respect the operating system's reduced-motion preference.
• Motion must never be the only way to communicate a state change.
------------------------------------------------------------------------
13. Accessibility and usability
• Target WCAG AA contrast for text and interactive controls wherever
applicable.
• Maintain at least 44 × 44 px touch targets.
• Support dynamic text sizing.
• Respect safe areas and system text scaling.
• Provide visible pressed, focused, disabled, and error states.
• Do not use color as the only status indicator.
• Ensure labels are understandable to screen readers.
• Respect reduced-motion settings.
• Avoid placing essential information inside images.
------------------------------------------------------------------------
14. Screen composition rules
### Everyday productivity screens
• White base canvas.
• Neutral cards and sections.
• Black primary text.
• Gray metadata.
• Blue reserved for actions, selection, and meaningful emphasis.
• Generous vertical spacing.
### AI home / assistant screen
• Blue gradient or blue-tinted hero region.
• Clear greeting or prompt.
• One prominent AI command bar.
• Simple feature shortcuts.
• White or near-white lower content surfaces.
• Keep the AI visual focal point purposeful and uncluttered.
### Lists and schedules
• Prioritize scannability.
• Use consistent row heights and spacing.
• Group related items logically.
• Use secondary gray for time, location, and metadata.
• Avoid placing multiple competing actions in each row.
### Empty states
• One simple illustration or icon when useful.
• A concise explanation.
• One primary next action.
• Avoid large decorative artwork that pushes the action below the
fold.
### Loading and error states
• Preserve layout stability.
• Use skeletons only when they clarify the expected content structure.
• Explain recoverable errors in plain language.
• Provide a clear retry or next action.
------------------------------------------------------------------------
16. Implementation guidance for Claude Code
This document is the visual source of truth. Before implementing a
screen:
1. Inspect the existing project structure, framework, routing, and
styling approach.
2. Identify existing reusable components and preserve working
functionality.
3. Map the design tokens in this document to the project's token/theme
system.
4. Build or reuse shared primitives for buttons, cards, inputs, chips,
icons, and navigation.
5. Implement the requested screen using the shared primitives.
6. Check safe areas, scrolling, keyboard behavior, and touch target
sizes.
7. Verify visual consistency across default, pressed, disabled,
loading, empty, and error states where relevant.
### Code quality rules
• Do not duplicate design token values across components.
• Prefer shared components over screen-specific copies.
• Keep layout, visual styling, and business logic reasonably
separated.
• Use semantic component names.
• Keep components responsive to different mobile screen sizes.
• Avoid unnecessary dependencies.
• Do not replace the project's existing architecture or framework
without explicit instruction.
• Do not remove existing features while implementing visual changes.
• If a reference is ambiguous, choose the simpler treatment that best
follows this guide.
### Change-control rule
When asked to modify a specific UI element: - Change only the requested
element and its directly necessary dependencies. - Preserve the rest of
the screen's layout, content, spacing, colors, and behavior. - Do not
make unrelated visual improvements unless explicitly requested.
------------------------------------------------------------------------
17. Design token reference
Use these values as the canonical starting point. If the project uses
CSS variables, adapt them into its existing token convention rather than
creating a parallel system.
``` css
:root {
/ Brand /
--color-primary: #438BEF;
--color-primary-pressed: #246FD5;
--color-black: #000203;
--color-white: #FFFFFF;
/ Surfaces /
--color-surface: #F2F6F9;
--color-surface-secondary: #F6F8FA;
--color-blue-light: #DCEBFF;
--color-blue-tint: #EEF5FF;
/ Text /
--color-text-primary: #111318;
--color-text-secondary: #737B86;
--color-text-tertiary: #A0A7B0;
--color-gray: #808081;
/ Borders and status /
--color-border: #E9EEF3;
--color-success: #28A66A;
--color-warning: #E9A23B;
--color-error: #E05252;
/ Typography /
--font-family: "Outfit", sans-serif;
--font-regular: 400;
--font-medium: 500;
--font-semibold: 600;
--font-bold: 700;
/ Radius /
--control-height: 52px;
--control-radius: calc(var(--control-height) / 2);
--radius-sm: 16px;
--radius-md: var(--control-radius);
--radius-lg: 24px;
--radius-xl: 28px;
--radius-pill: 999px;
/ Spacing /
--space-1: 4px;
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
--space-5: 20px;
--space-6: 24px;
--space-8: 32px;
--space-10: 40px;
--space-12: 48px;
/ Elevation /
--shadow-card: 0 4px 16px rgba(30, 65, 105, 0.045);
--shadow-floating: 0 6px 24px rgba(0, 0, 0, 0.10);
--shadow-control: 0 3px 10px rgba(30, 65, 105, 0.08);
}
```
------------------------------------------------------------------------
Final design standard
Mindly should look premium through **restraint, clarity, consistency,
and thoughtful interaction**.
When choosing between a decorative treatment and a simpler one, choose
the simpler one unless the decoration improves comprehension or
reinforces the AI experience.
Every screen should feel like part of one coherent product: spacious,
intelligent, approachable, and calm.
# 18. Complete UI component catalogue
This section defines the visible interface elements in the supplied mobile mockups. Treat these specifications as reusable components—not one-off screen decorations. Implement each component as a shared component where the project architecture allows it.
18.1 Device and screen foundations
### Status bar
• Respect the native iOS/Android status bar and safe-area insets.
• Use dark status-bar content on light backgrounds and light status-bar content over saturated blue hero backgrounds, depending on contrast.
• Never draw app content underneath system indicators unless the platform's edge-to-edge layout is intentionally configured.
• Do not hardcode the time, signal, Wi-Fi, battery, or system indicators.
### Screen canvas
• Default background: #FFFFFF.
• Use #F2F6F9 for a softly differentiated content region.
• Screen content should scroll naturally beneath a fixed or floating navigation area.
• Keep bottom content clear of the home indicator and navigation controls.
• Use a consistent horizontal inset of approximately 20 px, adjusted for device width and safe areas.
### Scroll behavior
• Avoid nested scrolling unless a specific interaction requires it.
• Floating controls must not cover the last content row.
• When the keyboard opens, keep the focused input and its submit action visible.
• Preserve scroll position when returning from a detail screen where practical.
18.2 Header and greeting area
The header is a compact personal area at the top of the home screen.
Structure
1. User avatar.
2. Greeting text, such as “Good morning”.
3. Supporting context, such as today's task count.
4. Search icon button.
5. Notification icon button.
Appearance
• Use a horizontal row with vertically centered content.
• Avatar: approximately 36–42 px, circular.
• Greeting: Outfit SemiBold, approximately 14–16 px.
• Supporting text: Outfit Regular, 11–12 px, secondary color.
• Search and notification controls: 40–44 px touch targets.
• On a blue hero background, use subtle translucent white circular controls and white icon strokes.
• On a white background, use neutral or lightly tinted controls with dark icons.
Behavior
• Avatar opens the profile/account destination.
• Search opens the app's search experience.
• Notification opens the notification center.
• Provide accessible labels for icon-only actions.
18.3 AI hero / assistant area
The AI area is the primary visual focal point on the assistant-style home screen.
Composition
• Optional greeting/header above the hero.
• Short centered or left-aligned prompt, e.g. “How can I help you today?”
• Optional AI orb or restrained 3D AI illustration.
• Prompt input or command bar.
• Optional shortcut cards beneath the prompt.
Background
• Use the signature blue gradient only in this focused area.
• Gradient direction: blue at the top, transitioning through lighter blue to a pale or white lower edge.
• Keep the gradient smooth and low-noise.
• Avoid patterns, textures, or unrelated decorative graphics.
AI orb
• Circular, softly reflective blue object.
• Use a restrained highlight and soft shadow to suggest depth.
• It should not compete with the prompt text.
• Provide a static fallback if 3D rendering or animation is unavailable.
• Do not use a continuously animated orb unless it communicates an active AI state.
AI state variants
• Idle: calm static orb or icon.
• Listening: subtle pulse/ring with a visible listening label.
• Processing: restrained animated indicator and clear status text.
• Responding: show streaming or response progress.
• Error: concise explanation and retry action.
18.4 AI prompt / command bar
The prompt bar appears in both supplied app-screen references and should be treated as a core reusable component.
Anatomy
• Optional leading add/attachment button.
• Text input area.
• Optional microphone/voice input button.
• Circular send/submit button.
Visual specification
• White surface.
• Pill-shaped or generously rounded rectangle.
• Radius: 24–999 px, depending on the layout.
• Height: approximately 52–60 px.
• Very subtle shadow or a fine neutral edge.
• Input text: Outfit Regular, 14–16 px.
• Placeholder: #A0A7B0.
• Send action: circular blue control, approximately 36–40 px.
• Leading and voice controls: neutral circular or icon-only touch targets.
Behavior
• Expand vertically for multiline input, with a sensible maximum height.
• Keep send action aligned to the lower/right edge when multiline.
• Disable send when the prompt is empty, unless another valid attachment/action is present.
• Support keyboard submit where appropriate.
• Show clear attachment, recording, sending, and disabled states.
• Do not clear a user's draft unexpectedly.
States
• Default: placeholder visible.
• Focused: subtle blue focus treatment.
• Typing: entered text in primary color.
• Recording: visible active microphone state and recording feedback.
• Sending: progress state; prevent accidental duplicate submission.
• Disabled: muted controls with accessible state information.
18.5 Add / attachment button
• Circular or softly rounded icon control.
• Minimum touch target: 44 × 44 px.
• Neutral white or pale-gray surface.
• Use a simple plus or attachment icon.
• Opens a clearly labelled attachment/action sheet.
• The action sheet should use the shared bottom-sheet component defined below.
18.6 Voice input button
• Use a microphone outline icon.
• Default state: neutral surface and dark icon.
• Active recording state: primary blue or a clearly distinguishable semantic treatment.
• Provide a visible listening/recording indicator and an accessible label.
• Ask for microphone permission only when the user initiates voice input.
• Include permission-denied and recording-error states.
• Never rely on animation alone to indicate that recording is active.
18.7 Send button
• Circular blue button inside or at the trailing edge of the prompt bar.
• White send/arrow icon.
• Approximately 36–40 px visual diameter, with a comfortable overall touch target.
• Pressed state uses #246FD5.
• Disabled state uses a muted blue-gray treatment.
• Loading state must prevent duplicate submissions and preserve the control's dimensions.
18.8 Shortcut / AI feature tiles
The assistant reference shows a two-column group of feature shortcuts:
• Voice Chat AI
• Chat with AI
• Generate Images
• Scan and Search
These are reusable action tiles.
Structure
• Small icon inside a subtle circular or softly tinted icon holder.
• Short feature label.
• Optional supporting description when needed.
Appearance
• White surface.
• Radius: 20–24 px.
• Padding: 14–16 px.
• Subtle card separation; avoid heavy borders.
• Icon size: 20–24 px.
• Label: Outfit Medium, 14–16 px.
• Use a two-column grid when the available width allows it.
• Maintain equal card heights within a row where practical.
Behavior
• Entire tile is a touch target.
• Provide pressed feedback.
• Open the associated feature or workflow.
• Use a clear selected/disabled state if a feature is unavailable.
18.9 Section heading row
Used for sections such as “Upcoming Events” and “Recently Visited”.
Anatomy
• Section title on the leading side.
• Optional count, status, or supporting metadata.
• Optional “View all” action on the trailing side.
Appearance
• Title: Outfit SemiBold, 16–18 px.
• Metadata/action: Outfit Regular or Medium, 11–13 px.
• Use black/primary text for the title and gray for secondary details.
• Align elements vertically.
• Provide approximately 12–16 px spacing before the section content.
Behavior
• “View all” opens the complete list.
• Counts must reflect actual data; do not hardcode sample counts in production.
18.10 Upcoming event / task card
The reference shows a white event card with a time chip, event title, location, participant avatars, a small contextual chip, and a circular arrow action.
Anatomy
1. Time-range chip.
2. Event or task title.
3. Location or meeting detail.
4. Participant avatar group.
5. Optional contextual chip, such as “Today | 1h”.
6. Circular open/detail action.
Appearance
• White card.
• Radius: 24 px.
• Padding: 16–18 px.
• Subtle shadow against a light-gray content background.
• Time chip: small neutral pill with compact gray text.
• Title: Outfit SemiBold, 15–16 px.
• Location: Outfit Regular, 11–12 px, secondary gray.
• Avatar diameter: approximately 26–30 px.
• Avatar group: slight overlap with a consistent outline if needed.
• Context chip: pale-gray pill with dark compact text.
• Arrow action: dark circular control, approximately 36–40 px, with a white diagonal arrow icon.
Layout
• Time chip near the top.
• Title and location grouped together.
• Context chip and participant avatars placed in the lower area.
• Arrow action aligned consistently to the upper or trailing area.
• Do not allow the action button to collide with the title or metadata.
Behavior
• Tapping the card opens the event/task detail.
• If the arrow is a separate action, make its hit area independent and provide an accessible label.
• Long titles should wrap cleanly.
• Missing location or participants should not leave awkward empty placeholders.
• Show real event times and participant data.
18.11 Time and metadata chips
• Use a pill shape.
• Neutral background by default.
• Compact horizontal and vertical padding.
• Outfit Regular, approximately 10–12 px.
• Use gray text for time and supporting information.
• Use blue tint only for selected, active, or AI-related metadata.
• Avoid making every metadata value look like a button.
18.12 Participant avatar group
• Circular avatars with consistent dimensions.
• Slight overlap when multiple people are displayed.
• Use a fine white outline to separate overlapping avatars.
• Show a maximum number of avatars appropriate to the available space.
• If there are more participants, use a compact +N avatar.
• Provide participant names through accessibility labels or the event detail view.
• Use neutral initials placeholders when profile images are unavailable.
18.13 Recently visited cards
The reference includes a horizontally arranged recently visited area.
Appearance
• White or soft-gray cards.
• Rounded corners consistent with the card system.
• Short title or destination label.
• Optional icon, thumbnail, or small metadata.
• Keep cards visually quieter than the main AI feature.
Behavior
• Horizontal scrolling when there are multiple items.
• Maintain consistent card widths and gaps.
• Make the whole card tappable.
• Include a “View all” action in the section heading when applicable.
• Do not force horizontal scrolling if a simple vertical list is more usable for the actual content.
18.14 Bottom navigation bar
The bottom navigation is a defining element of the first home-screen reference.
Anatomy
• Floating dark pill-shaped outer container.
• Selected destination shown inside a white capsule.
• Selected icon and label arranged horizontally in the same capsule.
• Inactive destinations shown as simple light outline icons.
• Optional separate circular AI/assistant action at the trailing edge, if that is part of the actual app navigation model.
Appearance
• Outer background: #000203 or near-black.
• Outer radius: 999 px.
• Selected capsule: #FFFFFF.
• Selected icon and text: #000203.
• Inactive icons: #FFFFFF or a softened white.
• Icon size: 19–22 px.
• Selected label: Outfit Medium, 12–13 px.
• Container padding: approximately 6–8 px.
• Use a restrained floating shadow.
• Keep sufficient space around the bar and above the system home indicator.
Layout rules
• The active icon and label must remain in one horizontal row.
• Inactive items may be icon-only when their destinations are clear and accessible labels are provided.
• Use even spacing and consistent visual centering.
• The selected capsule should expand naturally to fit its label.
• Do not squeeze labels or allow the active capsule to overlap adjacent items.
• If the navigation contains more destinations than fit comfortably, rethink the navigation model rather than shrinking touch targets.
Behavior
• Each item navigates to a distinct top-level destination.
• Clearly expose the current selected destination.
• Preserve state/scroll position where appropriate.
• Use accessible labels and selected-state semantics.
• Avoid placing the bar over scrollable content; add the necessary bottom inset.
18.15 Floating AI action button
The first reference shows a separate circular action near the bottom navigation; the assistant reference also uses a prominent central AI control.
Appearance
• Circular shape.
• Black or primary blue fill depending on context.
• White AI, sparkle, or assistant icon.
• Approximately 48–56 px visual diameter.
• Subtle floating shadow.
• Clear separation from the bottom navigation pill.
Behavior
• Opens the AI assistant or the app's primary AI action.
• Provide a clear accessible label.
• Show a pressed state.
• Do not obscure navigation items or important content.
• If the button is central to the product, preserve its position and treatment consistently across relevant screens.
18.16 Assistant bottom action controls
The assistant mockup shows a bottom group of circular controls: a conversation/chat action, a highlighted AI/sparkle action, and a close action.
Appearance
• Circular controls with equal visual dimensions.
• Neutral white or translucent surfaces for secondary actions.
• Primary blue fill or blue glow only for the active AI action.
• Dark outline icons on neutral surfaces.
• Consistent spacing and alignment.
Behavior
• Each control must have a distinct, documented action.
• The close control dismisses the assistant layer and returns to the previous context.
• The chat control opens or switches to the relevant conversation mode.
• The AI control activates the assistant's primary interaction.
• Do not display controls that have no implemented action.
18.17 Search and notification controls
• Circular or softly rounded icon buttons.
• Minimum touch target: 44 × 44 px.
• Search uses a magnifying-glass outline.
• Notifications use a bell outline.
• Use white translucent surfaces on the blue hero.
• Use a neutral surface on white backgrounds.
• A notification indicator should be small and unobtrusive.
• Do not show a badge unless there are unread notifications.
18.18 Bottom sheets and action sheets
Use for attachment options, contextual actions, filters, or secondary workflows.
Appearance
• White surface.
• Top corner radius: 28 px.
• Optional small drag handle.
• Comfortable horizontal padding.
• Clear title and optional description.
• Rows with icons and labels.
• Subtle dividers only where needed.
• Background scrim should be restrained.
Behavior
• Support swipe-to-dismiss where the platform allows it.
• Provide an explicit close/dismiss action.
• Respect safe areas.
• Keep destructive actions visually and spatially separate.
• Do not use a bottom sheet for a workflow that requires a full dedicated screen.
18.19 Modals and dialogs
• White surface.
• Radius: 24–28 px.
• Clear title, concise body, and explicit actions.
• Use primary and secondary button hierarchy.
• Keep destructive actions clearly identified.
• Do not stack multiple modal layers.
• Return focus to the initiating control when dismissed where supported.
19. Component inventory checklist
Use this checklist when translating the references into the actual app component library.
### Foundations
• [ ] Screen canvas and safe-area wrapper
• [ ] Status-bar appearance handling
• [ ] Typography styles
• [ ] Color and semantic tokens
• [ ] Spacing and radius tokens
• [ ] Shadow/elevation tokens
• [ ] Icon wrapper and icon sizing rules
### Header
• [ ] User avatar
• [ ] Greeting and supporting text
• [ ] Search icon button
• [ ] Notification icon button
• [ ] Notification unread indicator
### AI experience
• [ ] AI hero/gradient surface
• [ ] AI orb or static fallback
• [ ] AI prompt/command bar
• [ ] Add/attachment button
• [ ] Text input
• [ ] Voice input button
• [ ] Send button
• [ ] AI shortcut tile
• [ ] AI processing/listening/responding states
### Productivity content
• [ ] Section heading row
• [ ] Count/status metadata
• [ ] Upcoming event/task card
• [ ] Time chip
• [ ] Context chip
• [ ] Participant avatar group
• [ ] Circular arrow/detail action
• [ ] Recently visited card
• [ ] Horizontal card list
• [ ] View-all action
### Navigation and overlays
• [ ] Floating bottom navigation container
• [ ] Active navigation capsule with horizontal icon + label
• [ ] Inactive navigation icon items
• [ ] Floating AI action button
• [ ] Assistant bottom action controls
• [ ] Bottom sheet/action sheet
• [ ] Modal/dialog
• [ ] Toast/feedback message
### States and accessibility
• [ ] Default
• [ ] Pressed
• [ ] Focused
• [ ] Selected
• [ ] Disabled
• [ ] Loading
• [ ] Empty
• [ ] Error
• [ ] Offline
• [ ] Screen-reader labels
• [ ] Dynamic text sizing
• [ ] Reduced motion
• [ ] Safe-area and keyboard behavior
---
20. Reference fidelity and implementation acceptance criteria
A screen is considered visually aligned with the references when:
1. The overall canvas remains bright, spacious, and predominantly white.
2. Blue is used as a deliberate AI/action accent, not as a universal card color.
3. Outfit typography is consistent across headings, labels, metadata, and controls.
4. Cards use soft corners and restrained elevation.
5. The AI prompt bar has clear attachment, text-entry, voice, and submit affordances where applicable.
6. Event cards preserve the hierarchy of time, title, location, participants, and contextual action.
7. The bottom navigation uses a dark floating pill with a white active capsule and horizontal active icon/label layout.
8. Floating AI controls remain distinct from ordinary navigation.
9. Every visible control has a real action, accessible name, and appropriate interaction state.
10. The UI remains usable with long text, empty data, loading, errors, keyboard display, and different mobile screen sizes.
Important: The component catalogue describes the visual elements shown or implied by the supplied app-screen references. It does not authorize adding every component to every screen. Use only the components relevant to the screen and its actual functionality.
Use with MCP
Don't have the MCP? Install it here