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: quick navigation and content management.

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 in seconds.

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

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.

Tile - size and content options

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 anatomy

I designed every state from default through disabled, across light and dark themes - detailed enough for pixel-perfect implementation without back-and-forth with engineering.

Tile component - all states across light and dark themes

Tile states, sub-components, and size variants

In production, Tile became the default pattern for dashboard navigation and scaled into secondary contexts like modal flows.

Tile in production - dashboard navigation

Large Tile variant in production

Tile in dialog context

Card component

Cards needed the opposite approach: a deliberately inert body where users can scan rich content without accidentally triggering actions.

Card - size and content options

All actions are scoped to a dedicated toolbar, making it clear where to act. This prevents accidental triggers when users are scanning dense content.

Card anatomy

Multi-selection - a pattern I designed specifically for Cards. When activated, checkboxes appear on each card and batch actions replace individual toolbars. This reinforced 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 configurations across product contexts

Card in production - vertical and horizontal configurations

Card component in a file management interface

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

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

Outcomes & Reflection

Explore more projects