Architecture
Shape Architecture — Synthesis
Overview
Shape in a design system is almost exclusively about border radius. It is one of the few visual dimensions that operates as a continuous personality dial — from sharp/precise at one end to rounded/approachable at the other — with no inherent functional meaning. This makes it both powerful and easy to misuse.
Border radius as a personality signal
The border radius scale positions a product on a spectrum that users read as personality, not function:
| Radius level | Character | Communicates |
|---|---|---|
| 0px (sharp) | Precise, formal, architectural | Technical tools, financial platforms, enterprise software |
| 2–4px (very slight) | Grounded, professional | Most business software; serious without being cold |
| 8–12px (moderate) | Friendly, approachable | Consumer products, productivity apps, developer tools |
| 16–24px (pronounced) | Warm, modern, expressive | Social products, creative tools, B2C |
| Full/pill | Playful, inviting, mobile-native | Interactive actions, badges, tags; used sparingly at system level |
This is not a rule — it is a communication framework. Sharp edges in a healthcare app read differently than sharp edges in a code editor; the product context modifies the signal. But the underlying dimension is real: rounding communicates warmth and approachability; sharpness communicates precision and seriousness.
The practical implication: choose a radius level as a product character decision, before designing individual components. Then hold to it consistently. A product that mixes 0px cards with 16px buttons sends conflicting signals — not because either value is wrong, but because they suggest different personalities.
Scale approaches
Named scale (semantic)
Define a small number of named radius tiers and assign components to tiers:
none → 0px
small → 4px
medium → 8px
large → 16px
full → 9999px (pill)
Why named tiers work: They enforce a limited vocabulary. When a new component needs a radius, the designer or developer picks the tier that matches the component's purpose — not the pixel value that looks right to them. This makes the scale teachable and auditable.
How to name tiers: Name for role, not size. radius-interactive for buttons and inputs, radius-container for cards and dialogs, radius-subtle for small inline elements, radius-pill for badges and tags. Role-based names survive visual changes; size-based names (radius-small, radius-medium) become misleading when values change.
Numeric scale (steps)
A 4–6 step numeric scale (1 through N) where each step is a specific pixel value. Components consume step numbers rather than semantic names.
Works well for library systems where consumers compose freely. Has the same composability tradeoff as numeric type scales: no communication of purpose, but maximum flexibility. More suitable for a component library than a prescriptive product system.
Global factor
A single theme-level setting that recalculates all component radii proportionally (Radix's radius prop: none / small / medium / large / full). Extremely simple to use — one knob controls the whole product.
Tradeoff: Some components should not round fully even when the system-level setting is full. A checkbox should never become a circle (visual confusion with radio buttons); a data table cell should not have individual rounded corners. The global factor approach requires component-level exceptions, which defeats some of its simplicity.
Component consistency
Components within the same family should share a radius tier. A button family (filled, outlined, ghost) that mixes 8px, 4px, and 0px radii reads as incoherent. The different variants express emphasis through fill and border, not through shape.
Size variants of the same component should scale radius proportionally. A small button and a large button with the same 8px radius will look different — the small button appears more rounded relative to its height. Either scale the radius with the component size (small: 4px, large: 8px) or accept that the larger variant will look more subtle.
Surface containers (cards, panels, modals) usually warrant a higher-radius tier than small interactive elements. A large container with the same radius as a chip looks proportionally different. Cards typically warrant medium-to-large radius; small badges and chips use small-to-medium.
The exception: data components. Tables, grids, code blocks, and data lists are typically none or small regardless of the system's overall personality. Sharp edges communicate structure and precision in data contexts even in an otherwise rounded system.
The pill (full radius) — using sparingly vs. as a default
Used sparingly: Pill shapes are high-emphasis signals. They draw the eye. When used selectively — primary action buttons, badges, tag pills — they indicate "this is important and interactive." When overused, the signal disappears.
As a system default: Some systems (particularly mobile-native and consumer products) use full radius as the default for all interactive elements. This creates a consistent, approachable feel but loses the distinction pill shapes usually carry.
The middle path: Use pill shapes for badges, tags, and selection chips (where the pill shape is the category convention); use moderate radius for interactive buttons and inputs; use larger-but-not-full radius for prominent CTAs.
Never full-radius: Data table cells, code blocks, image containers (distorts the image crop), and form fields in dense layouts.