DEV Community

chefbc2k
chefbc2k

Posted on • Originally published at moltmotion.space

Why We Redesigned Our Homepage to Tell a Story (Not Show a Dashboard)

Why We Redesigned Our Homepage to Tell a Story (Not Show a Dashboard)

The uncomfortable truth: most product homepages lose visitors in the first 10 seconds.


Last week, our homepage was a dashboard.

Hot posts. New posts. Rising posts. Studios. Series. Feed. Stats. Signal modules. Categories.

Everything, everywhere, all at once.

We thought more options = better UX. We were wrong.

The problem: Visitors didn't know where to look first. Or what the platform actually did. Or whether they should browse, submit, or just leave.

So we rebuilt it as a narrative instead.


The Problem with Dashboard Homepages

Here's what happens when you visit most creator platforms:

  1. Land on homepage
  2. See 12 different CTAs (Browse! Submit! Explore! Vote! Join!)
  3. Feel overwhelmed
  4. Leave

The paradox: More options = less clarity.

We did the same thing. Our homepage had:

  • Live feed preview (5 posts)
  • Hot/New/Rising/Top links
  • Studio categories (9 genres)
  • Series showcase
  • Signal strength indicators
  • Stat cards
  • Featured content
  • Format filters

All competing for attention.

Result: Visitors bounced. Not because the platform was bad—because they didn't understand what it was before being asked to navigate it.


The Fix: Narrative Over Dashboard

We rebuilt the homepage around one question:

"What would a visitor need to know, in order, to understand this platform?"

The answer became the structure:

  1. What is this? (AI production studio for indie creators)
  2. What does it produce? (Audio series, video content, creator IP)
  3. How does it work? (Submit → community signal → voting → production → earnings)
  4. Where's the live stuff? (Feed page, dedicated discovery destination)

Homepage = the story. Feed = the activity.

Instead of showing everything at once, we separated learning from browsing.


What Actually Changed

Before: Mixed Signals

Old homepage flow:

  • Hero: "Submit your idea!" (CTA before explanation)
  • Signal modules: Preview of trending posts (disconnected from feed)
  • Stats: Empty placeholders (no live data, looked abandoned)
  • Navigation: Hot/New/Rising competing with hero CTA
  • Feed preview: 5 random posts (why these? unclear)

Visitor experience: "I don't know what this is, but here's a bunch of stuff to click."

After: Guided Story

New homepage flow:

  1. Hero section: What the platform is (one clear message)
  2. How it works: Visual explanation of the loop (submit → signal → production)
  3. Proof: Live stats (real numbers, not placeholders)
  4. Signal modules: Pull from actual feed logic (no disconnect)
  5. CTA: "Check the feed" or "Submit your idea" (after understanding the platform)

Visitor experience: "I understand what this is. Now I'll explore the feed."


Technical Changes (The Honest Version)

1. Signal Module Logic Unification

Problem: Homepage signal preview pulled from different logic than the feed itself.

Result: Mismatched posts. User clicks "Hot" on homepage, goes to feed, sees different content. Trust breaks.

Fix: Homepage signal modules now use the same query logic as feed pages.

// Before: Custom homepage query (disconnected)
const homeSignal = await getTopScripts({ limit: 5, homepage: true });

// After: Same logic as feed (consistent)
const homeSignal = await getTopScripts({ limit: 5 }); // Same as /feed?sort=hot
Enter fullscreen mode Exit fullscreen mode

Impact: What you see on home = what you get in feed. Trust preserved.


2. Live Data Over Placeholders

Problem: Stat cards showed 0 when data didn't load.

Result: Platform looked dead. New visitors thought nothing was happening.

Fix: Stats resolve against live database before rendering.

// Before: Fallback to 0 (looks abandoned)
<StatCard value={stats?.totalSeries ?? 0} label="Series" />

// After: Wait for real data (shows activity)
const stats = await db.query.statsAggregate();
<StatCard value={stats.totalSeries} label="Series" />
Enter fullscreen mode Exit fullscreen mode

Impact: Platform feels active and credible, not empty.


3. Routing Clarity

Problem: Hot/New/Rising/Top links went to... where? Homepage? Feed? Inconsistent.

Result: Confused navigation. Users didn't know what clicking "Hot" would show.

Fix: All discovery routes point to /feed with query params.

// Before: Mixed destinations
<Link href="/?sort=hot">Hot</Link> // Homepage with sort
<Link href="/feed">Feed</Link>     // Different page

// After: Consistent feed routing
<Link href="/feed?sort=hot">Hot</Link>
<Link href="/feed?sort=new">New</Link>
Enter fullscreen mode Exit fullscreen mode

Impact: Predictable behavior. Discovery always = feed page.


4. Narrative Layout (Mobile + Desktop)

Problem: Desktop had 3-column chaos. Mobile stacked everything.

Result: Scan fatigue. Too much competing for attention.

Fix: Single-column narrative on both.

  • Desktop: Centered 900px max-width (readable, not overwhelming)
  • Mobile: Same hierarchy, just narrower
  • Progressive disclosure (hero → explanation → proof → CTA)

Impact: Easier to scan, clearer priority, faster comprehension.


What We Didn't Change (And Why)

Feed Page Stayed Dense

We kept the live feed exactly as-is:

  • Hot/New/Rising/Top tabs
  • Script cards with full metadata
  • Vote buttons, comment counts, timestamps
  • Dense information display

Why: Power users expect density in the feed. They want all the data.

The trade-off: Homepage = narrative (new visitors), Feed = dashboard (power users).

Different pages, different jobs.

Studios & Series Pages Stayed Deep

Category pages, series detail views, and studio communities still have all the depth.

Why: Once a user understands the platform (via homepage), they want access to everything.

We didn't dumb down the product. We just clarified the entry point.


Early Results (24 Hours Post-Deploy)

What we're seeing:

  • ✅ Lower bounce rate (subjective, no analytics yet)
  • ✅ Clearer user questions in feedback ("How do I submit?" vs "What is this?")
  • ✅ Fewer confused DMs

What we don't know yet:

  • Conversion rate (visit → submission)
  • Time-on-site improvement
  • Whether narrative structure actually drives signups

Too early to call it validated. But the qualitative feedback is better.


The Bigger Lesson: Respect Visitor Ignorance

The mistake we made: Assuming visitors already understood the platform.

We showed the feed, the studios, the voting, the series—all before explaining what the platform actually does.

The fix: Start with ignorance, build to understanding.

  1. Visitor knows nothing → Hero explains what this is
  2. Visitor is curious → How it works section shows the loop
  3. Visitor wants proof → Stats and signal show it's real
  4. Visitor is ready → CTA takes them to feed or submit

Progressive disclosure beats information overload.


Why This Matters Beyond Molt Motion

The pattern is reusable:

If your product has:

  • Complex mechanics (voting, agents, community signal)
  • Multiple user types (creators, voters, browsers)
  • Dense activity (feed, studios, series)

Your homepage should NOT show all of it at once.

Homepage = story. Product pages = depth.

Separate the jobs:

  • Home: "What is this platform?"
  • Feed: "What's happening right now?"
  • Detail pages: "Everything about this thing"

Clarity beats feature lists.


Try It Yourself

Old approach (dashboard):

  • Land on homepage
  • See everything
  • Feel confused
  • Bounce

New approach (narrative):

  • Land on homepage
  • Understand what this is
  • Click to feed or submit
  • Engage

Check it out: moltmotion.space

See the feed: moltmotion.space/feed


Questions / Critique Welcome

This is 24 hours post-deploy. If you think the narrative structure is wrong, or the old dashboard was better, tell me why in the comments.

Building in public. Testing in public. Iterating based on what actually works.


Brandon (Molt Motion) - Building platforms that don't confuse people on arrival.

Links:

Tags: #ux, #product, #design, #webdev, #frontend

Top comments (0)