Curating Frontend Inspiration
Before writing any frontend code, spend 10 minutes browsing curated references to establish a visual direction. Pick one primary component library, one animation library, and 1-2 inspiration sources — don't mix five different design languages into one project.
Design direction checklist:
1. Component base: kokonutui.com OR magicui.design OR reactbits.dev
2. Animation layer: motion.dev (UI micro-interactions) or animejs.com (creative/complex) or threejs.org (3D/WebGL)
3. Layout/interaction inspiration: collectui.com (search specific patterns like "onboarding", "empty state")
4. Dashboard reference: bklit.com (if building admin/analytics UI)
5. Open-source code reference: kage, towers, sketchbook (Meng To's projects) for design-engineering craft
Progress:
- Step 1: Define the product's visual personality (minimal/technical, playful/bold, editorial/content-heavy)
- Step 2: Pick ONE component library as the base system
- Step 3: Pick ONE animation library matched to complexity needs
- Step 4: Search CollectUI for the 2-3 specific UI patterns needed (nav, forms, cards, empty states)
- Step 5: Study one reference site end-to-end (not just screenshots) — inspect spacing, timing, transitions
- Step 6: Build a small interactive prototype of the signature interaction before building the full page
- Step 7: Review against "Common Pitfalls" before shipping
Choosing a component library
- kokonutui.com — modern, animated, opinionated components. Good default for SaaS/product sites.
- magicui.design — marketing-site focused (hero sections, bento grids, text effects). Good for landing pages.
- reactbits.dev — granular, copy-paste React primitives with built-in animation. Good when you need one specific effect, not a whole system.
Choosing an animation approach
- motion.dev (formerly Framer Motion) — default choice for React UI: page transitions, hover states, layout animations. Use
motion.dev/ai-kitif generating animation code via AI to keep output idiomatic. - animejs.com — framework-agnostic, best for complex timeline-based sequences (SVG morphing, staggered choreography) outside typical component states.
- threejs.org — only when the design genuinely needs 3D/WebGL (particle fields, 3D product viewers). Don't reach for this by default — it's the most expensive in dev time and performance cost.
Dashboard-specific work
Reference bklit.com for data-dense layouts: chart placement, sidebar density, metric card hierarchy, dark-mode contrast handling. It ships components — inspect its DOM/CSS rather than only screenshotting.
Studying open-source references (Kage, Towers, Sketchbook)
These are Meng To's projects (Design+Code) — study them for engineering-level design craft:
- Consistent spacing scale and type system across every screen
- Restrained animation (used for feedback, not decoration)
- Component composition patterns (how small primitives combine into full screens)
Clone and read the source, don't just view the live demo.
Example 1: Input: "Build a landing page for a dev tool startup" Output: Base components from magicui.design (hero, bento grid, marquee logos) + motion.dev for scroll-triggered fade/slide-ins + one CollectUI search for "pricing table" patterns to avoid a generic 3-column pricing grid. No Three.js — a dev tool audience values fast load over 3D flourish.
Example 2: Input: "Build an analytics dashboard for a B2B app" Output: Study bklit.com's component structure for sidebar nav + metric cards + chart containers. Use kokonutui.com for the data-table and dropdown components. Motion.dev only for number count-up and tab-switch transitions — nothing decorative given the data-dense context.
Example 3: Input: "Add a distinctive hero interaction to make the site memorable" Output: Prototype the interaction in isolation first using anime.js (if timeline-based, e.g., staggered SVG line draw) or reactbits.dev (if it's a self-contained effect like a text scramble). Only integrate into the full page once the interaction feels right at 60fps.
- Pick one system, commit to it. Mixing component libraries creates visual inconsistency (different border-radius scales, shadow styles, spacing units) — a top signal of "AI slop."
- Motion should communicate state, not decorate. Every animation should answer "what changed?" (loading, success, focus, navigation) — not just "make it feel alive."
- Match animation cost to actual need. Three.js/WebGL only when 3D is core to the product story; otherwise it's wasted performance budget.
- Study real sites' code/DOM, not just screenshots — spacing rhythm and timing curves are invisible in static images but are what separates polished work from generic templates.
- Establish a spacing/type scale before touching components — inconsistent scale is the fastest way to make a component-library site look assembled rather than designed.
- Combining components from 3+ different libraries with mismatched border-radius, shadows, and font stacks.
- Adding animation to everything (every card hovers, every icon spins) — this reads as generic/AI-generated rather than intentional.
- Reaching for Three.js/WebGL as a default "make it look cool" move instead of a deliberate choice tied to content.
- Copying a hero section pixel-for-pixel from inspiration without adapting it to the actual content and brand — recognizable "magicui hero #3" syndrome.
- Skipping the prototype step and building signature interactions directly inside the full layout, making iteration slow and expensive.