--- category: principles topic: shape-architecture content_type: synthesis status: latest retrieved: 2026-05-13 tags: [shape, border-radius, personality, tokens, components, synthesis] sources: - kb/reference/design-systems/material/guidance/foundations/shape - kb/reference/design-systems/radix/guidance/foundations/radius - kb/reference/design-systems/atlassian/guidance/foundations/design-tokens --- # 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.