Card

What a card organizes in a SaaS interface

A card groups related information into a distinct unit. It can summarize a plan, feature, record, article, or workflow, often with an associated action. The pattern is useful when readers need to compare repeated objects or recognize where one subject ends and another begins. Its value comes from the relationship among its contents, rather than the presence of a border or rounded corner.

Start by identifying the object the card represents. A plan card organizes a commercial option; a feature card organizes a capability; a record card organizes an item of work. These uses need different fields and interaction rules. Applying the same generic image-title-button template to all of them can obscure the information that makes each object meaningful.

A good card has a clear reading order and a predictable action model. Readers should know what it represents, which details matter, and what happens if they activate it. If the card contains several controls, those controls should have distinct purposes. If it is purely informational, its visual treatment should not imply an unavailable interaction.

Use cards to distinguish comparable options

Dust's captured subscription page presents Pro and Enterprise as neighboring plan cards. Each card has its own label, commercial framing, action, and included capabilities. The layout makes the options recognizable as separate choices while keeping them available for comparison in one view.

The actions differ: the Pro route is a direct subscription path, while Enterprise points toward a sales conversation. This is more informative than repeating the same generic button under both cards. It acknowledges that the options have different acquisition models. Read the captured amounts as historical content rather than current pricing.

For comparable cards, align the fields that users need to compare. A plan's price basis, capacity, and main distinction should occupy predictable positions. Avoid making one option appear superior merely because its content pushes the action higher or its description happens to be shorter. The design should clarify the comparison rather than introduce accidental emphasis.

Use cards to explain distinct capabilities

Base44's captured enterprise page includes three feature cards for version history, shared project workspaces, and lifecycle management. Each has a short title and a concise explanation. Elsewhere, larger paired sections combine copy with a visual preview. The page therefore uses different grouping scales for different amounts of information.

The three smaller cards are useful as a set because they represent distinct capabilities within a broader collaboration story. They are not simply three differently worded statements of the same benefit. A comparable design should give each card a specific subject and enough explanation to distinguish it from its neighbors.

The screenshot does not establish whether these cards are clickable. Do not infer interaction from their shape alone. If adapting an informational set into navigation, add a clear destination and review its accessible behavior. If the cards remain summaries, keep the visual language focused on grouping and reading rather than suggesting hidden actions.

Build a hierarchy around the object's important fields

A card's hierarchy should reflect the task. For a project record, identity and status may matter first. For a plan, the option and commercial basis may be central. For an article, title and topic may matter more than a decorative image. Choose fields deliberately instead of including every available property.

Separate primary, supporting, and metadata content. A short title identifies the object; a description explains relevance; status or category supplies context; an action offers a next step. When all elements have equal visual weight, the card becomes a small undifferentiated page. Use spacing and typography to reveal the relationship without excessive ornament.

Check the card with realistic content variations. Long titles, missing images, additional metadata, and empty descriptions should not destroy its structure. Avoid relying on manually edited content lengths to make a reusable component appear consistent. Define what can wrap, what can be omitted, and what must remain visible.

Choose a clear interaction model

A card can be a single destination, a container with separate actions, or a passive summary. Make that choice explicit. If the whole card opens a record, users should be able to identify and activate the destination consistently. If it contains a menu, selection control, or secondary link, those actions should not accidentally trigger the primary destination.

Use a direct action label when the consequence needs explanation. “Subscribe” and “Contact sales” communicate different next steps in Dust's capture. A vague “Learn more” can be appropriate for an informational destination, but it is less useful when several cards lead to materially different actions.

Review keyboard focus and accessible naming. A card with several links should not create redundant or confusing stops. A clickable surface should have a meaningful destination label, not a long announcement of every decorative detail inside it. The correct implementation depends on its interaction model, so define that model before writing component behavior.

Use images and decoration according to their role

An image can help identify an object, show product evidence, or establish an editorial topic. It can also consume space without improving understanding. Decide what the image contributes and whether it is required for recognition. A plan card often needs readable comparison more than a large decorative thumbnail.

Base44's smaller capability cards use a restrained colored treatment rather than a detailed screenshot in each one. Larger sections provide more substantial visual context. This illustrates a useful distribution of attention: concise summaries remain concise, while content that benefits from a preview gets a larger surface.

Keep decoration consistent with interaction. A strong hover treatment on a passive summary can imply clickability. An oversized gradient can make supporting content look like the primary message. Review the card at its actual size, including thumbnails and mobile variants, so borders, backgrounds, and media support the hierarchy rather than compete with it.

Design repeated cards as a collection

Cards rarely exist alone. A grid or list introduces questions about order, alignment, density, and comparison. Choose an arrangement around how users browse. A uniform grid can support scanning across similar objects. A list may better support detailed comparison or long names. A visually varied layout may emphasize editorial priorities but make systematic comparison harder.

Do not force equal heights by hiding important information. Sometimes aligned actions improve comparison; sometimes natural height makes longer descriptions easier to read. Define which relationship matters. For a plan comparison, consistent positions can help; for a feed of varied articles, overly rigid dimensions may create unnecessary truncation.

Consider how the collection behaves with one item, a few items, and many items. Filtering, sorting, pagination, and empty states should preserve the meaning of the cards. If the user selects cards for a bulk action, show selection separately from hover or active navigation so the state remains understandable.

Adapt content order to narrow screens

A desktop row often becomes a vertical stack on a phone. The order can then imply priority more strongly than the horizontal arrangement did. Review which card appears first and whether the sequence supports the page's purpose. Preserve key comparison details when options move farther apart.

Keep actions reachable without making every card excessively tall. Text should wrap naturally, and important metadata should not disappear behind a fixed-height crop. If images change aspect ratio, preserve their relevant content. A card that looks balanced on desktop can become a long block of decoration before the actual explanation appears.

The supplied captures show desktop compositions, not responsive behavior. Test narrow widths, text enlargement, translated titles, and missing content separately. Review spacing between cards as well as within them. Users should still be able to distinguish the collection's objects and understand which action belongs to which card.

Handle loading, empty, and unavailable states

A reusable card system needs more than its filled state. While data loads, reserve appropriate space and avoid placeholders that look like actual values. If one image fails, retain identity and action where possible. If a record becomes unavailable, explain that state rather than leaving a card that appears active but opens an error.

For selectable or editable cards, show pending changes clearly. A status should not appear complete until the underlying action succeeds. Preserve user context if a card updates position after sorting or filtering. Abrupt movement can make it difficult to locate the item just changed.

Define empty collection states separately from empty fields within a card. No search results requires a different explanation from a missing description on an existing record. The interface should offer an appropriate next step, such as adjusting a filter, creating an item, or returning to another view.

Evaluate recognition, comparison, and action

Test the task the card collection supports. Ask users to find an item, compare two options, explain a feature, or predict the next step after activation. Observe whether they click decorative areas, overlook metadata, or mistake one action for another. These findings reveal hierarchy and interaction problems more directly than a preference comparison.

Maintain field definitions and content conventions alongside the component. A plan card and a record card may share spacing and typography while requiring different structures. Document those differences so future screens do not accumulate unnecessary fields or inconsistent action rules.

Use this checklist:

• Each card represents a clear object or subject.
• Fields and hierarchy support the intended task.
• Comparable information occupies predictable positions.
• The interaction model is explicit and consistent.
• Secondary controls do not conflict with the primary action.
• Media and decoration have a useful role.
• The collection works across item counts and content variations.
• Narrow, enlarged-text, loading, and unavailable states are reviewed.
• Evaluation tests recognition, comparison, and the resulting action.

Frequently asked questions about card patterns

Should the whole card be clickable?

Only when the card has one clear primary destination and the implementation supports it accessibly. A card with multiple actions needs a more explicit structure. Avoid nested controls that accidentally activate the main destination or create confusing keyboard stops.

Should every card in a grid have the same height?

Use consistent height when alignment helps comparison, but do not hide meaningful content to achieve it. Define how titles and descriptions vary. Some collections work better with natural height, while others benefit from aligned fields and actions.

When should a list replace cards?

Use a list or table when users need dense comparison, repeated metadata, or efficient scanning across many records. Cards work well when objects need more visual separation or richer summaries. Choose the structure around the task rather than using cards as a universal container.

Explore the SaaSFrame card examples to compare plan options, capability summaries, and repeated content containers across SaaS designs.