## 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/speechmark/77b904ee-7a59-4d24-b7d4-3e274188b21e-1789106593-7.webp
- Full page it was cut from: https://kage-design-assets.t3.tigrisfiles.io/screenshots/speechmark/77b904ee-7a59-4d24-b7d4-3e274188b21e-1789106544280-full.webp
- Component on Kage: https://kage.design/component/speechmark-feature-grid-3

## Before you start
Ask me what my product does, who it is for, and what its visual brand is. Then apply the principles below to create an original version for my product—not a copy of the reference.

## Build a privacy-led feature grid
Create a responsive feature section that explains where sensitive product data is processed and gives users a fast, confidence-building summary of the main benefits. The section should feel considered, technical, and trustworthy without becoming cold or overly corporate.

### Layout and alignment
- Use a very light blue-gray section background, such as `#eef7fd`, with a centered content container capped around `1120–1200px`.
- Start with a left-aligned introductory block. Add a thin vertical accent rule on its left, followed by a large editorial headline and a short explanatory paragraph.
- Below the introduction, create a two-part visual comparison:
  - On the left, show a prominent rounded device/local-processing card.
  - On the right, show a lighter, quieter cloud/remote-processing card with a dashed border.
  - Connect them with a narrow horizontal annotation or arrow that describes what, if anything, crosses the boundary. Keep the diagram understandable without requiring technical knowledge.
- Give the local card stronger visual emphasis through a saturated brand colour, while the remote card should look visually secondary and conditional.
- Place a thin divider below the comparison. Under it, use a three-column checklist grid with two short benefit items per column. On small screens, stack the columns or use a two-column layout if the text remains readable.
- Finish with a small text link aligned to the content container, using an arrow or similarly restrained directional cue.
- Preserve generous empty space around the section. Avoid crowding the diagram, checklist, and follow-up link.

### Typography hierarchy
- Use a distinctive serif or humanist display face for the main heading, approximately `44–64px` desktop with tight line-height around `0.98–1.08`; scale to `34–42px` on mobile.
- Use a readable serif or neutral humanist font for the body copy, approximately `17–20px` with `1.45–1.6` line-height.
- Use a compact uppercase sans-serif eyebrow inside the cards, around `10–12px`, with increased letter spacing of `0.12–0.18em`.
- Use medium-weight sans-serif text for checklist items, around `14–16px`, with enough line height for quick scanning.
- Establish clear contrast between the large editorial heading, explanatory copy, diagram labels, and checklist details.

### Colour and visual language
- Use a pale blue background around `#eef7fd` or `#edf6fc`.
- Use deep navy ink around `#102d52` for headings and important labels.
- Use muted slate blue-gray around `#566473` for supporting text.
- Use a confident medium blue around `#2874c6` for rules, links, arrows, and the local-processing card.
- Use a deeper blue panel around `#174a8c` inside the local card for contrast.
- Use a warm pale yellow around `#f5dc79` only for a small security or status accent.
- Use very pale blue-white around `#f7fbfe` for the remote card and waveform/diagram surfaces.
- Use soft gray-blue borders around `#c8d6df`; keep the divider subtle rather than high contrast.

### Cards, borders, and radius
- Give the prominent local card a radius of roughly `16–20px`, generous internal padding, and a soft blue-tinted shadow.
- Give the remote card a similar radius but a thinner, quieter treatment; use a `1px` dashed border to signal an optional or external boundary.
- Use small inset panels inside each card to represent product output, data, or status. Keep these abstract and brand-neutral.
- Use a modest radius around `10–12px` for inset panels and controls.
- Keep the overall design flat and diagrammatic. Do not add excessive gradients, glass effects, or decorative shadows.

### Diagram and interaction
- Represent the data flow with simple abstract UI elements such as a waveform, text bars, status marks, or a crossed-out signal. Do not rely on an illustration.
- Make the local/remote relationship explicit with a labeled connector and a short qualifier such as “optional” or “only when enabled,” adapted to the product’s actual behaviour.
- Ensure the feature grid remains understandable in a static screenshot and works with keyboard navigation and screen readers.
- Make the final policy or details link visibly interactive: use the accent colour, a subtle hover underline or colour shift, and a clear focus state.
- If the cards are interactive, use restrained hover elevation or border emphasis only; do not turn the section into a carousel.
- On mobile, move the connector label between the two cards or convert it into a vertical flow indicator.

### Content guidance
- Write original, product-specific copy based on the user’s actual privacy, security, or data-flow claims.
- Keep the checklist claims short, concrete, and verifiable. Prefer one idea per line.
- Use the feature grid to answer the user’s likely trust question: what stays local, what may leave the device, and what is never sent.

## Never
- Never use the reference product’s logo, product name, or brand identity.
- Never reuse the reference copy, headings, checklist wording, labels, or policy-link text.
- Never copy the exact card composition, diagram, waveform, or visual arrangement; reinterpret the information architecture for the user’s product.
- Never use the reference’s illustrations, imagery, icons, or screenshots.
- Never invent privacy or security claims that the user’s product cannot substantiate.
- Never make the section depend on colour alone to communicate the data boundary.