render.com
Design analysis
A spacious split hero pairs an oversized, high-contrast product promise with concise supporting copy and dual CTAs. A restrained technical dashboard vignette, geometric construction lines, and a slim promotional/navigation shell add credibility without competing with the message.
Prompt preview
## 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/render-com/a2f1bfec-cff8-46a3-938e-5c68bed6eccd-1789073948-1.webp - Full page it was cut from: https://kage-design-assets.t3.tigrisfiles.io/screenshots/render-com/a2f1bfec-cff8-46a3-938e-5c68bed6eccd-1789073879-full.webp - Component on Kage: https://kage.design/component/render-hero ## Before you start Ask what the user's product does, who it is for, and what its brand personality and visual identity are. Then apply the principles below to create an original hero section for that product rather than reproducing this reference. ## Design direction Build a premium B2B software hero for a developer-facing or infrastructure-oriented product. The composition should feel calm, precise, technical, and highly legible, with a strong editorial headline balanced by a lightweight operational UI visual. ### Structure and layout - Create a full-width page header above the hero. Optionally include a very short announcement strip at the top, but only if the product has a meaningful announcement or offer. - Use a clean navigation row with the product identity on the left, primary navigation near the center-left, and utility links plus one dark, high-emphasis action on the right. - Keep the hero within a wide max-width container, approximately 1100–1240px, with generous horizontal gutters around 64–80px on desktop. - Use a two-column composition: the left column is approximately 52–58% wide and contains the message; the right column contains an abstract product or infrastructure visualization that may extend toward the viewport edge. - Align the headline, paragraph, and CTA row to the same left edge. Keep the visual slightly lower than the headline so the composition feels dynamic rather than like two equal cards. - Give the hero substantial vertical breathing room: approximately 96–130px above the main content and 80–120px below it. - On smaller screens, stack the text above the visual, collapse navigation into a menu, and ensure the headline remains comfortably readable without horizontal overflow. ### Typography hierarchy - Use a modern grotesk or neutral sans-serif with a crisp, slightly technical character. - Make the main headline very large and light-to-regular in weight: roughly 68–82px on desktop, 1.02–1.08 line-height, with a maximum width around 620–700px. Break lines intentionally around the product promise, not arbitrarily. - Use a supporting paragraph at approximately 22–25px with a 1.35–1.45 line-height and a muted dark-gray colour. Limit it to roughly 430–500px so it remains scannable. - Use navigation and button labels around 14–16px, with medium weight and clear contrast. - Keep any labels inside the technical visual uppercase, small, and letter-spaced, around 9–11px. ### Colour - Prefer a mostly white or warm-white canvas, approximately `#FFFFFF` or `#FAFAF8`. - Use near-black for the primary heading and high-emphasis controls, approximately `#111111` or `#151515`. - Use a softer charcoal for body copy, approximately `#4B4B4B`. - Keep structural rules and visual construction lines very subtle, approximately `#DCDCDC` to `#E9E9E9`. - If using an announcement strip, choose a restrained brand-appropriate gradient or solid accent rather than default blue; keep text highly legible. - Use only one or two small accent colours in the product visual, such as a muted violet, green status indicator, or warm neutral. Avoid turning the hero into a colourful dashboard. ### Borders, surfaces, and geometry - Use thin 1px borders for navigation separators, grid lines, and dashboard modules. - Keep corners mostly square or very lightly rounded, approximately 0–4px, to communicate infrastructure precision. - The primary CTA can be a solid near-black rectangle with a subtle hover colour shift; the secondary CTA should be white or transparent with a dark 1px border. - Construct the right-side visual from fine orthogonal grid lines, offset panels, and a simplified monitoring/deployment interface. It should suggest a real product workflow without exposing dense, unreadable data. - Use a small dark command-style label or status chip near the visual only when it reinforces the product's core action. - Add a small utility control, such as theme or display settings, only if it is genuinely useful; do not add decorative controls that imply functionality without purpose. ### Interaction and responsiveness - Primary and secondary CTAs should have distinct hover, focus, and pressed states. Preserve a visible keyboard focus ring. - Navigation links may subtly change colour or underline on hover; the active or primary action should remain visually dominant. - If the visual contains charts or status elements, use restrained hover feedback such as a highlighted module or tooltip, but keep the hero immediately understandable without interaction. - Respect reduced-motion preferences. Any entrance animation should be a brief opacity/translate transition, not a distracting dashboard animation. - Maintain strong contrast and readable text at all breakpoints. On mobile, make CTAs stack or wrap cleanly and crop or simplify the decorative visual rather than shrinking it until it becomes illegible. ## Never - Never use the reference company's logo, product name, navigation labels, promotional copy, headline, body copy, or CTA wording. - Never copy the reference dashboard, monitoring cards, exact grid arrangement, command label, iconography, or visual proportions one-to-one. - Never include logos, product names, copy, illustrations, or imagery from the reference. - Never invent dense fake metrics merely to fill space; use a simple, purposeful visual language tailored to the user's product. - Never sacrifice semantic HTML, accessibility, responsive behaviour, or focus states for visual similarity.
kage