I Redesigned RootstockCollective’s Contributor Onboarding Experience. Would Love Your Thoughts!

General
1

Hey RootstockCollective community :waving_hand:t4:

I explored how onboarding could feel clearer for new contributors entering the ecosystem, and for this concept, I redesigned the contributor onboarding experience for RootstockCollective, focusing on:

  • onboarding clarity

  • governance accessibility

  • contributor pathways

  • staking UX

  • and RSK identity ownership

Come build.PNG
Come build.PNG1920×1200 193 KB

One thing I noticed immediately was how many unfamiliar concepts new users encounter within minutes.

Terms like:

  • DAO

  • sidechain

  • merge mining

  • builders

  • backers

…can feel intimidating for first-time contributors.

SOLUTION 1

So I introduced lightweight educational cards to simplify key concepts and reduce friction.

Another challenge was ecosystem fragmentation.

As a first-time contributor, I constantly had to mentally connect:

  • Bitcoin

  • Rootstock

  • RootstockCollective

  • governance

  • contributors

SOLUTION 2

So I simplified the ecosystem structure into layers to make participation easier to understand using layers:

Layer 1 → Bitcoin
Layer 2 → Rootstock
Layer 3 → RootstockCollective

I also surfaced ecosystem activity and participation metrics more clearly to help the ecosystem feel active, transparent, and approachable.

SOLUTION 3

One thing I realized:

Many DAO platforms explain protocols better than they explain people.

So I expanded contributor pathways beyond just “builder” and “backer” to include:

  • designers

  • developers

  • educators

  • writers

  • community contributors

The goal was to help contributors instantly feel like they belong too.

I also wanted onboarding to feel guided instead of research-heavy.

SOLUTION 4

So I introduced:

  • a lightweight “Start Here” flow

  • onboarding steps for first-time contributors

Because participation should feel approachable, not intimidating.

SOLUTION 5

I introduced a demo staking experience users can safely interact with before engaging with the real ecosystem.

Users can:

  • connect a demo wallet

  • adjust staking percentages

  • drag staking sliders

  • and simulate participation visually

The goal was to reduce fear, confusion, and hesitation around staking mechanics for first-time contributors.

Governance participation was another important part of the experience.

So I connected live proposal interactions directly into the onboarding journey.

Users can:

  • explore active proposals

  • understand governance activity

  • and transition directly into participation

The goal was to make governance feel accessible instead of distant or overly technical.

As I continued exploring the ecosystem, I started thinking beyond onboarding alone.

I began asking:

SOLUTION 6

What makes participation feel personal?

Because contributor ecosystems aren’t just about governance mechanics.

They’re also about identity and belonging.

That led me to explore how ownership and digital identity could become part of the onboarding experience through RSK domains.

Overall, the UX problem wasn’t visual quality.

The community already had strong infra & foundations.

The opportunity was improving:

  • onboarding clarity

  • contributor understanding

  • governance accessibility

  • ecosystem discoverability

  • identity & participation

Especially for first-time contributors entering Bitcoin ecosystems.

Excited to keep contributing and exploring this space.

Hey, I also made a detailed walkthrough video explaining my full design process and approach:

​​https://youtube.com/shorts/S45L56f8P74?si=n5qfuNTNjtk2O3MJ

X handle here: https://x.com/adedamolajoke/status/2057109040300233088?s=46&t=ydgECxoBWwIqxzr4W_jEGg

2 Likes
2

Hi @adedamolajoke appreciate you taking the time to research and redesign the onboarding UX for Rootstock Collective dApp. To fully say it’s a problem, it would help to show some validation of the assumption, whether that’s user data, drop-off metrics, or something similar. But it’s still great that you pointed this out based on your observation, it’s valuable and could help inform the Rootstock team to improve specific parts.

All of your solutions point to the same core question: “How do we make onboarding easier for new users who aren’t yet familiar with Rootstock?” We’ve reviewed all of your solutions and want to share our perspective. We’ll go through each one on what we think is worth pursuing, what might not be necessary, and where some could be tweaked to add more direct value.

First solution: We think this is worth pursuing. If the core problem is that Rootstock is difficult to understand for new users, educational cards are a simple, low-cost fix that the Rootstock team could implement directly. Sometimes the simplest solution is the best one, and this is one of those cases. It could also complement the second solution well, together they give new users a clear mental model of how everything works and connects. We think both solutions should be combined into a single section, something like “The Rootstock Primer,” which would create a clear introduction to the ecosystem for new users.

We have one question on your second solution: in the image you posted on Twitter, you included “Working Group” as part of the ecosystem structure. Could you clarify what that refers to? We don’t think that’s an existing structure within the Collective, so we’d love to understand what you had in mind there.

Third solution: We think this adds complexity without a clear need. The Collective Rewards mechanism already has two well-defined roles:

  • Builder: a project that goes through the delegate review and approval process and can earn rewards.
  • Backer: a user who stakes RIF to receive stRIF and allocates it to builders based on performance and reward-sharing percentage.

Adding labels like designer, developer, writer, or educator doesn’t meaningfully simplify the experience, and could actually create more confusion, since all of those roles already fall under the Builder category as it stands. The mechanic is set by the protocol, so expanding the vocabulary without aligning with the underlying structure doesn’t add value.

Fourth solution: This risks creating redundancy with onboarding resources that already exist on the website. More importantly, a guided checklist-style flow can make participation feel like a task to complete rather than something to genuinely explore. We think users are better served by actually using the ecosystem than by being walked through a structured sequence before they get there.

Fifth solution: We appreciate the direction here, but the staking portal within the Rootstock dApp already shows estimated rewards per builder based on your total stRIF allocation. The core functionality you’re proposing to demo already exists in a live form. Building and maintaining a separate demo environment would carry significant cost, and since it mirrors what’s already available, we don’t think the investment is justified.

Sixth solution: The intent to keep users informed about what’s happening in the ecosystem is valid, but a dedicated summary page on the website may not be the most effective channel. Users aren’t likely to revisit an activity summary page regularly. Rootstock already covers this through existing channels, forum users receive activity summaries by email and can get notified on specific topics they follow. Discord mods regularly ping the community about live proposals and new forum posts, and there’s Telegram as well. Adding another surface for this could actually work against “participation” by making it feel passive rather than active.

Taken together, many of these solutions are attempting to solve the same problem through different functions, when a simpler approach already covers the core need. Solutions 1 and 2 combined address the actual gap most directly, giving new users a clear and approachable mental model of what Rootstock is before they dive in. We’d encourage focusing energy there.

One thing we’re also curious about: what’s the direction you’re aiming for with this? Is the goal to develop this into a grant proposal, or more to surface these observations and let the Rootstock team take it from there?

2 Likes
3

Cool! Thank you @adedamolajoke for taking the time to work on this. Its been good food for thought for me :slight_smile:. As @Curia asked, I’m also curious what next steps, if any, you had in mind for this work.