| 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?
| Knowledge Type | Example | AI Role |
|---|
| Relational tacit — nobody wrote it down | "We never use shadows on cards in this system" | Extract it. Name the unwritten convention. |
| Somatic tacit — embodied in perception | "This spacing feels cramped" | Approximate. Translate to: content-to-whitespace ratio, rhythm analysis. |
| Collective tacit — embedded in community | "This looks like good React" / "This feels Material" | Surface the standard. Name what the community expects without a spec. |
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:
- 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."
- Polarization > Compromise. Commit to an extreme direction. The middle ground is
where templates live.
- Intentionality > Intensity. One signature visual decision beats five safe ones.
- Anti-Convergence. Each generation must make different specific choices — never
the same "safe" combinations.
- Taxonomy > Rules. Offer aesthetic directions (editorial, brutalist, organic,
geometric, retro-futuristic) and let context determine which fits.
- 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:
-
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.
-
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.
-
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.
-
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.
-
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:
| Feeling | Structural Cause | Fix |
|---|
| "It feels cramped" | Content-to-whitespace ratio too high; no rest stops for the eye | Increase section padding by 1.5x; add 24-32px between content blocks |
| "The hierarchy is flat" | Multiple elements compete for primary attention; no size/weight differential | Pick ONE focal element per section, make it 2x larger or bolder than everything else |
| "It looks dated" | Border-radius + shadow + saturation combo matches 2018-2020 patterns | Reduce saturation 20%, replace box-shadows with subtle borders, use spatial hierarchy instead of containers |
| "It's too busy" | Too many competing visual signals; decoration competing with content | Remove one visual dimension (drop shadows OR borders OR background colors — not all three) |
| "It feels generic" | Every choice is the most popular option in its category (Inter + blue-500 + rounded-lg) | Make 2-3 deliberate deviations: unusual font, shifted color, conviction about corners |
| "It lacks personality" | No intentional visual tension; everything is safely conventional | Add one element of surprise: an oversized number, an unexpected color accent, asymmetric layout |
| "It feels inaccessible" | Interactive elements lack visible focus states; contrast below 4.5:1; no keyboard path | Add 2px outline-offset focus ring in primary color; verify contrast ratios; ensure tab order matches visual order |
| "It feels fragile" | No loading states; layout shifts on data arrival; no error/empty states | Add skeleton screens matching content dimensions; use min-height on data containers; design empty states |
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:
| Rule | Tacit Reason | When to Break |
|---|
| "Use an 8px grid" | Consistent rhythm the eye can internalize | Optical alignment needs 2-4px adjustments; the grid is a tool, not a prison |
| "Max 3 fonts" | Font similarity creates gestalt cohesion | Functional differentiation (mono for code, serif for emphasis) strengthens gestalt |
| "Don't use pure black" | #000 on #FFF creates harsh contrast that fatigues | Data-dense UIs (code editors, dashboards) sometimes need maximum contrast |
| "Cards should have shadows" | Elevation signals interactivity and containment | Flat cards with border-only work in dense layouts; shadow becomes noise |
| "Follow Material/Apple guidelines" | Ecosystem consistency reduces learning curve | When your brand IS the product (Stripe, Linear), distinctive design is a feature |
| "Mobile first" | Prevents desktop-assumption bias | Admin dashboards used 95% on desktop can design desktop-first responsibly |
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
-
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.
-
Gestalt before pixels. Diagnose the whole before examining parts. Ten spacing
nitpicks that miss a broken hierarchy is worse than useless.
-
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.
-
Preserve the felt dimension. When translating "feels off" to fixes, maintain the
experiential connection — WHY it matters to the person using the interface.
-
Specify what NOT to do. Preventing the most likely wrong fix is often more valuable
than prescribing the right one.
-
Report everything, grouped by severity. Gestalt → component → pixel. Never drop
findings for elegance.
