## Reference images

Study these alongside the description below: hierarchy, rhythm, spacing, colour. Build for the product you are asked about, using this design language.

- Component: https://kage-design-assets.t3.tigrisfiles.io/components/hob/bb3af585-7542-45f5-8db1-3e25168b9aff-1789106503-6.webp
- Full page it was cut from: https://kage-design-assets.t3.tigrisfiles.io/screenshots/hob/bb3af585-7542-45f5-8db1-3e25168b9aff-1789106472876-full.webp
- Component on Kage: https://kage.design/component/hob-feature-grid-4

## Before you start
Ask the user what their product is, who it is for, and what visual brand system it uses. Then apply the principles below to create an original trust, privacy, security, or product-principles feature section for that product—not a copy of the reference.

## Build this section
Create a spacious feature-grid section that presents a short, confident section heading above a two-column bento layout. Use the grid to turn high-level product promises into tangible evidence: one dominant card should be mostly text-led, while a secondary card should pair concise explanatory copy with a compact technical or product-interface detail.

### Layout and alignment
- Place the section inside a very light neutral panel with generous outer padding, approximately 32–56px on desktop.
- Use a centered section heading above the cards, with a maximum width that keeps it to one line where possible.
- Below it, use a two-column grid with a subtle gap of about 20px.
- Make the left card wider or visually dominant; let it occupy roughly 55–58% of the grid width.
- Make the right column a stacked composition: an upper explanatory card and a lower proof area containing two compact rows, panels, or code-like readouts.
- Give the dominant card a substantial minimum height. Keep its copy aligned to the upper-left, with a large quiet area below so the content feels considered rather than crowded.
- Add a slim bottom control or metadata strip to the dominant card only when it supports the product story. Populate it with generic controls, status labels, or selectors relevant to the user’s product, not decorative filler.
- On small screens, collapse to one column. Preserve the dominant card first, then stack the supporting card and proof panels. Reduce outer padding while keeping the internal breathing room.
- Align card text, proof panels, and dividers to a consistent internal grid. Avoid excessive centering inside cards; the cards should feel structured and operational.

### Typography hierarchy
- Use a modern sans-serif or the product’s existing UI typeface.
- Set the section heading in a bold, compact display style around 28–32px desktop, with tight line-height around 1.1–1.2.
- Set feature titles around 20–23px, medium or semibold, with a restrained line height.
- Set supporting descriptions around 16–18px with a relaxed 1.5–1.65 line height.
- Use smaller 13–15px text for metadata, controls, code snippets, and status information.
- Keep sentence case and use short, direct copy. Make the claim prominent, then explain how the product makes it true.

### Colour
- Use a warm or cool off-white page background, approximately `#FFFFFF` or `#FCFCFB`.
- Put the whole feature area on a very light gray surface, approximately `#F5F5F5` to `#F7F7F7`.
- Use white cards, approximately `#FFFFFF`, against that surface.
- Use near-black for headings and primary text, approximately `#171717` to `#202020`.
- Use a softened gray for descriptions and metadata, approximately `#6B6B6B` to `#777777`.
- Use pale gray borders and separators, approximately `#E6E6E6` to `#ECECEC`.
- If the product has an accent colour, introduce it sparingly in status indicators, icons, or one interactive affordance; do not let it overpower the calm, trustworthy composition.

### Borders, radius, and depth
- Use thin 1px borders rather than heavy shadows.
- Give the outer section a modest radius around 6–10px.
- Give cards a radius around 10–14px, with the dominant card and stacked cards sharing the same visual language.
- Keep shadows absent or extremely subtle, such as a low-opacity gray lift only where needed to separate white cards from the pale panel.
- Use clear horizontal rules to separate a card’s content from its control or metadata strip.
- Proof panels may use a slightly tighter radius and a faint inset or border to feel like embedded technical output.

### Interface details and interaction
- Make any visible controls feel functional: use compact labels, simple chevrons, status marks, sliders, or capability indicators that match the product domain.
- Treat the lower proof area as evidence, not decoration. It can show a log excerpt, permission state, local path, audit event, API response, workflow state, or another product-specific artifact.
- Use monospace typography only for technical output, paths, identifiers, or logs.
- Keep interactions subtle: cards can slightly raise or strengthen their border on hover; controls can reveal a clear focus ring; any dropdown or selector should have an obvious but restrained active state.
- Ensure all controls have keyboard focus states and accessible labels. Do not rely on colour alone to communicate status.
- Use responsive wrapping for control rows rather than allowing labels to collide or overflow.

### Content strategy
- Write two or three original feature claims relevant to the user’s product. The first should express a clear principle or boundary; the second should explain where or how the product operates; the proof area should demonstrate a concrete consequence.
- Keep claims specific and credible. Prefer concrete language over generic phrases such as “best-in-class” or “next-generation.”
- If showing technical evidence, use realistic but invented values that fit the user’s product. Avoid exposing real credentials, paths, customer data, or proprietary identifiers.

## Never
- Never reuse the reference’s logos, product names, brand marks, icons, or distinctive copy.
- Never copy the reference’s exact claims, labels, code, paths, control names, or interface data.
- Never include illustrations, screenshots, or imagery from the reference.
- Never reproduce the exact grid proportions if they conflict with the user’s content; adapt the composition to the product and responsive needs.
- Never make the section feel like a generic dashboard full of decorative widgets.
- Never use colour, borders, or motion so aggressively that the trust-oriented message loses its calm, credible tone.