Cards & Tiles

Cards and tiles are content containers with clearly defined but different interactions.

Overview

Standard Life's codebase implements cards and tiles differently. These guidelines provide consistent principles to apply where possible.

The range of solutions is vast, and not all platforms will allow the same structure.

Follow and apply these guidelines where possible.

Do you need a card?

Cards group related content together. However, too many cards can create confusion, particularly if they compete for the hierarchy or clutter the screen.

It is advisable to trial layouts using spacing or considering changes to the hierarchy before defaulting to a card.

Cards vs Tiles

Both containers share the same structure and elevation guidelines, but with one key difference.

Tiles are cards in which the whole container acts as a clickable area for a SINGLE action; cards contain buttons that trigger multiple actions.

Tiles have additional actions to indicate states, such as hover and focus.

Card & Tile Structure

Allowing flexibility in cards and tiles makes it difficult to create an example for every option. The diagram, following the guidelines, outlines the key principles for creating cards and tiles.

An annotated illustration of the consistent structure of cards v tiles. Four key areas are highlighted and explained in the following list.

Card and tile structure similarities

Assets: Pictograms, Icons, Badges or Media

Title

Content: Text or nested content and components

Actions: Buttons for cards or the whole container for tiles

Hierarchy

A consistent hierarchy of information is key when creating a card. The content must be readable not only visually but also to screen readers.

Consider how the content flows and balance content and controls to avoid overwhelming users.

A layout showing the cards and tiles similarities

Example of a basic card and tile in React Native.

The hierarchy of a card or tile should be consistent to create familiarity for the users.

Icons, Pictograms, Badges and Media should use the appropriate accessibility labels

Keep titles clear and concise

Content and components can sit within the body of the card as required

Button Groups should always be last in the hierarchy for cards; they do not appear in tiles

Tokens

Cards and tiles should not use any other surface colours

There are component-level design tokens specifically designed to style cards and tiles; these include.

The component-level design tokens for card-* are also used on tiles as they share the same basic structure.

Surface Colour

Title Text

Border

Border Radius

Inner padding

Titles

Cards and tiles can appear in various locations on the page, and the correct markup (e.g., h1, h2) should be used to create a structured hierarchy.

If the visual style needs to be a different size, you can adjust it using a text class or prop.


                                                        
                                                        
                                                            <div class="co-card">
                                                        <h2 class="co-heading-6xl co-card-title">Card Title</h2>
                                                        ...
                                                        </div>

HTML example of a card using classes to style the heading markup

Padding & Radius

The inner padding should always use the space/card/x space/card/y token, except for images, which will likely touch three edges.

This inner padding remains constant across all breakpoints; it does not increase as the card’s overall width increases.

The token border-radius/card/base sets the card’s border radius.

Mockups of a card showing the internal spacing and radius

Web card showing the tokens used for spacing and radius

Media

When media is used within a card, it should touch three sides with no inner padding. The media can be placed on the edge that suits.

Two card layouts displaying that the media (images) go directly to the edges on three sides

Headings

Font size can be used to visually represent hierarchy. All cards in a collection should use the same font sizes for consistency.

Colour

Cards have a dedicated surface colour, colors/surface / card. Using a single surface colour allows a broader range of components to be nested within the body area.

Elevation

Elevated cards will be phased out in 2026, cards will sit on surfaces with no shadow

Cards appear on different surfaces within a page; use the correct surface based on context.

Nested cards that appear on the default surface and are best used when highlighting supporting information alongside longer content

Elevated cards are typically used when several cards are used in a single interface, such as a dashboard, and appear on an alternate surface

It is essential to apply the correct elevation guidelines when working with depth in UI components.

Nested Cards	Elevated Cards
These cards sit at the same page level and therefore do not require a shadow. Cards have a border line to separate the group from the page.	Elevated cards sit above the alternate surface and require a shadow because they are closer to the screen.
Background colour: Base Surface Shadow: No	Background Colour: Alternate Surfaces Shadow: Yes

Alignment

Collections should have consistent alignment of child elements. The tallest card or tile determines the overall height of the collection.

Align button groups to the bottom of each element.

Designers choose the spacing between cards, but follow the space/1 (8px) soft grid; the suggested minimum is space/2 (16px).

The example above shows how the type scale and weight depict hierarchy. Compositions vary, but use the type styles available to describe the appropriate hierarchy in any custom cards.

Layout of two cards in a collection with consistent titles and alignment

A collection of cards with different title lengths but consistent alignment