Right-Sizing the Rectangles

Grappling with Hierarchy for a More Effective Design System

Nathan Curtis
Mar 14, 2016 · 6 min read

#1. Components Are Hierarchical, Containing Other Components

Beginners see pages as a two-dimensional construct displayed on screen. That’s why the activities like the Component Cut-Up are so effective. Soon, designers (using a light source) and developers (via z-index) develop a more nuanced appreciation for depth, unflattening elements into a third dimension.

#2. Build & Encapsulate Small Components

A library must have a sufficient quantity of bite-sized components — Button, Textbox, Tag, Checkbox, Breadcrumb, Modal, even Cards — to be minimally useful and adoptable. Let’s say you need ~10 to 20, including at least Button (with lots of variations), Forms, and a few others depending on the system’s context.

Encapsulate the Small Components

Modern front-end tooling—like CSS preprocessor mixins and template partials and macros—help us encapsulate the definition of and interface to small components.

Encapsulation Makes Things Complicated

But encapsulation is a challenge for library makers. Where do properties go? Will CSS classes of smaller components be integrated into or encapsulated within the classes of larger ones containing them? How can ensure larger components are resilient to changes in their reusable smaller parts? My emotions are mixed: Encapsulation is required to scale a library, but increases complexity, lengthens conversations, and requires thoughtful planning. Practicing effective encapsulation is far from free.

#3. Offer Important Big Components, Too

The more atomic a part, the more likely it’ll be broadly reused, correctly, at a small cost to the system. However, this doesn’t mean system can’t also offer big components like a “Hero Carousel” banner, a Toolbar with varied menus, icons, and buttons, or—if you’re serious about bringing products together—a Header system (possibly including panels like Megamenus that may span products).

More Complex=More Expensive=More Likely to be Inconsistent. Some of These Matter. A lot.

Big components — Heroes, Toolbars, and especially Header Bars — are essential for making a broad experience cohesive. Yet these components are complex beasts, particularly responsively, as measured by overflowing lines of markup and style.

Big Components Reveal Seams

A library lacking big components risks looking like a muddled mess when things are put together. Larger components provide inspectable examples of both visually and in code. You can see how small things fit in big things, learning how to apply spacing, color, variable names and themes along the way.

#4. Grids are Components, Not Layouts

The parts on a page are all composed in a the hierarchical journey, from the most atomic element all the way up to the body tag.

A Grid is a Component

Most libraries offer a Grid defined as (more often now) rows containing columns down a scrollable page. The Grid has many hallmarks of a component, in that a grid is:

  • A predictable array of variations (1/4 wide, 2/3 wide, etc).
  • Hierarchical, with a row contains column contains row contains column.
  • Markup encoded with styles, managed and adjusted over time.
  • A container of while also often contained in other components.

Grid ≠ Overall Layout.

That said, a Grid never the top-most component that contains everything else. It’s an intermediate component sandwiched between the smaller parts and often one of a few likely Layouts.

#5. Users Value Assembled Shells

When library users approach a library, they can be overwhelmed by the vast ocean of atomic choices. A library’s breadth of parts is correlated with its perceived worth. However, another key question is:

Offer Prebuilt Shells that Include Big Components

That’s not “the grid” and it’s more complex than just a layout of empty regions. We’ll often offer a page Shell as a prearranged layout that already contains a Header, Global Navigation, and possibly Footer and other Paneling.


A collection of stories, studies, and deep thinking from EightShapes

Nathan Curtis

Written by

Founder of UX firm @eightshapes. Speaker. Writer. Fan of Arsenal, Hokies. Cyclist & runner. Father & husband. VT & @uchicago grad.


A collection of stories, studies, and deep thinking from EightShapes