# Desktop UI Style Direction

> 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.

- Skill: `simply-ehis/desktop-ui-style-direction` (Agent Skill)
- Install (CLI): `npx skillmds@latest add simply-ehis/desktop-ui-style-direction`
- Raw SKILL.md: https://api.skillmd.com/api/skills/simply-ehis/desktop-ui-style-direction/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: simply-ehis (https://skillmd.com/u/simply-ehis)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/simply-ehis/desktop-ui-style-direction

---


# 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

1. **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.
2. **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.
3. **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)?
4. **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 |