Wensity

React feature section components

11 feature section componentsLive previewFull source in your repo

The features section is where a landing page has to prove the product. These blocks do it with a six cell control grid, a row of product cards, a prompt on a blurred still, or an empty upload tray.

Browse all feature blocksRead the docs

Works with

  • React
  • Next.js
  • TypeScript
  • Tailwind CSS

Features section blocks you can copy

Each features section is one file covering the headline, the proof layout and the responsive Tailwind rules. Preview it live, then copy the source into your project.

Bento grid feature sections

A bento grid gives one feature the large tile and the rest smaller ones. Use these when a features section needs depth rather than six equal cells.

SaaS UI to show beside your features

Dashboards, usage panels and dense product UI from the same library, for a features page that needs more than a six cell grid.

Feature card components

Single cards to drop into a features grid of your own: panels that expand on hover, a spinning globe, a glass envelope and the plain Card primitive.

How to design a features section that proves the product

A features section is the part of a landing page that explains what the product does, usually straight after the hero. The hero spent the visitor's first attention on one promise. This section has to back that promise up for someone reading more slowly, who wants to know whether the product can be trusted, operated or measured. If a line here would also work on a pricing card, it is too thin for the slot.

Most features section designs use one of three layouts. A grid of cells, each with an icon, a title and one sentence, for claims a buyer already understands. A row of product cards, for a product people need to see before they believe it. A split or a stage, with copy on one side and a working interface on the other, for one workflow told in detail. Pick the layout from the claim you are making rather than from whichever feature section example looks best.

Feature Section With Security Grid is the grid case. Six equal cells name vaults, seats, review letters and other controls, each with a hairline icon, and two buttons sit above the matrix. No cell is a screenshot, because a compliance claim that lives only in an image is the first thing a legal review deletes. Keep the claims in the DOM where a buyer can select and quote them.

Feature Section With Gradient Product Cards and Feature Section With Workspace Composer are the cards case. The first sets coded interface panels on sea glass and lilac gradients with a photograph in the middle card. The second puts a chat composer with Calendar, Meet and Drive chips on a blurred still, with three product claims below. Replace every photograph and every panel before you ship: a photo unrelated to the product makes the interfaces read as decoration.

Feature Section With Blurred Prompt Stage and Feature Section With Media Upload Stage are the stage case. The prompt stage pairs a serif headline and a one open accordion with a tall blurred photograph carrying a live prompt card, and opening a row rewrites that card. The upload stage sets an empty dropzone on a blurred still, then follows it with three proof mockups. Both work when the product is a single action worth watching rather than a list of capabilities.

Three to six features is the range that still reads as one section on a laptop. Past six, the second row is the part most people skip, and a claim nobody reads costs attention from the ones they do. If a cell is a synonym of its neighbour, cut it and let the remaining cells breathe. Overflow belongs in documentation, linked from a single cell.

Write every cell as a claim you could defend in a security review or a sales call. Region locked storage and least privilege seats are claims. Powerful and seamless are not. A thinner icon stroke does not make a weak policy look finished, and the visitor scanning this section is usually looking for the one line that disqualifies you.

Do not follow one features section with another. One proof section is already a full argument, and the next block on the page should ask for a decision: pricing, a FAQ, or a walkthrough of how it works. Keep the buttons honest too. Talk to security belongs on a grid for buyers who will not self serve, and an empty button that jumps to a hash is worse than no button.

Frequently asked questions

It is the block on a landing page that lists what the product does and why each capability matters, usually placed under the hero. It is typically a grid of short claims, a row of product cards, or a split layout with copy beside a working interface. Its job is to turn the hero's single promise into specific, checkable reasons to believe it.

Run the Wensity CLI with the block slug, for example npx wensity@latest add feature-section-with-security-grid --type block. The CLI writes the component into your codebase and pulls in the packages it needs. You can also open any feature section on this page and copy the source from the Code tab. There is no provider to wire up.

Icons help when the cells are certificates, controls and policies that a visitor already recognises, which is why Feature Section With Security Grid uses hairline icons. Use real interface panels or screenshots when the product has to be seen to be believed, as the gradient product cards do. Mixing both inside one grid usually means the claims were not sorted first.

Six is the upper bound that still reads as one section on a laptop, and four is calmer. Eight forces a second row that most people will not finish. If a claim cannot survive being cut, it did not belong on the marketing page. Put the overflow in documentation and link to it from one cell.

Yes. The security grid stacks, then becomes two columns, then three. The gradient product cards, the blurred prompt stage, and the media upload stage stack to one column on a phone. Nothing is hidden behind a carousel and nothing scrolls sideways. Test the longest description on a 360 pixel width before you ship.

Directly under the hero, or after a short social proof strip if the product is unknown. It should not follow a long article of other features. By the time someone has read three sections of benefits they have stopped comparing and started skimming. One proof section, then a decision section such as pricing or a FAQ.

Where to go next