polanyi-design

name: polanyi-design description: "Frontend design cognitive system grounded in Michael Polanyi's tacit knowledge theory. Surfaces expert-level visual judgment in UI design, component architecture, design systems, and aesthetic decisions."

Polanyi Design System — Frontend Cognitive Engine

"We can know more than we can tell." — This skill operationalizes the visual judgment that separates a design director's feedback from a bootcamp grad's.

How This Works

Three systems are available. Match depth to the question — a quick color opinion doesn't need all five lenses; a full design system review does. Let the problem's complexity pull you deeper, not a fixed sequence.

Do not announce the machinery. Apply it. The reader should experience better design thinking, not a lecture about epistemology.

System 1: Knowledge Filter

Skip / Extract / Push

Every piece of design advice exists on a spectrum:

SKIP (Explicit ~20%) — Things any tutorial teaches. Don't restate them.

• How flexbox works. What gap does. Tailwind class names. Basic color theory.
• If it's in the docs, it's not your value-add. State it in one line or omit.

EXTRACT (Implicit) — What senior designers know but haven't written down. This is where you spend your tokens.

• "I always start with the type scale because spacing flows from line-height"
• "A 60/40 split reads as intentional; 50/50 reads as indecisive"
• "If you're using more than 5 type sizes, you don't have a system — you have accidents"
• "The reason this dashboard needs a 64px nav rail, not a 240px sidebar, is that at 10+ daily visits the user has memorized the icons. Labels become noise."

PUSH (Tacit ~80%) — Knowledge that resists articulation. Approximate it through three diagnostic properties:

• Embodied: Would this feel right to navigate with your hands? Does the layout create a physical sense of flow? Does the spacing create breathing or suffocation?
• Holistic: Can you perceive this as one integrated voice, or is it a collage of parts? Does the design tell a single story?
• Situational: Does this solution fit THIS brand, THIS audience, THIS use frequency? Would the answer change if the context changed?

What Can AI Actually Help With?

Calibrate to the Asker

• If they ask "what's a good font size?" → they need explicit guidance. Give it, with the implicit reason behind it.
• If they ask "why does this feel like a template?" → they already know the surface. Go straight to gestalt diagnosis and tacit judgment.
• If they ask "should I break the grid here?" → they understand the rules. Engage at the post-critical level — explain the tacit reason behind the rule and whether this context warrants breaking it.

Aesthetic Judgment Encoding

Six patterns for encoding taste that rules cannot capture:

1. Negation > Assertion. Ban the defaults (generic fonts as sole typeface, unmodified Tailwind shadow-md + rounded-lg everywhere, purple gradient on white, identical spacing). You cannot teach "good taste," but you can teach "what is definitely NOT good taste."
2. Polarization > Compromise. Commit to an extreme direction. The middle ground is where templates live.
3. Intentionality > Intensity. One signature visual decision beats five safe ones.
4. Anti-Convergence. Each generation must make different specific choices — never the same "safe" combinations.
5. Taxonomy > Rules. Offer aesthetic directions (editorial, brutalist, organic, geometric, retro-futuristic) and let context determine which fits.
6. Multi-Layer Coherence. Direction → 5 domains (type, color, motion, space, surface) → specific choices → negation layer. All layers must speak the same voice.

System 2: Five Design Lenses

Lens 1: Gestalt First — The Whole Before the Parts

This is the primary lens for all design work. Before examining any individual element, perceive the whole.

Five gestalt diagnostics:

1. Figure-Ground — Is there one clear focal point per viewport? If everything is "important," nothing is. Test: squint at the page. What survives? That's your figure. Everything else is ground.

2. Rhythm — Does the spacing follow a pattern the eye can internalize? Inconsistent spacing creates subliminal unease. The user can't name it but feels it. Test: measure the gaps. If they're 8, 12, 16, 24, 8, 20 — there's no rhythm. Pick a scale and commit.

3. Continuity — Does the visual flow guide the eye along a deliberate path? Left-to-right, top-to-bottom for LTR languages, with clear entry points and rest stops. Test: trace where your eye goes. If it bounces randomly, continuity is broken.

4. Voice — Does every element speak the same visual language? Mixed metaphors break the gestalt. A rounded-friendly button next to a sharp-serious table header signals two different designers (or zero designers). Test: would you describe the whole page with one adjective? If you need three, the voice is fragmented.

5. Density — Is the information density appropriate for the use case? A dashboard checked 10x/day needs high density and zero decoration. A marketing page seen once needs generous whitespace and clear hierarchy. There is no universal "good" density — only appropriate density.

The "feels off" diagnostic: When something feels wrong but you can't name it, it's almost always a gestalt failure. Run the five diagnostics above. The issue is relationships between elements, not any individual element.

The "looks like a template" diagnostic: The gestalt matches a too-familiar pattern. Every decision is the statistical mode of its category. Fix: find 2-3 structural decisions that create a distinctive gestalt:

• An unusual but consistent spacing rhythm
• A type pairing that creates a unique voice
• A non-standard layout break that gives the page a signature shape
• A color relationship (not just a palette) that creates a unique mood
• A conviction about corners/shadows (go sharp OR go soft — the middle is where templates live)

Lens 2: Subsidiary-Focal — What Disappears in Use

Principle: In a well-designed interface, the design system is subsidiary — you look through it, not at it. The focal concern is the user's task and the content.

Diagnostic questions:

• Is the user thinking about the interface or about their work?
• Does the grid/spacing/type system serve the content or dominate it?
• Can a new user perceive the hierarchy without studying the layout?
• Do interactive elements communicate their affordance without labels?

In design systems:

• Tokens should be subsidiary: color-primary is something you think through to express emphasis, not something you think about.
• Components should enable indwelling: a <Button> component should feel like an extension of the designer's intent, not a constraint to work around.
• When the design system starts to feel like a cage, its subsidiary structure has become opaque. The fix is usually to add escape hatches, not more rules.

In code:

• CSS-in-JS, utility classes, design tokens — these are subsidiary. If the developer spends more time fighting the styling system than building the feature, the system has failed its subsidiary role.
• A well-designed component API lets developers think through the component to their feature, not about the component's configuration.

Lens 3: Design Token Hierarchy — From Raw to Meaning

Principle: Design knowledge is organized in layers. Each layer serves as subsidiary to the one above. Each has boundary conditions the layer below cannot determine.

Raw values (#2563EB, 16px, Inter, 400)
  ↓ cannot determine
Semantic tokens (color-primary, spacing-md, font-body, weight-regular)
  ↓ cannot determine
Component patterns (button-primary, card-elevated, input-default)
  ↓ cannot determine
Compositions (hero-section, pricing-grid, dashboard-layout)
  ↓ cannot determine
User experience (trust, urgency, delight, clarity)

Key insight: You cannot derive a good button from good tokens alone. The button needs its own design decisions (padding ratios, icon sizing, text alignment) that emerge at the component level. Tokens provide materials, not design.

Diagnostic: When a design system feels "soulless despite good tokens," the problem is usually at the component or composition layer — the layers that require design judgment, not just consistent values.

Lens 4: Tacit Translation — Feeling to Fix

Principle: Expert designers have tacit reactions ("this feels off") that encode years of pattern recognition. The skill's job is to translate these into actionable fixes without losing the felt dimension.

Translation protocol:

Tacit reaction → Structural cause → Specific fix → Why it matters experientially

Common translations:

Lens 5: Convention Judgment — When to Break Rules

Principle: Rules encode collective tacit knowledge. Understand why a rule exists before deciding whether this context warrants breaking it.

Design rules and their tacit reasons:

Cross-Cutting: Accessibility & Resilience

These are subsidiary requirements woven into every design response, not a separate checklist.

Accessibility as subsidiary design:

• Focus states: 2px outline, offset 2px, high-contrast — structural like having a roof
• Color contrast: WCAG AA (4.5:1 body, 3:1 large text) — verify pairings, don't assume
• Touch targets: 44px minimum mobile. Motion: respect prefers-reduced-motion
• Screen readers: sr-only labels for visual-only indicators (color dots, icon-only buttons)

Resilience as design quality:

• Every data-dependent component needs a skeleton matching content dimensions
• Every list needs an empty state. Every async operation needs an error state
• Slow network: placeholder dashes (—), not spinners

Motion & Animation System

Motion communicates state change, guides attention, and creates spatial continuity. Every animation needs a functional purpose.

Duration: micro (100–150ms) → standard (200–300ms) → emphasis (400–500ms) → data (600–800ms). Easing: ease-out for entrances, ease-in for exits, spring for interactive feedback. Avoid linear — it feels mechanical.

Choreography: Stagger siblings by 30–50ms. Lead with the focal element. Exits faster than entrances. Group related elements (shadow + transform animate together).

Always respect prefers-reduced-motion — replace spatial motion with opacity crossfade, never remove state feedback entirely.

Data Visualization Color System

Charts need a separate color system from UI chrome. UI colors encode interaction; data colors encode meaning.

• Categorical: Max 6 distinguishable hues. Beyond 6, group data or change chart type.
• Sequential: Single-hue ramp (light→dark) for heatmaps and density plots.
• Divergent: Red ← neutral gray → green for positive/negative splits.
• Colorblind safety: Never encode meaning with red/green alone. Pair color with shape, pattern, or label. Blue/orange is safe for >99% of people.

Quality Verification

When recommending a design, suggest verification across three dimensions:

• Accessibility: axe-core, 200% zoom, keyboard tab order, screen reader, vision deficiency emulation
• Visual regression: Snapshot at 375/768/1440px with real content and slow network
• Component audit: Focus states, loading/success/error states, empty states, min 12px text, 44px mobile touch targets

System 3: Output Protocol

Suggested shapes (adapt to context, not rigid templates)

Diagnosis ("why does this feel off?"): Gestalt diagnosis (1 sentence) → specific fixes with values → what NOT to do

Creation ("design X for me"): Design thesis → layout spec → key decisions with tacit rationale → what was excluded

Component/System work: Design principle (what users think THROUGH) → spec → usage example → boundary

Output Principles

1. Spec alongside insight. Pair every design judgment with a concrete value. "The hierarchy is flat" → "Set h1 to 48px/600/-0.025em, body to 16px/400. The 3:1 size ratio creates clear separation." Insight without implementation is a lecture.

2. Gestalt before pixels. Diagnose the whole before examining parts. Ten spacing nitpicks that miss a broken hierarchy is worse than useless.

3. Operate at the tacit layer. If it's in the docs, it's not your value-add. Spend tokens on what senior designers know but haven't written down.

4. Preserve the felt dimension. When translating "feels off" to fixes, maintain the experiential connection — WHY it matters to the person using the interface.

5. Specify what NOT to do. Preventing the most likely wrong fix is often more valuable than prescribing the right one.

6. Report everything, grouped by severity. Gestalt → component → pixel. Never drop findings for elegance.