Tile & Card Guidelines

Challenge

Over 20 designers across multiple products were solving the same UI pattern differently, building their own versions of components with no consistency or documentation.

Role

End-to-end ownership: research across 6 designers and 9 products, component design, guidelines authoring, and engineering handoff.

Design Systems UX Research Interaction Design

Impact

Reduced container component variants to 2 standardized components, adopted across all 9 products. Gave every team a shared framework that cut design review debates around container patterns.

Duration

8 months

Discovery

Interviews and a product audit revealed that teams weren't just using one pattern inconsistently - they were solving two fundamentally different problems - navigation and content management purposes.

Some earlier drafts existed in the design system, but they hadn't addressed this split, which is why adoption never stuck. One component couldn't cover both needs.

The research pointed to two distinct interaction models, so I proposed two separate components instead of one configurable one - Tile and Card - each with a clear use case and boundaries. To make the choice effortless, I built a comparison matrix so any designer could pick the right component.

Criteria	Tile	Card
Primary intent	Navigate to content	Display and act on content
Click target	Entire surface	Toolbar actions only
Content density	Brief - 2–3 lines	Rich - no hard limit
Action count	One (+ optional IconButton)	Multiple (Buttons, Links, Toolbar)
Multi-selection	Not supported	Supported
Best for	Dashboards, navigation grids, app launchers	Data management, download portals, project lists

Scroll to explore

Tile component

A Tile is designed for quick navigation - the entire surface is a single click target. It gives users a fast, scannable entry point without pulling attention into the content itself.

Hover activates the whole Tile, not individual elements inside it, so users never have to guess where to click. An optional IconButton allows a secondary action without breaking the whole-surface model.

Tile - size and state options

In production, Tile became the default pattern for dashboard navigation and scaled into larger entry points and dialog flows.

Tile in production - dashboard navigation

Large Tile variant in production

Tiles in dialog context

Card component

Cards needed the opposite approach: a non-clickable body where users can scan rich content freely and reach primary, secondary or multi-select actions only through a dedicated toolbar.

Card - size and content options

When the Multi-selection Card pattern is activated, checkboxes appear on each card and batch actions replace individual toolbars. This was one of the main reinforcements to the component split - multi-selection is a content management behavior, not a navigation one.

Multi-selection: before and after activation

Teams adopted Card for data-heavy workflows - vertical and horizontal configurations across content management, download portals, and project lists.

Card component in a file management interface

Card in production - file management with list view and details panel

Tile and Card together

Both components working side by side in the same interface - Tile handling navigation, Card managing content.

Tile and Card components used together in a product interface

Tile and Card side by side in a dashboard layout

Tile and Card components in another product context

Another production example of Tile and Card side by side in a dashboard layout

Outcomes & Reflection

Results

Two standardized components adopted across all 9 products, replacing fragmented one-off implementations
Shared decision framework - designers pick the right component without a conversation
Interaction-first approach to component design adopted for future system additions

What I learned

Starting from behavior, not visual anatomy, was the right call. Defining what each component does before how it looks gave the system a logic teams could internalize rather than memorize. Running discovery with designers first prevented major revision cycles that would have delayed the project.

What I would do differently

I would involve engineering earlier. Bringing developers into the conversation while the components were still being shaped, not after handoff, would have surfaced implementation constraints sooner and made the rollout smoother.

Discovery

Tile component

Card component

Tile and Card together

Outcomes & Reflection

Explore more projects