Style Selection (Per App / Per Task)
Why this needs its own decision, on purpose
Every rule in this skill family (spacing, color roles, elevation, motion) is a craft floor — it keeps anything built on it from looking broken or generic. But craft alone doesn't give an app personality, and a portfolio of tools that all share the exact same accent blue, the exact same rounded-corner card, and the exact same motion timing will start to feel like reskins of each other rather than distinct products. Decide the personality on purpose, before locking in specifics.
The direction brief — answer these before choosing a single color or font
- What is this tool for, moment to moment? A creative/audio tool used in bursts of flow state needs a different feel than a technical dev tool used with a terminal open beside it, which needs a different feel than a productivity/sorting tool used many times a day for seconds at a time.
- What's the emotional register? Playful and organic vs. precise and technical vs. calm and quiet vs. energetic — pick a register in a sentence, not a mood board of forty images.
- What's the one visual motif, if any, that's actually tied to what the app is (a brand mark, a shape from the domain itself — a waveform, a mesh, a folder) — and can it inform something beyond the logo (an accent shape, an icon style, a loading-state animation)?
- Who is this genuinely for — a solo power user who wants density and speed, or someone who needs a gentler, more guided experience? This affects information density and how much the UI should "explain itself" versus get out of the way.
Translating the brief into decisions
Once the four answers above exist, they should visibly shape:
| Register |
Color approach |
Type approach |
Motion personality |
Radius/shape language |
| Precise / technical (dev tools, data tools) |
Desaturated neutrals, one sharp accent, minimal color elsewhere |
Monospace or a technical sans for data-heavy areas; tight, efficient |
Fast, minimal (100–150ms), almost no bounce |
Small radius (4–8px), sharper geometry |
| Organic / creative (audio, art, writing tools) |
Slightly warmer neutrals, room for a richer accent palette tied to the brand motif |
A sans with more character than a pure system font; slightly looser tracking |
Can afford a touch more personality (subtle spring/bounce on rare, celebratory moments only) |
Rounder radius, softer shapes — but still restrained per foundations, not maximal roundness everywhere |
| Calm / utility (productivity, sorting, background tools) |
Very restrained, mostly neutral, accent used sparingly for state only |
Plain, highly legible, no personality flourishes |
Minimal, close to invisible — this register benefits most from motion that's felt rather than seen |
Small-to-medium radius, consistent and unremarkable on purpose |
These are starting points, not a lookup table to apply blindly — the point of the brief is to make a specific call for a specific app, not to pick a row and stop thinking.
Consistency within a multi-app portfolio
If several apps share this skill family (a shared design-token structure, a shared craft floor), they can still each have their own accent color, type pairing, and motion personality without breaking consistency — because the rules that keep each one from looking broken (spacing scale, elevation logic, state coverage, anti-AI-slop checklist) stay identical across all of them. Consistency at the craft level plus distinctiveness at the style level is the goal — not one identical skin stamped across every product.
Locking it in
Once a direction is chosen, write it down in one short reference (a references/style-direction.md alongside the app's own theme file is enough) so future work on the same app — by a future session, a different agent, or a different contributor — starts from the same brief instead of drifting toward the generic default a few decisions at a time.
Scope the accessibility and localization commitment here too
Whether the app needs to support right-to-left locales or heavy translation is a scope decision as real as the visual register, and it's far cheaper to decide up front than retrofit later — it changes how much headroom to build into every label and layout from day one. Decide it in the same brief, alongside register and motif. See desktop-ui-accessibility-i18n.
Review format
| Before |
After |
Why |
| Every new app defaults to the same "clean SaaS" blue accent and rounded card |
A register chosen deliberately from the direction brief for this specific app |
Skipping the brief is how a whole portfolio ends up looking like reskins of the same product |
| Localization/RTL support decided reactively once translation strings arrive |
Decided as part of the initial direction brief, before layouts are locked |
Retrofitting text-expansion headroom and RTL mirroring after the fact costs far more than designing for it up front |
1---2name: desktop-ui-style-direction3description: Use at the START of any new app or major redesign, before picking specific colors/type/icons, to deliberately choose an aesthetic direction that fits what the app actually is — instead of defaulting to one generic "clean SaaS" look for every project. Depends on desktop-ui-foundations. Trigger on "what should this look like," "style direction," "visual identity," "this app needs its own personality," or when starting a new app in a multi-app portfolio.4---56# Style Selection (Per App / Per Task)78## Why this needs its own decision, on purpose910Every rule in this skill family (spacing, color roles, elevation, motion) is a craft floor — it keeps anything built on it from looking broken or generic. But craft alone doesn't give an app personality, and a portfolio of tools that all share the exact same accent blue, the exact same rounded-corner card, and the exact same motion timing will start to feel like reskins of each other rather than distinct products. Decide the personality on purpose, before locking in specifics.1112## The direction brief — answer these before choosing a single color or font13141. **What is this tool for, moment to moment?** A creative/audio tool used in bursts of flow state needs a different feel than a technical dev tool used with a terminal open beside it, which needs a different feel than a productivity/sorting tool used many times a day for seconds at a time.152. **What's the emotional register?** Playful and organic vs. precise and technical vs. calm and quiet vs. energetic — pick a register in a sentence, not a mood board of forty images.163. **What's the one visual motif, if any, that's actually tied to what the app is** (a brand mark, a shape from the domain itself — a waveform, a mesh, a folder) — and can it inform something beyond the logo (an accent shape, an icon style, a loading-state animation)?174. **Who is this genuinely for** — a solo power user who wants density and speed, or someone who needs a gentler, more guided experience? This affects information density and how much the UI should "explain itself" versus get out of the way.1819## Translating the brief into decisions2021Once the four answers above exist, they should visibly shape:2223| Register | Color approach | Type approach | Motion personality | Radius/shape language |24|---|---|---|---|---|25| Precise / technical (dev tools, data tools) | Desaturated neutrals, one sharp accent, minimal color elsewhere | Monospace or a technical sans for data-heavy areas; tight, efficient | Fast, minimal (100–150ms), almost no bounce | Small radius (4–8px), sharper geometry |26| Organic / creative (audio, art, writing tools) | Slightly warmer neutrals, room for a richer accent palette tied to the brand motif | A sans with more character than a pure system font; slightly looser tracking | Can afford a touch more personality (subtle spring/bounce on rare, celebratory moments only) | Rounder radius, softer shapes — but still restrained per foundations, not maximal roundness everywhere |27| Calm / utility (productivity, sorting, background tools) | Very restrained, mostly neutral, accent used sparingly for state only | Plain, highly legible, no personality flourishes | Minimal, close to invisible — this register benefits most from motion that's felt rather than seen | Small-to-medium radius, consistent and unremarkable on purpose |2829These are starting points, not a lookup table to apply blindly — the point of the brief is to make a specific call for a specific app, not to pick a row and stop thinking.3031## Consistency within a multi-app portfolio3233If several apps share this skill family (a shared design-token structure, a shared craft floor), they can still each have their own accent color, type pairing, and motion personality without breaking consistency — because the *rules that keep each one from looking broken* (spacing scale, elevation logic, state coverage, anti-AI-slop checklist) stay identical across all of them. Consistency at the craft level plus distinctiveness at the style level is the goal — not one identical skin stamped across every product.3435## Locking it in3637Once a direction is chosen, write it down in one short reference (a `references/style-direction.md` alongside the app's own theme file is enough) so future work on the same app — by a future session, a different agent, or a different contributor — starts from the same brief instead of drifting toward the generic default a few decisions at a time.3839## Scope the accessibility and localization commitment here too4041Whether the app needs to support right-to-left locales or heavy translation is a scope decision as real as the visual register, and it's far cheaper to decide up front than retrofit later — it changes how much headroom to build into every label and layout from day one. Decide it in the same brief, alongside register and motif. See `desktop-ui-accessibility-i18n`.4243## Review format4445| Before | After | Why |46|---|---|---|47| Every new app defaults to the same "clean SaaS" blue accent and rounded card | A register chosen deliberately from the direction brief for this specific app | Skipping the brief is how a whole portfolio ends up looking like reskins of the same product |48| Localization/RTL support decided reactively once translation strings arrive | Decided as part of the initial direction brief, before layouts are locked | Retrofitting text-expansion headroom and RTL mirroring after the fact costs far more than designing for it up front |
simply-ehis