İçeriğe geç
Blog

Card UI Readability vs Aesthetics: Lessons We Learned

How we decide between a pretty card and a readable one, and the cheap tests we use to check whether a player can understand a card in a single glance.

IIlhan Seyhan8 min read1 views

Every card game UI runs into the same argument: the card that looks best in a mockup is rarely the card that reads fastest in a player's hand. This post is about how we settled that argument on Kart Üçlüsü — the specific things that slowed testers down, and the cheap, repeatable checks we use to answer one question: can a player understand a card in a single glance?

You'll get five tests you can run today without any analytics tooling, plus the icon, text-density and hand-layout rules we ended up with.

The real tradeoff is not beauty vs clarity — it's hierarchy

"Readable or pretty" is a false choice most of the time. When a card is hard to read, the usual cause isn't that the art is too good; it's that too many elements are competing for the same level of attention. A decorative frame, a full-bleed illustration, a suit symbol and a rank number can all coexist — as long as exactly one of them wins the first 200 milliseconds.

So we stopped asking "is this card beautiful?" and started asking "what does the eye hit first, and is that the thing the player needs?" In a classic card game the answer is almost always rank first, suit second, everything else third. Once we wrote that order down, most layout debates resolved themselves: anything that made the third tier louder than the second tier was cut, no matter how nice it looked in isolation.

Five ways we measure "at a glance"

None of these need a lab. We run them on a phone, in a room, with people who aren't on the project.

  1. The flash test. Show a card for roughly a third of a second, hide it, then ask what it was. If a design survives a flash, it survives a real hand. If the tester needs a second look, the hierarchy is broken — not the tester.
  2. The grayscale test. Screenshot the table and strip the color. If red and black suits, or selectable and non-selectable cards, become indistinguishable, the design is leaning on hue alone. That fails for colour-blind players and for anyone playing outdoors.
  3. The thumbnail test. Scale a screenshot down to a few hundred pixels wide, or just export the card at 48 px. Whatever is still legible is your first tier. Whatever disappears was decoration all along — which is fine, as long as you know it.
  4. Time to first action. Hand someone a fresh board state and measure the gap between the board appearing and the first tap. Comparing two layouts on the same board states tells you more than any opinion in a design review, because the tester is doing the same task in both cases.
  5. Miss-tap counting. We watch for taps that get corrected within a second — the player touched a card, realised it wasn't the one they wanted, and moved. Those corrections cluster around exactly the overlapping or badly labelled cards, and they show up on video even when the tester never complains out loud.

The important part is that all five are comparative. We never chase an absolute score; we run the same test on version A and version B and keep whichever one people misread less.

What actually slowed players down

The patterns below came up again and again in our sessions and in our own play:

  • Illustration bleeding into the corner value. A full-bleed artwork looks great in a card gallery, but the moment a light part of the art sits behind a light rank number, the number stops being scannable. A flat plate or a solid pip zone behind the value fixes it and costs nothing visually.
  • Display typefaces for numbers. Ornate figures cost recognition time, especially 6/8/9 and 1/7 at small sizes. We kept the personality in the frame and the back of the card, and used a plain, high-contrast face for anything the player has to read under time pressure.
  • Icons that need a legend. If a tester has to ask what a symbol means once, they'll ask again in a week. Any icon that didn't survive a cold read got a text label or got deleted.
  • Tone-on-tone card backs and table felt. A tasteful dark green table with dark blue card backs looks calm and makes the hand edge disappear. Card silhouettes need to separate from the background before anything printed on them matters.
  • Too much text per card. More than one short line and players stop reading entirely — they pattern-match on colour and position and guess. Guessing is fast and wrong, which is the worst combination.

Iconography rules we settled on

Icons are where aesthetics quietly eat clarity, so we gave ourselves hard rules:

  • Shape carries the meaning, colour only reinforces it. Two icons that differ solely in hue are one icon.
  • One meaning per silhouette. If a symbol means "score" in one place and "bonus" in another, players stop trusting it everywhere.
  • Test at the smallest size you ship, not the size you design at. We export icons at 16 and 24 px and look at them at arm's length. Interior detail almost always has to go.
  • Contrast is a spec, not a taste. WCAG's contrast minimum for normal text is a ratio of 4.5:1 (W3C, Understanding SC 1.4.3). Game UI isn't a web page, but using that number as a floor for anything a player must read quickly removed a whole class of arguments from our reviews.

Hand layout: the part players feel but never mention

Card readability isn't only about the card face. On a phone, a hand of cards is a stack of overlapping tap targets partly covered by a thumb. Three decisions mattered most:

Minimum visible strip. Each card needs enough exposed width to be both identifiable and tappable. Apple's guidance is a minimum tappable area of 44×44 points for controls (Apple Human Interface Guidelines: Layout), and we treat that as the floor for a card's visible strip rather than for the whole card. Below that, miss-taps appear immediately.

Overlap that degrades predictably. Instead of dividing the container by the card count, we clamp the step so the hand never squeezes past the usable minimum:

// Lay out a hand so every card keeps a minimum visible strip.
function handLayout({ count, containerWidth, cardWidth, minVisible = 44 }) {
  if (count <= 0) return [];
  if (count === 1) return [{ x: (containerWidth - cardWidth) / 2, z: 0 }];

  const fitStep = (containerWidth - cardWidth) / (count - 1);
  const step = Math.min(cardWidth, Math.max(minVisible, fitStep));
  const handWidth = step * (count - 1) + cardWidth;
  const startX = (containerWidth - handWidth) / 2;

  return Array.from({ length: count }, (_, i) => ({
    x: startX + i * step,
    z: i, // later cards draw on top, so the fan reads left to right
    overflowing: handWidth > containerWidth,
  }));
}

When overflowing is true, the honest answer is not "squeeze tighter" — it's a second row or a scrollable hand. Squeezing turns a readable hand into a coloured smear.

Selection feedback in two channels. A selected card lifts and changes contrast. Movement alone is easy to miss mid-thumb; a border alone is easy to miss under a thumb.

The iteration loop: paper, grey blocks, then art

Our sketching order is deliberate. Paper first, because it's the only stage where deleting an element is free. Then a grey-block version on a real device — no illustration, no final typeface, just rectangles and numbers at true size. Most hierarchy problems are visible here, and fixing them before the art exists means nobody has to defend work they already finished. Art comes last, and its job is to fit into a hierarchy that's already proven, not to establish one.

One habit worth stealing: keep the rejected versions side by side in a single image. When a decision comes back up six months later, "we tried it and people misread it" is a much shorter conversation with a picture attached.

A checklist you can run in an afternoon

  1. Screenshot your table. Convert to grayscale. Can you still tell suits, and selectable from non-selectable cards, apart?
  2. Scale that screenshot to thumbnail size. Is the rank still the loudest thing on each card?
  3. Flash a single card at someone for a third of a second. Do they name it correctly?
  4. Export every icon at 16 px. Which ones become mush? Simplify or label them.
  5. Measure the narrowest visible card strip in a full hand. Is it at least a comfortable fingertip wide?
  6. Watch one person play for five minutes and count corrected taps. Look at where they cluster, not how many there are.

None of this makes a card game look worse. It just moves the decoration to where it can't cost the player a beat — which, in a game like Kart Üçlüsü where a turn is a couple of seconds long, is the difference between a game that feels smooth and one that feels vaguely tiring for reasons nobody can name.

Share:

Comments

Be the first to comment.