Applying a Bento visual direction

You are being asked to apply a Bento visual direction to a web interface. This document gives you framing and recommendations for that direction. It does not tell you what page, product, or feature to build — apply the guidance below to whatever interface you are already working on, at whatever scope that work requires.

What “Bento” means here

Bento organizes content into a mosaic of rounded tiles at different sizes, packed tightly into a filled rectangle with an identical gap on every side — the arrangement of a compartmented lunch box, which is where the name comes from. Its purpose is to make a lot of separate things scannable at once: instead of a long scroll of sections, a viewer sees the whole set in a single glance and picks what to read.

The discipline is the one-idea rule. Each tile holds exactly one thing: one claim, one metric, one image, one feature. The moment a tile contains two headings of equal weight, it stops being a compartment and becomes a small page, and the format’s entire advantage disappears. Tile size is how you express importance — a bigger compartment for the thing that matters more — not a container to be filled with more material.

The second discipline is that the mosaic must actually be full. A bento arrangement with holes in it reads as a broken grid rather than a designed one, and fixing that with automatic dense packing is not an option: it makes what a viewer sees diverge from what a screen reader announces.

Recommendations

• Define the grid explicitly — column count, row count, and the span of every tile — rather than letting tiles flow and land where they may.
• Vary spans meaningfully. If every tile is the same size it is a card grid, not a bento; give the most important item two columns or two rows and let the rest fit around it.
• Put one idea in each tile. If a tile needs two headings, it is two tiles.
• Use one corner radius for every tile, generous enough to read as a compartment — eight pixels or more.
• Keep the gap identical horizontally and vertically. An uneven gap is what makes a mosaic look accidental.
• Fill the rectangle. If a hole appears, resize a neighboring tile or promote something into it; do not leave the gap and do not turn on dense auto-placement.
• Make each tile self-contained: its own heading, its own meaning, understandable without reading its neighbors. Viewers do not read a bento in order.
• Order the tiles in the document the way you want them read, and let the visual order follow. Explicit placement keeps those two the same.

Avoid

• Uniform tiles at a single size, which is a card grid wearing the name.
• Two headings of the same level inside one tile.
• Different corner radii or different gap values across the mosaic.
• Empty cells left inside the mosaic’s bounding rectangle.
• Dense automatic packing, which makes visual order diverge from document order.
• Tiles whose content only makes sense in sequence with the tile beside them.

How to check your own work

Before considering the result finished, look at it and ask:

• Are all the tiles the same size? If so, nothing is being said about relative importance and the format is doing no work.
• Does any tile contain two things I would describe separately? Split it.
• Is there a hole anywhere inside the mosaic’s rectangle? Fill it by resizing, not by packing.
• Read the tiles in document order with the visuals hidden. Is that the order they appear on screen? If not, the layout is reordering content and that has to be fixed at the placement level.
• Pick any single tile and read it alone. Does it still mean something? If it needs its neighbor, the content is not compartmented yet.

A working order

1. Inventory the product facts and give every fact a priority before placing a tile.
2. Declare the desktop grid, rows, gaps, and spans explicitly; place the primary promise first in both DOM and visual order.
3. Give each remaining feature one heading and one supporting idea, then fill any hole by resizing content rather than enabling dense packing.
4. Verify the mosaic as a rectangle, its reading order as a sequence, and every tile as meaningful in isolation.
5. Redraw all spans for narrow widths and retain at least one high-priority full-width tile until the honest one-column collapse.

Bento — Specification

Definition

Bento is a web-interface layout style that arranges content as a tightly packed mosaic of rounded tiles at varying spans, filling a rectangle with a uniform gap on every side. Each tile carries exactly one idea, and tile size expresses relative importance. Its purpose is to make many separate items scannable simultaneously rather than sequentially.

Core principles

• One idea per compartment. A tile holds a single claim, metric, image, or feature; two ideas mean two tiles.
• Size communicates importance. Span is the mechanism for emphasis, not a container to be filled with more material.
• The mosaic is full. Holes inside the bounding rectangle read as a broken grid rather than a composed one.
• Explicit placement. Every tile’s span and position is declared, which is what keeps visual order identical to document order.
• Tiles stand alone. Each is understandable without its neighbors, because a bento is not read in sequence.

Visual characteristics

• Rectangular tiles of varying width and height packed into a filled rectangle.
• A single, generous corner radius shared by every tile.
• An identical gap horizontally and vertically between all tiles.
• One heading plus its supporting content inside each tile.
• No empty cells within the mosaic’s bounds.
• Larger tiles for higher-priority items, surrounded by smaller ones.

Rules

1. Explicit grid with varying spans. The mosaic is a declared grid in which tiles occupy different spans. Acceptance criterion: The container declares explicit columns and rows, and at least two tiles occupy different span values.

2. One idea per tile. Each compartment carries a single subject. Acceptance criterion: No tile contains more than one heading at the same heading level.

3. Uniform corner radius. Tiles share a single rounding value. Acceptance criterion: The computed border-radius is identical across every tile and measures 8px or greater.

4. Constant gap. Separation is even in both axes. Acceptance criterion: Computed row-gap and column-gap are equal to each other and identical throughout the mosaic.

5. No holes. The mosaic fills its own rectangle. Acceptance criterion: No empty grid cell exists within the bounding rectangle of the rendered mosaic.

6. Visual order equals document order. Placement never reorders content. Acceptance criterion: grid-auto-flow does not include dense, and the visual sequence of tiles matches their order in the DOM.

7. Self-contained tiles. Each tile is meaningful in isolation. Acceptance criterion: Every tile has its own accessible name, and its content is comprehensible without reading any adjacent tile.

8. Priority owns area. The largest tile carries the primary product promise, not incidental decoration. Acceptance criterion: The tile with the greatest rendered area contains the page’s primary heading or action, while supporting facts occupy smaller tiles.

9. One radius and one gap system. The mosaic reads as one container even when tile colors differ. Acceptance criterion: All tiles share one computed radius and every adjacent horizontal and vertical separation resolves to the same gap token.

10. Feature content is scannable. A tile describes a product feature without requiring sequential prose. Acceptance criterion: Each feature tile has one heading and at most one supporting sentence, and no sentence refers to a neighboring tile for its subject.

11. Responsive spans are deliberate. The priority hierarchy survives the reduced grid. Acceptance criterion: At a two-column breakpoint, the primary tile spans both columns and remaining tiles use declared spans without holes or dense packing.

Avoid

• Uniform tiles at a single size, which is a card grid rather than a bento.
• Two same-level headings inside one tile.
• Varying corner radii or gap values across the mosaic.
• Empty cells left inside the mosaic’s bounding rectangle.
• Dense automatic packing, which separates visual order from document order.
• Tile content that only makes sense in sequence with its neighbor.

Acceptance criteria

• Rule 1: The grid is explicitly declared and at least two tiles have different spans.
• Rule 2: No tile contains two headings of the same level.
• Rule 3: All tiles share one corner radius of at least 8px.
• Rule 4: Row gap and column gap are equal and constant throughout.
• Rule 5: No empty cell exists inside the mosaic’s bounding rectangle.
• Rule 6: Dense packing is not used and visual order matches DOM order.
• Rule 7: Every tile has its own accessible name and stands alone.
• Rule 8: The largest tile carries the primary promise or action.
• Rule 9: Tile radius and separation use one shared system.
• Rule 10: Feature tiles remain short and self-contained.
• Rule 11: Reduced grids use explicit, hole-free spans.

Blocking failures

• Dense automatic packing is enabled, so the order a sighted visitor sees differs from the order a screen reader or keyboard user encounters.
• A tile’s content is unintelligible without an adjacent tile, which breaks the format’s premise that items can be read in any order.
• Every tile has an identical span, so the layout communicates nothing about relative importance and the format has been applied as decoration.

These conditions make the work unacceptable to ship; they are not stylistic suggestions and are not subject to designer discretion.

Responsive adaptation guidance

• The column count reduces at narrower viewports and tile spans are re-declared for the reduced grid; spans are never left to reflow automatically, since that is what introduces holes and reordering.
• Span variation (Rule 1) must survive the reduction: at a two-column grid, at least one tile spans both columns while others span one.
• The no-holes requirement (Rule 5) is re-verified at every breakpoint, because a span that fits a four-column grid frequently leaves a gap in a three-column one.
• At the narrowest widths the mosaic legitimately collapses to a single column of stacked tiles; Rules 2, 3, 4, 6, and 7 continue to apply, while Rules 1 and 5 are satisfied trivially.