Cards Are Everywhere. Most of Them Shouldn’t Be.
Open any Figma template, any Webflow theme, any WordPress page builder. Cards. Cards for services, cards for testimonials, cards for blog posts, cards for FAQ items, cards for navigation links, cards for the footer. Everything bounded, everything elevated, everything equal.
That last word is the problem. When every piece of content on a page lives inside a card, every piece of content has equal visual weight. Equal weight means no hierarchy. No hierarchy means the user’s eye has nowhere to go, nothing to prioritise, no path through the page.
Cards are the most overused and least thought-about pattern in web design. Not because they’re bad — they’re genuinely useful in specific contexts. But because they’ve been adopted as the default answer to “how do I display content?” rather than as one specific tool for one specific job.
The job of a card is to group related information about a single subject into a bounded, comparable unit. That’s it. When the content fits that definition, cards excel. When it doesn’t, you’re forcing content into a container that was never meant for it.
What a Card Actually Is
A card is a bounded container that groups related information about a single subject. The operative phrase is single subject.
A team member card: photo, name, title, two-sentence bio, LinkedIn link. Everything in that card is about one person. The boundary is meaningful — it says “this is one person’s information.”
A service card that tries to contain: service name, 3-sentence description, pricing tier, feature list, FAQ question, and a CTA button — that is not a card. That is a landing page section that someone decided to put a border around. The boundary is not meaningful; it’s decorative.
This is the most common card mistake: mistaking “grouped content” for “any content placed together.” Grouping content in a card implies the content is a single coherent unit that stands alone. If the content requires other sections to be understood, or if it’s too deep to be scanned quickly, it’s not card content.
When Cards Are the Right Pattern
Parallel Comparable Items
This is the canonical use case for cards, and the one they’re best at. Product listings: image, product name, price, rating, add-to-cart button. Every card carries the same information structure. Users can scan across cards horizontally and compare — price vs. price, name vs. name, rating vs. rating.
The key requirement: the items must be genuinely parallel. Same type of information at the same level of depth. When cards are parallel, they facilitate comparison. When they’re not parallel, they create visual inconsistency that undermines the comparison.
Other examples that work: team members (all have photos, names, titles, short bios), article previews (all have headline image, title, excerpt, date), portfolio pieces (all have project image, name, category, brief description).
Mixed Content in a Structured Feed
Social feeds use cards effectively because each post has different content but the same structural container. The card gives visual consistency to variable content — you always know where the author, text, and actions are, even when the content itself changes. The structure is consistent; the content varies.
This works because the card’s job is to say “this is one post” — and every post is genuinely one discrete unit.
Scannable Browsing Contexts
Users exploring product catalogues, article archives, or portfolio galleries are browsing, not reading. They’re making rapid binary decisions — “relevant or not relevant?” — before committing to a deeper look. Cards support this non-linear, browse-and-select behaviour because each card gives enough information to make a quick judgment without requiring a full read.
If users are expected to read content linearly (a how-to guide, a case study), cards are the wrong pattern for the main content.
Dashboard Metric Cards
Metric cards — a single large number + label + directional trend indicator — are purpose-built for dashboards, and they work extremely well. The content is genuinely bounded (one metric), comparable (each card is one metric), and scannable (users don’t read dashboards, they scan them).
When Cards Fail
Sequential Content That Requires Linear Reading
A how-to guide divided into five cards. The problem: cards imply parallelism and comparability. They suggest you can read them in any order and the content is independently meaningful. A step-by-step process is exactly the opposite — each step depends on the previous, sequence is mandatory, and the content is not independently meaningful.
Forcing this into cards loses the narrative thread. Users don’t know which card to read first. The visual structure fights the content’s logic. A numbered list or a single article flow serves this content far better.
Content of Wildly Different Depth
One card with 20 words. The next with 200 words. One card with no image. The next with a full-bleed photo.
In a card grid, either all cards expand to the height of the tallest (creating vast white space in shorter cards), or content is truncated (losing meaning). Both outcomes are worse than not using cards. If your content units have genuinely different depths, they’re not parallel — and cards require parallelism to function.
Non-Comparable Content
If users don’t need to compare items, cards add visual structure without adding navigational value.
A page listing five company values doesn’t need cards. The values are not being compared — they’re being communicated. A heading + paragraph for each value, in a single-column flow, communicates just as well with less visual noise.
A FAQ page is not card content. FAQ items are not parallel comparable units — they’re answers to different questions at different depths. An accordion serves the user better: it shows all questions at once (scannability), expands only the relevant answer (focus), and adds no visual clutter.
”Card Everything” Syndrome
When the entire page is cards — hero card, navigation cards, content section cards, testimonial cards, footer cards — the hierarchy disappears. The page reads as a uniform grid of boxes, and the user has no signal about what matters most, what to do first, or where they are in the page structure.
Cards are meant to stand out from the page. When everything is a card, nothing stands out.
Card Anatomy — What to Include and Why
Every element added to a card increases cognitive load. Include only what serves the user’s task in that specific context.
| Element | Include when | Exclude when |
|---|---|---|
| Image | Visual recognition matters (products, people, articles) | Content is abstract or text-first (settings, notifications) |
| Label / tag | Cards span multiple categories; users need to orient | Single-category list; tag adds no filtering value |
| Title | Always — it’s the primary subject identifier | Never |
| Body text | A preview is useful (article excerpt, product description) | Content is fully conveyed by title alone |
| Action / CTA | Card represents a specific available action | Card is purely informational with no available action |
| Metadata (date, author, price) | Metadata is part of the comparison (price comparison, recency) | Metadata is noise in this context |
Body text in cards: maximum 2–3 lines. Always truncate with ellipsis if longer. Never show full body text in a card — if users need the full text, the card should link to the full content, not contain it.
Depth Signals — Shadow, Border, Background
A card’s visual depth treatment tells the user how to interpret it. These are not aesthetic choices — they’re functional signals.
Drop shadow signals that the card is elevated above the page surface. It reads as interactive and “liftable.” Hover states that increase the shadow reinforce this — the card can be “picked up” (clicked).
- Small shadow
(0 2px 8px rgba(0,0,0,0.08)): subtle, refined. Most professional contexts. - Medium shadow
(0 4px 16px rgba(0,0,0,0.12)): noticeably elevated. High-contrast environments. - Large shadow: prominent, marketing-focused. Landing pages, hero sections.
Border signals a boundary without implying elevation. Use when the background provides insufficient contrast to separate the card visually. 1px solid rgba(0,0,0,0.08) is usually enough — visible but unobtrusive.
Background change is the subtlest separation. White card on an #F5F5F5 page background is a classic, clean approach. Requires sufficient contrast — white on white is invisible.
The rule: choose one method and apply it consistently. Every card on the page should use the same depth treatment. Mixing shadows on some cards, borders on others, and plain backgrounds on a third group within the same section reads as unresolved design. The user’s perceptual system looks for patterns; inconsistency breaks the pattern without reason.
Border-Radius — It Carries More Meaning Than You Think
Border-radius is a personality signal. It tells the user something about the brand’s character before they read a word.
| Radius | Visual character | Appropriate contexts |
|---|---|---|
| 0px | Sharp, precise, formal | Finance, legal, data tools, enterprise |
| 4–8px | Subtle rounding, modern professional | Most B2B, professional services, SaaS |
| 12–16px | Noticeably rounded, approachable | Consumer products, health, education |
| 20–24px | Friendly, casual, playful | Lifestyle, wellness, consumer apps |
| 9999px (pill) | Extremely casual / badge-like | Tags, status badges — not content cards |
The consistency rule applies absolutely here. All content cards on the same page or across the same product should use the same border-radius value. Mixing 4px cards with 16px cards on the same page creates a visual inconsistency that signals the page wasn’t designed — it was assembled.
Mobile Card Behaviour
Full-width single column is the default and almost always correct for mobile below 480px viewport width. Forces the user’s attention to one card at a time. Reading comfort is maximised when the card occupies the full available width.
Horizontal scroll carousel works for 4+ similar items where horizontal browsing is intentional (category filters, featured product row, app screenshots). Always signal scrollability with a partial card peek on the right edge — never hide the existence of more cards.
The common mistake: 2-column card grid below 480px. On a 375px viewport, two-column layout gives each card approximately 175px of width after gutters. That’s too narrow for a card title, any body text, and an image to coexist comfortably. Text either wraps awkwardly or truncates too early. Go single column below 480px without exception.
Card Pattern Decision Table
| Content type | Use cards? | Better alternative |
|---|---|---|
| Product listings (comparable items) | Yes | — |
| Article / blog previews | Yes | — |
| Linear how-to steps | No | Numbered list, accordion |
| Dashboard metrics | Yes (metric cards) | — |
| Service descriptions | Depends on depth | Section headings + paragraphs if content varies |
| Team members (photo + bio) | Yes | — |
| FAQ items | No | Accordion |
| Navigation links | No | Navigation list or menu |
| Company values | No | Heading + paragraph flow |
| Testimonials / quotes | Yes (with constraint) | Horizontal scroll or single featured quote |
| Pricing tiers | Yes (feature comparison) | — |
One Useful Test
Before committing to cards for a content section, ask: “Do users need to compare these items, or do they need to understand each item individually?”
If the answer is compare — cards. If the answer is understand — probably not cards.
A product page listing options at different price points: users compare. Cards.
A page explaining your company’s design process in five phases: users understand each phase sequentially. Not cards.
The question takes 10 seconds and saves hours of fighting with misaligned card heights and truncated content.
Need a UI system designed with the right components for your project? Free consultation →
References
- Nielsen Norman Group. “Cards: UI-Component Definition.” https://www.nngroup.com/articles/cards-component/
- Material Design 3. “Cards.” https://m3.material.io/components/cards/overview
- Shopify Polaris. “Card component.” https://polaris-react.shopify.com/components/layout-and-structure/card
- Prokhorova, A. (2020). “8 best practices for UI card design.” UX Collective.
- Justinmind. “Card UI design: fundamentals and examples.” https://www.justinmind.com/ui-design/cards
Card Design — Common Questions
Should I use cards for my services page?
Depends on what your services look like. If each service is 2–3 sentences and comparable in scope, cards work. If each service has a different depth — one needs a paragraph, one needs a numbered process, one needs pricing tiers — cards will force awkward content truncation or create inconsistent heights. In that case, section headings with paragraphs or an accordion serve users better.
How many cards per row is optimal on desktop?
Three columns is the most common and generally the most effective for comparable content (products, services, team members). Two columns works well for content-heavy cards (article previews, case studies) where reading comfort matters. Four columns is viable for minimal cards (metrics, category links). Five or more columns on standard desktop widths (1280–1440px) makes individual cards too narrow to read comfortably.
Do cards hurt SEO?
Cards themselves are neutral for SEO — what matters is the markup inside them. Ensure card titles use appropriate heading tags (h2 or h3, not just bold text). Ensure card links are proper anchor tags with descriptive text. Lazy-loaded card images need explicit width/height attributes to avoid layout shift that harms Core Web Vitals scores.
When should I use a card vs. a list item?
Cards when content has visual weight that justifies the container — an image, multiple data points, an action button. List items when content is primarily text and the relationship between items is more important than each item individually. A team member with a photo, title, and bio: card. A list of office locations with addresses: list. Forcing locations into cards adds chrome without adding clarity.