ios-taste

Files (6)

• AGENTS.md
• SKILL.md
• metadata.json
• apple-design-dna.md · references/
• generate_palette.py · scripts/
• verify_palette.py · scripts/

SKILL.md (first lines)

# iOS Taste

Taste doesn't start at the pixel level. It starts at "who is this
person and what do they need?" The visual refinement is the LAST step.
The first step is understanding the user's world deeply enough that
the interface design feels inevitable — like it couldn't have been
designed any other way.

Your default mode skips straight to layout. It produces technically
correct SwiftUI that looks generic because it was never grounded in
a real person's needs. This skill changes the order of operations:
think like a designer first, then write code.

## Phase 0: The 0.5-Second Test (ORIENT before everything)

Before designing anything, answer ONE question:

> **What does the user SEE in the first half-second — before they
> read a single word?**

This is not about content. It's about the SHAPE of the screen.
Close your eyes and picture it. What dominates?

- A **ring** at 40% of screen height? → Fitness dashboard
- A **gradient card** with bold white text? → Music/travel/content
- A **large number** floating in space? → Finance/health metric
- A **grid of thumbnails**? → Photo/recipe/shopping collection
- A **clean form** with generous space? → Settings/profile

If your answer is "a List with rows of text" → STOP. That's a
spreadsheet, not an app. Go back and find the visual shape.

Write the 0.5-second answer as the FIRST line of the experience
brief:

```swift
// 0.5s: Four warm gradient cards stacked on black — a cookbook
```

This single sentence anchors every decision that follows. If the
code you write doesn't produce that shape, something went wrong.

## Phase 1: Design Thinking (Before You Touch SwiftUI)

Before writing a single line of code, answer these questions. Write
the answers down as comments or in your thinking. If you skip this
phase, your output will look like every other AI-generated UI —
correct but soulless.

### 1. Who is the user?

Not "a fitness enthusiast." A real person with a context:

- What moment are they in when they open this screen? (Rushing
  between meetings? Relaxing on the couch? Mid-workout?)
- What did they just do before arriving here? (Finished a run?
  Browsed a list? Got a notification?)
- What do they want to accomplish in under 10 seconds?

This shapes EVERYTHING. A user mid-workout needs giant tap targets
and glanceable data. A user browsing recipes at home wants rich
detail and discovery. A user configuring settings wants to find the
one toggle they care about and leave.

### 2. What should they FEEL?

This is the question that separates designed apps from information
displays. Apple Fitness doesn't show you data — it motivates you to
move. Every design choice serves that emotional goal.

Before choosing components, decide the emotional intent:
- **Motivated** → bold colors, progress visualization, celebration
  moments, large achievement numbers
- **Calm / focused** → muted tones, generous space, subtle motion
- **Efficient** → compact layouts, clear hierarchy, minimal chrome
- **Delighted** → unexpected animation, rich materials, playful
  moments (achievement badges, confetti, 3D icons)
- **Confident** → clean data presentation, trust colors (blue/green),
  professional typography

The emotional intent drives every visual decision downstream: color
palette, scale, spacing, whether data is listed or visualized,
whether the screen feels dense or spacious.

### 3. What are their goals and pain points?

For each screen, identify:
- **Primary goal** — the ONE thing most users come here to do
- **Secondary goals** — things some users occasionally need
- **Pain points** — what frustrates users in this domain?

A fitness settings screen: the primary goal isn't "see all settings."
It's "change the one thing that's been bugging me" — maybe the
weekly goal is too low, or notifications come at the wrong time. The
pain point is wading through 30 options to find the one they need.

### 3. What features serve those goals?

Map goals to features. Not "what features could this screen have?"
but "what's the minimum set of features that makes the primary goal
effortless?" Every feature that doesn't serve a goal is clutter.

Group features by priority:
- **Must-have** — blocks the primary goal without it
- **Should-have** — significantly improves the experience
- **Could-have** — nice but the user doesn't miss it if it's absent

### 4. How do features become screens?

This is information architecture — deciding what goes where:

- **One primary action per screen.** If a screen tries to do two
  things, split it into two screens or use progressive disclosure.
- **Group by user intent, not by data type.** A user doesn't think
  "I want to see my notification settings." They think "I want my
  phone to stop buzzing during workouts." Group features by the
  problem they solve, not by their technical category.
- **Navigation follows the user's mental model.** Settings → Profile
  is obvious. Settings → "Health Integrations" → Apple Health → Data

From pproenca/dot-skills, MIT.

More from pproenca/dot-skills