--- version: alpha name: Companion Robotics Interface description: "A friendly robotics and physical-AI design system for humanoid robot, robotics SDK, companion hardware, and embodied AI launch pages. It uses a cloud-gray canvas, soft sky-blue signal color, warm domestic surfaces, approachable rounded product modules, visible safety evidence, developer-ready capability rails, and playful but controlled interaction states. The system is inspired by public award-case metadata and case-study writing for Fauna Robotics, but it must not copy proprietary robot likenesses, photography, illustrations, brand marks, videos, or exact motion." colors: primary: "#D1E3FF" primary-strong: "#6EA8FF" primary-ink: "#17324F" on-primary: "#102436" canvas: "#F6F5F0" canvas-cloud: "#EFEFEF" surface-card: "#FFFFFF" surface-soft: "#F9F8F2" surface-blue: "#D1E3FF" surface-warm: "#F3DEC9" surface-play: "#FFE4A8" surface-safety: "#DCEEDC" ink: "#171A1C" body: "#3F464A" muted: "#747C80" hairline: "#D7D8D3" hairline-strong: "#B7BDB8" safety: "#6F9F6A" fun: "#FFB86B" research: "#BCA7FF" danger: "#D85C4A" focus: "#6EA8FF" inverse-canvas: "#11171C" inverse-surface: "#18222A" inverse-ink: "#F4F7F8" typography: display-xl: fontFamily: "Nunito Sans, Inter, system-ui, sans-serif" fontSize: 68px fontWeight: 760 lineHeight: 1 letterSpacing: 0 display-lg: fontFamily: "Nunito Sans, Inter, system-ui, sans-serif" fontSize: 46px fontWeight: 740 lineHeight: 1.06 letterSpacing: 0 heading-md: fontFamily: "Nunito Sans, Inter, system-ui, sans-serif" fontSize: 28px fontWeight: 740 lineHeight: 1.16 letterSpacing: 0 title: fontFamily: "Nunito Sans, Inter, system-ui, sans-serif" fontSize: 18px fontWeight: 760 lineHeight: 1.28 letterSpacing: 0 body-lg: fontFamily: "Inter, system-ui, sans-serif" fontSize: 18px fontWeight: 440 lineHeight: 1.55 letterSpacing: 0 body: fontFamily: "Inter, system-ui, sans-serif" fontSize: 15px fontWeight: 440 lineHeight: 1.55 letterSpacing: 0 label: fontFamily: "Inter, system-ui, sans-serif" fontSize: 12px fontWeight: 760 lineHeight: 1.25 letterSpacing: 0.04em textTransform: uppercase mono: fontFamily: "ui-monospace, SFMono-Regular, Menlo, Consolas, monospace" fontSize: 12px fontWeight: 520 lineHeight: 1.45 letterSpacing: 0 rounded: none: 0px xs: 8px sm: 12px md: 18px lg: 26px xl: 36px blob: 44px pill: 9999px spacing: base: 6px xs: 6px sm: 12px md: 18px lg: 24px xl: 36px xxl: 56px section: 104px components: request-robot-button: backgroundColor: "{colors.ink}" textColor: "{colors.surface-card}" typography: "{typography.body}" rounded: "{rounded.pill}" padding: 12px 18px white-paper-button: backgroundColor: "{colors.surface-card}" textColor: "{colors.ink}" typography: "{typography.body}" rounded: "{rounded.pill}" padding: 12px 18px companion-card: backgroundColor: "{colors.surface-card}" textColor: "{colors.ink}" typography: "{typography.body}" rounded: "{rounded.lg}" padding: 22px safety-panel: backgroundColor: "{colors.surface-safety}" textColor: "{colors.ink}" typography: "{typography.body}" rounded: "{rounded.xl}" padding: 24px audience-pill: backgroundColor: "{colors.surface-blue}" textColor: "{colors.primary-ink}" typography: "{typography.label}" rounded: "{rounded.pill}" padding: 8px 12px spec-chip: backgroundColor: "{colors.canvas-cloud}" textColor: "{colors.body}" typography: "{typography.mono}" rounded: "{rounded.pill}" padding: 7px 10px wizard-step: backgroundColor: "{colors.surface-warm}" textColor: "{colors.ink}" typography: "{typography.body}" rounded: "{rounded.md}" padding: 16px motion: companion-response: purpose: "Make an embodied agent feel responsive without pretending that motion is capability proof." properties: "transform, opacity, color, border-color" duration: "160ms to 360ms" fallback: "Static labels, step numbers, and visible state chips." product-reveal: purpose: "Reveal hardware close-ups, safety details, and SDK affordances." properties: "opacity, transform, clip-path only when content remains readable without it" fallback: "Sequential cards and still product frames for prefers-reduced-motion." layout: hero: "First viewport shows the robot or physical product state as the main signal, paired with a concise human promise and two concrete actions." grid: "12-column desktop grid, 6-column tablet grid, 1-column mobile. Product stage can span 6 to 7 columns; copy and CTAs span 5 to 6 columns." sections: "Alternate product evidence, safety evidence, audience rails, and developer platform details. Avoid abstract brand-only sections." surfaces: "Use cloud-gray and warm domestic surfaces as room-like fields. Use blue for capability, safety green for trust, and amber for playful moments." guidance: do: - "Make the physical product, robot state, or hardware close-up visible in the first viewport." - "Pair friendliness with safety evidence: lightweight materials, soft exterior, pinch-point mitigation, compliant control, sensing, or test status." - "Separate developer, enterprise, researcher, consumer, and venue audiences with scannable rails." - "Use rounded, asymmetric modules to make robotics feel approachable, while keeping specs and safety labels precise." - "Give every playful interaction a functional state label and a mobile equivalent." dont: - "Do not show only abstract shapes, mascots, or vague AI copy in the hero." - "Do not use cuteness as a substitute for safety, capability, battery, autonomy, or teleoperation evidence." - "Do not copy Fauna Robotics, O0, Sprout imagery, videos, illustrations, exact character design, brand marks, or page choreography." - "Do not hide critical safety details inside video-only sections or hover-only reveals." - "Do not let large rounded cards become a generic toy-like page; keep hardware facts visible." caseStudy: source: "Fauna Robotics public award listing, live site, and O0 case study, reviewed June 18 2026" urls: - "https://www.awwwards.com/sites/fauna-robotics" - "https://faunarobotics.com/" - "https://www.ozero.design/works/fauna-robotics" - "https://www.awwwards.com/inspiration/main-page-fauna-robotics" - "https://www.awwwards.com/inspiration/mobile-fauna-robotics" analysis: "The public Awwwards listing describes a technology and startup site with graphic design, icons, illustration, gestures, interaction design, and a palette anchored by #EFEFEF and #D1E3FF. The live site frames robots as capable, safe, and fun, with white papers, video, developer, enterprise, and researcher paths, plus explicit safety-first claims. The O0 case study frames the reusable design move as coexistence over replacement: playful interactions, asymmetric shapes, warm calm tones, detailed close-ups, and a companion-like posture. This resource extracts that reusable interface pattern without copying the source brand or proprietary assets." --- # Companion Robotics Interface Use this design system for humanoid robot launches, robotics SDK pages, embodied AI platforms, companion hardware, home robotics, retail and hospitality robots, research lab showcases, teleoperation tooling, and physical-AI developer portals. The posture is capable, safe, and friendly. A page should make the robot feel approachable, but it must also show evidence. The style works best when soft, playful surfaces are paired with precise specs, safety states, SDK details, and audience-specific next steps. ## Overview The core idea is coexistence-first robotics. The interface introduces an embodied machine as something that can live near people, not as a replacement fantasy or a faceless industrial arm. It balances three signals: 1. A visible physical object, robot state, or hardware close-up. 2. Evidence that the system is safe, controllable, and inspectable. 3. A friendly product voice that makes complex robotics feel reachable. The first viewport should never be only abstract AI copy, soft blobs, or cinematic atmosphere. Show the product or a representative state. If the true product image is unavailable, use a clearly marked schematic, CAD-like frame, prototype stage, or capability diagram rather than pretending with generic stock imagery. The style uses cloud-gray, sky-blue, warm room-like surfaces, soft green safety panels, and amber play accents. Large rounded modules are allowed because the product category benefits from approachability, but facts must remain crisp: locomotion, teleoperation, autonomy, sensing, materials, developer access, release stage, and deployment context. ## Colors ### Brand & Accent - `primary` (#D1E3FF) is the soft sky-blue signal. Use it for capability modules, active audience rails, hero product halo panels, and selected states. - `primary-strong` (#6EA8FF) is for focus, links, progress, and high-contrast accents. Use it sparingly so the interface does not become a generic blue SaaS page. - `primary-ink` (#17324F) is readable text on sky-blue surfaces. ### Surface - `canvas` (#F6F5F0) is a warm off-white page floor that keeps the experience domestic and human. - `canvas-cloud` (#EFEFEF) is a cloud-gray surface derived from the public award palette. Use it for product stages, side rails, and quiet comparison panels. - `surface-card` (#FFFFFF) is for precise content such as specs, SDK access, form steps, pricing, or documentation. - `surface-warm` (#F3DEC9) adds room-like warmth for onboarding, use cases, and human context. - `surface-play` (#FFE4A8) is a playful accent for demo moments, onboarding chips, and non-critical celebratory states. - `surface-safety` (#DCEEDC) is reserved for safety evidence and compliance-adjacent claims. ### Text - `ink` (#171A1C) is the primary heading and label color. - `body` (#3F464A) is the main reading color. - `muted` (#747C80) is for metadata, captions, tags, and secondary descriptions. Do not use it for required safety or product constraints. ### Hairlines & Borders Use `hairline` (#D7D8D3) for quiet dividers and `hairline-strong` (#B7BDB8) for active product frames, selected audience cards, and safety-critical modules. Borders should feel like precise hardware assembly lines, not heavy SaaS chrome. ### Semantic - `safety` (#6F9F6A) marks safe mode, compliant motion, verified checks, or operator-ready states. - `fun` (#FFB86B) marks playful demos, interaction affordances, and personality cues. Do not use it for safety or success. - `research` (#BCA7FF) can mark lab, SDK, dataset, or experimental content. - `danger` (#D85C4A) is for stops, blocked movement, warnings, failed checks, or unavailable hardware states. ## Typography ### Font Family Use a rounded humanist display sans such as Nunito Sans for headlines and major labels. Use Inter or a system UI sans for body text. The type should feel friendly without becoming childish. ### Hierarchy - `display-xl` is for the main product promise or launch headline. - `display-lg` is for major section claims, not for every card. - `heading-md` names product evidence sections, audience paths, and safety modules. - `title`, `body`, and `label` carry most interface content. - `mono` is for firmware, SDK, sensor, runtime, or inspection metadata. ### Principles Avoid pseudo-technical all-caps voice as the main brand tone. Robotics needs technical trust, but the interface should sound human. Use short headings, concrete labels, and measurable evidence. Examples: - Better: "Soft exterior, compliant control, onboard safety sensing." - Worse: "The future of embodied intelligence starts here." ### Note on Font Substitutes If Nunito Sans is unavailable, use Avenir Next, Manrope, or system UI. Preserve the rounded, open feel through weight and line-height. Keep letter spacing at 0 for display and body roles; use modest uppercase spacing only for small labels. ## Layout ### First Viewport The first viewport must answer four questions: 1. What physical product or robot state is this? 2. Why is it safe around people? 3. Who is this for right now? 4. What can I do next: request, watch, read, build, or inspect? Use an asymmetric hero: one side carries the human promise and CTAs, the other side shows product state. The product stage can be a still, video with poster, 3D model, line drawing, or diagram, but it must be inspectable and not purely decorative. ### Section Order A strong robotics page often works in this order: 1. Hero with physical product and concrete action. 2. Safety-first evidence. 3. Capability modules: locomotion, autonomy, teleoperation, interaction, developer readiness. 4. Audience rails: developers, enterprises, researchers, venues, education, home. 5. Hardware close-ups or modular anatomy. 6. White papers, SDK access, deployment request, or waitlist. ### Grid & Container Use a 12-column desktop grid with generous section rhythm. Product stages can be wide and unframed; spec modules and safety cards should be smaller and precise. On tablet, collapse to 6 columns. On mobile, use a single column with the product visual before or immediately after the headline. ### Whitespace Philosophy Whitespace should feel like a calm room, not a luxury gallery. Leave enough space for the product to breathe, but keep facts close to their claims. Avoid long scrolls of empty brand mood. ### Depth Depth comes from layered product evidence, not from generic shadows. Use: - Soft room-like panels for hero and use cases. - White cards for specific facts. - Thin borders for modules and technical states. - Small shadows only for lifted controls, dialogs, or selected product frames. ## Components ### Request Robot Button Use `request-robot-button` for high-intent actions such as "Request robot", "Request demo", "Join pilot", or "Talk to team". It should be visually decisive but not aggressive. Pair it with a lower-risk action such as white papers or product video. ### White Paper Button Use `white-paper-button` for technical evidence, safety notes, SDK docs, deployment details, or research papers. This button is essential for robotics pages because the user often needs trust before conversion. ### Companion Card Use `companion-card` for capability summaries. Every card should include: - Capability name. - Human outcome. - Technical evidence or current availability. - Optional spec chip or status label. Do not use companion cards for vague brand values. ### Safety Panel Use `safety-panel` for human-contact claims, movement constraints, sensing, soft materials, compliant control, lockout states, supervision requirements, or deployment boundaries. It must include evidence, not only reassurance. Recommended structure: 1. Safety claim. 2. Evidence bullets or status chips. 3. Link to detailed paper, test, or deployment guidance. ### Audience Rail Use `audience-pill` and companion cards to separate audiences. Developers need SDK, simulator, API, and sensor access. Enterprises need deployment, support, safety, and ROI. Researchers need papers, reproducibility, and lab access. Education needs curriculum, supervision, and durability. ### Spec Chip Use `spec-chip` for compact hardware metadata: autonomy, battery, torque class, payload, DOF, beta status, firmware, sensor suite, SDK, simulator, or support region. Keep chips short and scannable. ### Wizard Step Use `wizard-step` for flows such as request a robot, configure a pilot, choose a use case, or join a developer program. The step should expose current status and next action. ## Interaction & Motion Motion can make the product feel responsive, but it must not be the only evidence of intelligence. Use interaction for: - Showing a robot state change: idle, sensing, teleoperated, autonomous, safe-stop. - Revealing a hardware close-up or spec. - Demonstrating an audience path. - Confirming a request, white paper download, or demo booking. Use short easing and restrained transforms. Avoid long character animations that hide content, delay navigation, or turn the robot into a toy. Provide reduced-motion fallbacks with still frames, labels, and clear step order. ## Responsive Behavior ### Desktop Desktop pages can use an asymmetric split: product stage on one side, promise and CTAs on the other. Safety panels and capability cards can form a 3-column or 4-column grid, but every row needs clear labels. Use fixed aspect ratios for product media so loading states do not shift layout. ### Tablet Tablet should move to a 6-column rhythm. Keep the product visual large enough to inspect. Convert audience rails into horizontal scroll or two-column groups with explicit active states. ### Mobile Mobile should show the product object early. Use one-column sections, sticky or repeated CTAs only when they do not cover content, and avoid hover-only interactions. Convert desktop close-up reveals into accordions, tabs, or simple stacked cards. ### Accessibility Robotics content often contains video, motion, and visual demos. Every demo needs text labels and a non-video path. Controls must support keyboard focus. Safety-critical states cannot rely on color, animation, or icon shape alone. ## Case Study Notes The referenced public case is useful because it shows a hard category becoming emotionally approachable. The lesson is not a specific mascot or visual asset; it is the combination of: 1. A concrete product promise: capable, safe, fun. 2. Calm surfaces that make robotics feel domestic rather than industrial. 3. Playful interaction and asymmetry that reduce intimidation. 4. Detailed close-ups and safety language that keep trust intact. 5. Audience-specific routes for developers, enterprises, and researchers. For implementation, translate those ideas into product states, safety panels, SDK links, use cases, and request flows. Do not copy the exact source art direction. ## Agent Usage Checklist When using this resource to generate an interface, start with these decisions: 1. Product stage: real photo, generated image, 3D model, CAD frame, video still, or diagram. 2. Safety evidence: what can be truthfully stated and linked. 3. Audience split: developers, enterprise, research, consumer, venue, education, or support. 4. Capability cards: locomotion, autonomy, teleoperation, interaction, SDK, sensing, deployment. 5. Motion model: which state changes need animation, and how reduced-motion users see the same information. Then produce the page. Do not spend the first viewport on abstract AI slogans. ## Prompt Starter "Use the Companion Robotics Interface as the page-wide visual language: cloud-gray canvas, soft sky-blue capability surfaces, warm domestic panels, rounded asymmetric product modules, visible safety evidence, developer/enterprise/research audience rails, and playful but controlled robot-state interactions. The first viewport must show the physical product or robot state and concrete CTAs; do not copy Fauna Robotics, O0, Sprout imagery, videos, brand marks, or exact choreography." ## Known Gaps This resource is derived from public Awwwards metadata, the live Fauna Robotics site, and O0 case-study writing, not from private design files. Exact typography, component measurements, animation curves, video treatment, and product imagery are inferred into a reusable system. Treat it as a practical interface direction for friendly robotics and physical AI, not a reconstruction of the source site.