uini.io
Design analysis
A calm two-column feature section pairs an editorial product benefit with a contained in-app knowledge-centre preview. It works through strong left alignment, generous whitespace, restrained typography, and a believable UI example that explains the feature without overwhelming the page.
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/uini-io/ef5b466a-1fe9-4cb6-9300-79049ee31244-1789059861-4.webp - Full page it was cut from: https://kage-design-assets.t3.tigrisfiles.io/screenshots/uini-io/ef5b466a-1fe9-4cb6-9300-79049ee31244-1789059824-full.webp - Component on Kage: https://kage.design/component/uini-feature-grid ## Before you start Ask the user what their product is, who it is for, and what visual brand or design system it uses. Then apply the principles below to create an original feature section for that product—not a copy of the reference. ## Build this section Create a spacious, editorial feature section that explains an in-product knowledge centre, help surface, documentation layer, or comparable product capability. Use a responsive two-column composition: explanatory content on the left and a polished product UI preview on the right. ### Layout and alignment - Place the section inside a wide, centered container with generous horizontal margins and substantial vertical whitespace. - Use a two-column grid on desktop, approximately 40% text / 60% visual, with a large gap between columns. - Vertically center the text block against the main visual rather than aligning it to the top. - Keep the text column relatively narrow so the headline wraps into two or three deliberate lines. - Stack the columns on smaller screens, with the text first and the UI preview below it. - The right side should feel like a contained product demonstration: use a soft, near-white panel or quiet background field behind a floating app card. - Avoid excessive decoration. The visual hierarchy should be created by scale, whitespace, and the contrast between the page and the UI mockup. ### Typography - Use a modern sans-serif with a friendly, highly legible shape. Prefer the product's existing font; otherwise use an equivalent contemporary grotesk. - Add a small, simple document or feature marker above the heading. It can be a minimal CSS icon or custom neutral symbol. - Set the heading in near-black, around #171717, with a large responsive size of roughly 42–52px, medium-to-semibold weight, tight line-height around 1.05–1.12, and modest letter spacing. - Use body copy around 16–18px with 1.55–1.7 line-height and a muted charcoal tone around #5F5F5B. - Separate multiple paragraphs with approximately 24–32px of space. Keep line lengths around 34–45 characters for an editorial rhythm. - All interface text inside the mockup should be noticeably smaller than the marketing copy, with clear hierarchy between title, supporting text, labels, source links, and actions. ### Colour and surfaces - Use a warm, almost-white page background, approximately #FCFCFA or #FEFEFD. - Use near-black text around #171717 and secondary text around #6F706B. - Place the product preview on a very pale neutral field around #F7F7F4, with a subtle cool or grey cast if it suits the brand. - Keep the mockup mostly white, around #FFFFFF, with one restrained brand accent for the app avatar, header artwork, links, or primary action. Choose the accent from the user's brand rather than copying the reference. - Use soft, low-opacity shadows instead of heavy outlines: for example, 0 18px 45px rgba(20, 20, 18, 0.10). ### Product preview composition - Design a believable help-centre or knowledge assistant card rather than a generic illustration. - Give the card a rounded outer radius of approximately 18–24px and a clear top section that may contain a compact branded banner, abstract pattern, or subtle colour field. Do not use stock imagery. - Include a small app/avatar badge overlapping the top area, followed by a concise welcome heading and supporting sentence. - Show one user question in a dark or strongly contrasted message bubble and one helpful answer in a light neutral response bubble. - Include a compact “sources” or related-content area with two or three pill-like document rows, making the answer feel grounded in published content. - Add a low-emphasis feedback or conversion row at the bottom with a short prompt and a compact dark or brand-colour button. - Include a quiet footer or metadata line only if it supports the product story. Keep it visually subordinate. - The mockup should look like a real responsive in-app surface with consistent padding, approximately 14–18px internal spacing, and clear alignment. ### Borders, radius, and interaction - Use hairline borders in a soft neutral such as #E8E8E3 for document rows and input/action containers. - Use rounded message bubbles around 10–16px and pill-shaped tags or buttons around 999px where appropriate. - Buttons should have a visible hover state: slightly darken or shift the brand colour, raise contrast, or move by 1px. Add a short 150–200ms ease transition. - Source rows may lift subtly on hover with a border-colour change and a very light background tint. - Make the entire composition accessible: strong text contrast, visible keyboard focus, semantic headings, and labels for any icon-only controls. - Ensure the preview remains legible and proportionate on mobile; it may become full-width, but should not become a tiny decorative thumbnail. ### Content strategy - Write original copy for the user's product. Explain what users can do, how the feature improves support or discovery, and what happens when information is unavailable. - Keep the headline benefit-led and concrete. Use one or two short paragraphs rather than a long feature list. - Make the UI example reinforce the explanation with a realistic question, answer, and source trail. ## Never - Never reuse logos, product names, brand marks, or proprietary labels from the reference. - Never copy the reference's exact headline, body copy, UI wording, question, answer, source names, or button labels. - Never reproduce the reference screenshot or its exact card proportions, illustration, banner artwork, iconography, or decorative details. - Never use the reference's illustrations, imagery, avatars, or visual assets; create an original CSS-based or product-specific treatment instead. - Never let the mockup become more visually dominant than the feature explanation. - Never add generic gradients, excessive glassmorphism, heavy shadows, or unrelated decorative elements merely to fill space.
kage