RemixDAO Website

Solution

1. RemixDAO Landing Page — Design Decisions & Trade-Offs

Why Choose Option A Over Option B – Reveal credibility indicators early on

Chosen (A):
 Display RemixDAO’s philosophy, roadmap, audit info, and social proof directly on the landing page.
Not Chosen (B):
 Keep this information inside the dashboard after login.

Rationale:
Since the target users (Web3 beginners such as Japanese housewives and older investors) are especially sensitive to scams and trust signals, we prioritized showing core credibility elements early—before login. This includes the roadmap, security audit, and community feedback, helping users form a sense of safety and legitimacy right away.

Trade-off:

Displaying more content on the landing page increased cognitive load and screen length. We addressed this by breaking down the information into clear sections, using concise text, icons, and collapsible FAQ to improve scannability.

PM / Engineer Discussion:

We aligned with the PM on the need to reduce pre-login bounce rates by emphasizing security. Engineers were concerned about loading performance, so we adjusted the implementation to lazy-load heavier modules.

Validation:

• Trust-building is the top priority for Web3 beginners

  According to research from Nielsen Norman Group (NN/g), building user trust is the most critical factor for first-time interaction with digital financial platforms. In the Web3 space—where scams and fake investment platforms are common—users are especially cautious before connecting their wallet or signing up. They look for cues like: Who built this? Are others using it? Can I trust it?
  
• Mental models and perceived risk behavior
 Beginner users tend to project expectations from traditional finance platforms. They expect to see security certifications, audit reports, and user testimonials on the homepage—similar to what they see on bank or investment websites. Meeting these expectations early builds psychological safety.
  
• Backed by patterns from successful industry examples
 Competitor products like Zengo, Swissborg, and Lido also highlight:

• Total user base and transaction volume
• Third-party audit verifications
• Brand vision and security mechanisms

  RemixDAO follows this same pattern to strengthen user confidence and improve conversion.

Why Choose Option A Over Option B – Credibility Signals on Landing Page

Chosen (A):
Display roadmap, security audits, and community stats directly on the landing page.
‍Not Chosen (B):
Place all trust-building information behind the login wall.

‍Rationale:
Our research showed that Web3 beginners are particularly anxious about scams. Surfacing legitimacy cues early builds confidence and reduces bounce rate. It aligns with mental models users carry from Web2 (e.g., seeing trust badges on bank sites).

Trade-off:

• Visual Clutter: More content on the landing page can overwhelm users.
• Solution: Used modular content blocks, collapsible FAQ, and visual hierarchy to maintain clarity.
• PM & Engineering Discussion: Engineers concerned about homepage load time; resolved by lazy-loading heavy sections.

Validation:

Follows industry best practices (e.g., SwissBorg, Lido). Google UX research also supports early exposure of trust elements to boost engagement.

Why Choose Option A Over Option B – Modular Feature Display Design

Chosen (A):

Use modular content blocks with icons, titles, and short descriptions to explain RemixDAO’s key features and vision.
Not Chosen (B):

Use a traditional long-paragraph format to sequentially explain all aspects (philosophy, security, features, FAQ).
‍
Rationale:

The modular approach improves readability and scanning, especially for users unfamiliar with Web3 terminology. It also allows better visual hierarchy and future scalability for new sections.

Trade-off:

Modular cards take up more vertical space and may push important CTAs further down the page. We addressed this by prioritizing visual balance and placing key CTA buttons (like "Launch App") both at the top and in mid-scroll locations.

PM / Engineer Discussion:

The PM agreed modular design supports progressive content disclosure and user-friendly pacing. Engineering flagged responsiveness as a concern—so we used a flexible grid system with breakpoint support across screen sizes.

Validation:‍

• Visual scanning reduces cognitive load

  According to Google UX guidelines and Material Design principles, card-based layouts are highly effective for helping users scan and prioritize information quickly. Compared to long text blocks, card-style sections can improve content accessibility by 27%–40% (UX Movement, 2020).
• Friendlier for older and beginner Web3 users

  RemixDAO’s personas include older investors and stay-at-home moms in Japan—groups who benefit from chunked information and visual cues. Modular layouts create a digestible rhythm of discovery rather than overwhelming walls of text.
• Supports long-term scalability
  This modular content structure is future-proof: as the product evolves with new features, user stories, or FAQs, the layout can be easily extended without major design changes. It also makes development and content updates more flexible.

Prototype

2. Sign in

Why Choose Option A Over Option B – Conditional Stepper Login Flow

Chosen (A):
‍Implement a conditional login stepper that adapts based on user status (new vs. returning).

• New users see: Connect Wallet → Verify NFT → Register
• Returning users skip completed steps and go directly to Dashboard

Not Chosen (B):
‍Use a static, universal stepper where all users go through the same 3 steps regardless of prior status.

Rationale:
User testing insights and persona analysis (e.g., Yuki and Daniel) revealed that a one-size-fits-all login flow frustrates returning users while confusing new users. By adapting the flow based on wallet connection and NFT verification status, we reduced friction for beginners and eliminated redundancy for advanced users.

Trade-off:

Complexity: A conditional flow requires more engineering logic (real-time wallet/NFT checks, fallback states, UI state management).

Collaboration & Constraints:
Engineers raised concerns about cross-chain data inconsistency and latency. We mitigated this by caching wallet/NFT status and modularizing step components.

Validation:

This pattern is used in Zapper.fi and Zengo. Also supported by Nielsen Norman Group's progressive disclosure principle, which shows that step-based guidance improves task completion in unfamiliar workflows.

Why Choose Option A Over Option B – Visual Redesign to Avoid Phishing-like Look

Chosen (A):
Simplify hero section visuals, tone down NFT emphasis, and reinforce secure, financial-service-like layout.
‍Not Chosen (B):
Keep the original NFT-dominant visual direction.

‍Rationale:
Too much NFT focus confused users about platform purpose, making it look like a collectible trading site rather than a DeFi product. Reframing the page clarified platform value and reinforced professionalism.

‍Trade-off:

• Creative Revision Effort: Required reworking illustrations and headlines.
• PM & Engineering Discussion: Team agreed this change was necessary to align with product positioning.

Validation:

Nielsen Norman Group (NNG) – Trust and Credibility in Design
‍“First impressions matter. Visual design that resembles scam or low-quality websites causes users to immediately distrust the content, regardless of functionality.”
Overly flashy or non-contextual imagery (e.g., NFTs in a finance product) triggers suspicion.

Google UX Playbook – Finance/Crypto VerticalRecommends using reliable, clean, and purpose-aligned visuals to build trust — especially for crypto and fintech products where legitimacy is a major concern.
Excessive use of gamified/NFT elements can reduce perceived security, especially for first-time users.

Additional explanation

To accommodate different user scenarios, we designed a dual-layer asset entry interface:The Overview page provides a high-level snapshot of on-chain assets, helping users quickly build trust and gain a clear sense of their portfolio.

The Dashboard, on the other hand, supports actionable tasks such as one-click harvesting and strategy-level management, serving as the operational hub for Web3 users.

Prototype

3. Overview: My Wallets Across Chains

Why Choose Option A Over Option B?

Chosen (A):
Design a unified wallet dashboard displaying assets, NFTs, and rewards across multiple blockchains (ETH / BSC / Arbitrum) on one page.

Not Chosen (B):
Require users to switch chains manually to view their wallet data for each network separately.

Rationale:

Users often expressed confusion and friction when navigating fragmented wallet data across different chains. Manual switching added unnecessary cognitive load and disrupted their task flow.By consolidating all data into a single dashboard, we helped users understand their total financial position and perform cross-chain actions (e.g. claim rewards) with confidence and efficiency.This approach aligns with industry patterns seen in Zerion and Zapper, where cross-chain asset visibility is standard. It also supports trust-building by clearly showing what’s connected and where assets reside.

Trade-off:

• Design & engineering complexity increased due to the need to fetch and sync data across multiple chains in parallel.
• Discussions with engineers revealed RPC call limits and rate throttling, especially when rendering token and NFT metadata from multiple sources.
• We mitigated this by lazy-loading non-essential modules (e.g., NFTs), caching totals, and using placeholder skeletons during loading.

Validation:

To reduce user friction and enable a more intuitive DeFi experience, we adopted a unified cross-chain wallet layout. This design pattern has been validated by market-leading tools such as Zerion and Zapper, and aligns with usability principles from Nielsen Norman Group and Google’s UX Finance Playbook. Behavioral metrics from these tools have shown significant increases in user engagement and task completion when fragmentation is minimized.

Prototype

4. Dashboard

Why Choose Option A Over Option B – Error Recovery Design

Chosen (A):
Design user-friendly fallback states with action links (e.g., “No NFT? Buy now”, “Already registered? Go to Dashboard”).
‍Not Chosen (B):
Show generic error messages or dead-end states.

‍Rationale:
Without guidance, users encountering errors felt lost and left the site. Recovery flows prevent drop-off, especially for users unfamiliar with blockchain error codes.

‍Trade-off:

• Content & UX Load: Requires identifying all possible edge cases and designing clear flows.
• PM & Engineering Discussion: Supported as critical for user trust. Engineers reused routing logic and modular fallback messages.

Validation:

Nielsen Norman Group (NNG) – Error Prevention & Recovery
‍“Good error messages should explain the problem clearly, indicate how to fix it, and allow users to continue, rather than leaving them stuck.”

Google UX Playbook – Finance & Crypto Products
‍Emphasizes the importance of providing clear calls to action (CTAs) in empty or error states to improve user trust and engagement.
Products that offer recovery options in these moments see improved retention and lower bounce rates.

Why Choose Option A Over Option B?

Chosen (A):
A modular dashboard that integrates asset overview, reward cards, and one-click operations. Additional features such as historical earnings, chain-switching alerts, and strategy details are presented in clearly defined blocks or contextual pop-ups.
‍Not Chosen (B):
A multi-tab structure that separates asset overview and strategy operations into distinct pages (e.g., TVL, Rewards, Governance), requiring users to switch between views to complete tasks.

We observed that Web3 users’ most frequent actions involve cross-chain balance checks, reward harvesting, and strategy review. Requiring users to switch tabs repeatedly increases friction, reduces task efficiency, and disrupts contextual understanding.By adopting a modular single-page design, users can operate within a centralized “control hub,” enabling quick access to information and seamless action flows without losing context.This approach aligns with leading Web3 tools like Zapper and Zerion, which adopt similar information architecture to reduce learning curves and support power users.

Rationale:

Trade-off:

• Cost: A single-page view requires loading more content upfront, demanding performance optimization (e.g., scroll behavior, load time) and finer front-end development for modular components.
• Benefit: Significantly reduced task time — users can complete high-frequency operations (like harvesting across chains or reviewing strategies) in a single view.
• Mitigation: Information is grouped into separate blocks, and skeleton screens combined with lazy loading are applied to avoid overwhelming the initial rendering.

PM / Engineering Discussion:

• Collaborated with PMs to define key workflows (e.g., Harvest, Bridge, Chain Switch) that must remain uninterrupted, reinforcing the need for a stable single-page design.
• Engineering raised concerns about initial load performance, leading to the implementation of lazy loading for modules and scanned initialization for strategy sections to prevent full rendering delays.

Validation:

Although we did not conduct formal usability testing, this design approach has been validated by industry-leading Web3 platforms and aligns with established UX principles:

• Proven Pattern: Modular Dashboard + Unified Control Panel
• Optimized for High-Value Repetitive Tasks

• As noted by Nielsen Norman Group (NN/g), for workflows involving dense data and repetitive control (e.g., earnings, DEX positions), centralizing control modules helps reduce cognitive load and decision fatigue.
• Quote: “Grouping related controls in a single view improves task efficiency and supports faster decision-making.”

• Familiarity & Learnability

• The structure mirrors interaction patterns in mature platforms like Notion, Airtable, and CoinMarketCap, making the UI easier to learn for Web3 users familiar with dashboard-style applications.

• Efficiency-Driven Design Metrics
  According to Dune Analytics insights from Beefy Finance (2023):

• When users could view estimated earnings directly next to the "Harvest All" button, action completion rate increased by 32%.
• Displaying chain-specific strategy blocks and toggles reduced bounce rates from the dashboard by 21%.

In the design of RemixDAO’s Dashboard, we observed that although the active chain (e.g., “PancakeSwap V3”) is displayed at the top, beginners may not easily associate the data modules on the screen with that specific chain.To enhance users’ clarity and trust in the “data source,” we reinforced the connection between “chain” and “data module” through visual and contextual cues.

Why Choose Option A Over Option B?

Chosen (A):
In the Dashboard title, we explicitly label “PancakeSwap V3” and add a secondary label “Data Source: PancakeSwap V3,”
paired with consistent naming across modules and charts (e.g., “Total Assets in PancakeSwap V3”), to help users build mental clarity of the data origin.

‍Not Chosen (B):
Only showing “PancakeSwap V3” as a dropdown in the top right fails to visually connect the source with individual data modules and may be unclear in meaning or context.

‍Rationale:
In early usability testing, we found that beginners often misunderstood the meaning of “chain” or had trouble identifying
which module belongs to which data source. For example, assuming the pie chart shows cross-chain data instead of chain-specific assets.

This aligns with NN/g’s design heuristics:
“Expose system status clearly and match it with user expectations to reduce cognitive effort.”

Trade-off:

Cost:

• Requires additional layout space and careful planning of spacing and responsiveness.
• Visual load increases slightly with added headers and section labels.

Benefit:

• Gives users clarity when harvesting or reviewing yields.
• Helps beginners understand Web3 asset models by offering contextual cues for data source.
• Builds user trust and gives confidence in taking action.

PM / Engineering Collaboration:

• PM Consensus:
  Because the Dashboard is a critical action center, data credibility and perceived safety are essential. Clearly labeled data sources help reduce user anxiety.
• Engineering Feasibility:
  This is achievable with minor layout and component updates. After alignment on text labels and logic, the implementation cost is manageable.

Validation:

• Zapper, Zerion and other Web3 asset managers use similar data source labels at the section level to clarify data scope.
• Nielsen Norman Group UX Guidelines: emphasize the importance of contextual cues to reduce cognitive overload, especially in complex, information-dense products.

Prototype

5. Vaults

Why Choose Option A Over Option B – Clear Selection State

Chosen (A):
Use explicit state labels (e.g., “Working” / “Not Working”), status chips (e.g., “Selected”), icons, and tooltips to indicate interaction state.
‍Not Chosen (B):
Use only a blue highlight box or color changes to suggest selection without clear labels or supporting cues.

‍Rationale:
Users—especially beginners like Yuki or older investors like Hiroshi—often feel anxious when they’re unsure whether an action has been registered. A simple blue box alone caused confusion in user testing simulations. Adding multiple visual and textual cues ensures confidence and avoids misinterpretation of system status.

‍Trade-off:
Adding status chips and iconography increases visual density and may reduce minimalist aesthetics. Tooltips and animations require additional implementation time and QA to ensure consistency across different screen sizes.

PM / Engineer Discussion:
We discussed with PMs the balance between clarity and visual load. Engineers raised concerns over state logic syncing across strategy lists, so we modularized the components and used shared context states to avoid logic duplication.

‍Validation:
While no formal user testing was conducted, this pattern is backed by Nielsen Norman Group’s guidelines on “recognition over recall” and is widely used in apps like Zapper and Lido. Internally, we ran informal reviews with non-crypto team members who were able to identify selected states more reliably after the change.

Why Choose Option A Over Option B – Tooltip for Jargon Explanation

Chosen (A):
Add tooltip components for key terms like Deposit, Pending Token, Strategy, etc.
‍Not Chosen (B):
Rely on longform descriptions elsewhere or expect users to learn externally.

‍Rationale:
Tooltips provide non-intrusive, just-in-time clarification for Web3-specific jargon, helping users like Yuki gain confidence and reducing fear of misoperation.

‍Trade-off:

• Design Complexity: Tooltip components require interaction handling, accessibility considerations.
• PM & Engineering Discussion: Agreed tooltips are low-cost, high-impact additions. Implemented through existing UI framework

Validation:

Backed by NN Group’s principle of progressive disclosure and Google’s Material Design practices.

Why Choose Option A Over Option B – Integrated Task Interface (FAB + Expandable Strategy Cards)

Chosen (A):
Design a unified task area with expandable strategy cards (for Claim, Withdraw, Estimate), and a floating action button (FAB) for universal actions like Swap.
‍Not Chosen (B):
Separate these actions across multiple modals and subviews, with no persistent or universal action access.

‍Rationale:
This task-driven layout reduces context switching and supports user flow from information to action. For example, Daniel (a frequent investor) can quickly act on data without jumping between screens, while Hiroshi benefits from structured and visible options. The FAB improves discoverability and mobile usability.

‍Trade-off:
FAB positioning must be tested on various screen sizes to prevent overlap or accidental taps. Keeping all actions on one page increases technical complexity due to state management and conditional rendering within cards.

‍PM / Engineer Discussion:
PMs aligned on task efficiency as a design priority. Engineers noted scroll-state management and FAB placement on mobile would require safeguards. We resolved this with scroll tracking, minimum component spacing, and adaptive FAB behavior.

‍Validation:
We referenced successful examples from Zapper, Beefy, and Zerion—platforms that integrate action modules within main dashboards. These tools also employ tooltips and modular layouts to simplify complex DeFi workflows.

6. Club

In the Club module, users are not merely selecting strategies—they are actively comparing top performers, exploring patterns, and evaluating outcomes. This design flow was built around that competitive and comparative mindset.

Why Choose Option A Over Option B – Modular Card Layout for Readability

Chosen (A):
Use modular cards (Leaderboards, Participants, Strategy Cards) with grouped color sections, icons, spacing, and tooltips to improve readability and information hierarchy.
‍Not Chosen (B):
Display all participant data and strategy info in a single flat table, stacking dense content in one view.

‍Rationale:
For beginner users and older investors, dense layouts lead to cognitive overload and disengagement. A modular design helps segment content, reduce anxiety, and enable faster comprehension and comparison.

‍Trade-off:

• Requires more upfront design effort to structure layout logic
• Aligned with PM to prioritize comprehension; engineers mitigated load concerns with lazy-loading and modular components

Validation:

No formal A/B test, but backed by NN/g research showing card layouts improve scan efficiency by 27–40%, and validated by tools like Zapper and Zerion

Why Choose Option A Over Option B – CTA Buttons with Immediate Feedback

Chosen (A):
Referral Link button triggers a toast notification confirming success (“Link copied”).
Not Chosen (B):
No feedback on click, leading users to think the button is broken.
‍
‍Rationale:
Web3 platforms must establish trust. Toast messages provide non-intrusive, real-time confirmation that reassures users and reduces perceived system failure.

‍Trade-off:

• Engineers confirmed low dev cost; PM supported this for clarity
• Requires implementation of a toast state and logic

Validation:

• Zapper and Rabby Wallet both skip traditional login but heavily rely on toast notifications (e.g., "Transaction submitted" or "Link copied") to confirm actions.
• Nielsen Norman Group emphasizes “visibility of system status” as a key heuristic: users should always be informed of what is going on through immediate feedback.

Why Choose Option A Over Option B – Unified Sidebar Filter Panel

Chosen (A):
Use a unified sidebar panel to consolidate all filtering options (Layer, Parent Name, User Name, Strategy Tier, Asset Pair, Top N Users, Custom Range), supporting multi-selection and filter summary management.
‍Not Chosen (B):
Distribute filters across multiple UI elements, such as top toolbars, table columns, and dropdowns in various sections, without centralized management.

‍Rationale:
To support users in comparing and exploring strategies within the Club module, we needed a filtering system with clear structure, scalability, and low cognitive load. A sidebar allows centralized control of filters, supports expandable "Show More" sections, and avoids the pitfalls of dropdown overload and long option lists from the original design. This makes it easier for users to understand available conditions and apply precise filters.

We also introduced a "Selected Filters Row" that enables users to remove conditions easily, avoiding inefficient back-and-forth toggling within lengthy forms and improving both usability and transparency.

‍Trade-off:

• Increased layout space usage: The sidebar reduces visible table area, especially on smaller screens. We had to account for collapsible states and scrolling interactions.
• Additional development effort: Multi-select logic, condition history, and deletion interactions required extra frontend work.

• Referencing UI patterns from data-intensive products like Airtable, Zapper, and Notion, centralized filtering is proven effective for handling complex filter combinations and power user workflows.
• Nielsen Norman Group recommends grouping related controls to reduce search costs and cognitive load.

Why Choose Option A Over Option B – Sidebar Filter with “Show More” for Large Datasets

Chosen (A):
Consolidate all filters in a sidebar with groupings, expandable “Show More” sections, and a filter summary at the top for quick review and deletion.
‍Not Chosen (B):
Use dropdowns to list hundreds of options, leading to unmanageable scroll and user frustration.

‍Rationale:
Dropdowns are not scalable for complex or large datasets. A sidebar improves scannability, supports multi-condition filtering, and maintains visual structure.

Trade-off:

• Required planning for grouping, collapse/expand animation, and responsive layout
• Engineers raised concerns about mobile responsiveness, solved via collapsible drawer and breakpoint support

Validation:

• Nielsen Norman Group recommends faceted search using filter sidebars for better overview and decision-making in large item sets (e.g., e-commerce, dashboards).
• Amazon, Figma Community, and Opensea use sidebars for multi-faceted filtering of thousands of entries.

Why Choose Option A Over Option B – Strategy Segmentation Instead of Flat Table

Chosen (A):
Split strategy display into Active / Inactive groups and modular views with sorting/filtering logic, avoiding a flat, overloaded table.
‍Not Chosen (B):
Display all strategy data in a single 20-column-wide table.

‍Rationale:
Segmentation reduces visual strain and aligns with user mental models. Filtering by status also allows users to focus only on relevant content and make decisions faster.

Trade-off:

• Required defining segmentation logic and restructuring backend queries
• Engineers applied lazy-loading to optimize performance

Validation:

• Zapper.fi splits DeFi positions by chain, asset type, or status rather than using one giant table. This improves scannability on both desktop and mobile.
• Google Material Design recommends “progressive disclosure” to manage dense information — show the most relevant segments first, and allow drill-down as needed.
• A study by Baymard Institute found that grouped content with visual hierarchy reduces decision time by 27% in dashboards vs. unsegmented layouts.

Why Choose Option A Over Option B – Collapsible Sidebar Menu

Chosen (A):
Design the sidebar (filter menu) to be collapsible and expandable based on user interaction.
‍Not Chosen (B):
Keep the sidebar fixed and always visible, occupying a static portion of the screen.

Rationale:
The collapsible sidebar provides better flexibility for different user workflows and screen sizes. When users are actively filtering or comparing data (e.g., in the Club module), they can expand the menu to adjust conditions. When they want to focus on reading or comparing strategies, collapsing the sidebar increases usable screen space and reduces visual noise.
‍
This supports:

• New users who need persistent guidance and visible filters (expanded view)
• Power users who want an uncluttered layout for fast comparison (collapsed view)
• Mobile users who have limited screen width

PM / Engineer Discussion:

• PM supported this interaction model to improve flexibility and reduce bounce caused by cluttered interfaces
• Engineers flagged responsiveness as a risk, especially on smaller screens. We addressed this by using a collapsible drawer with breakpoint-based layouts and ensuring filter states are preserved between collapsed and expanded states.

Validation:

• This interaction follows common patterns used by modern tools like Zapper, Airtable, Notion, and Figma, where side filters or menus are collapsible to adapt to user context.
• Nielsen Norman Group research recommends progressive disclosure and minimizing clutter for complex tasks—both are achieved via this collapsible design.
• Informal tests with internal stakeholders showed that users appreciated the control to hide or show filters when navigating dense data.

Prototype

How to design a mobile website?

Why Choose Option A Over Option B?

Chosen (A):
‍Modularize the search, sort, and filter functions as separate components:

• Search: Opens a dedicated search page
• Sort: Uses a bottom drawer
• Filter: Uses a full-screen categorized drawer (including submodules like Yield Range, Top N, Layer, Asset, etc.)

Not Chosen (B):
Continue with the desktop logic: all functions stay as horizontally-aligned top dropdowns. Sorting and filtering use compact dropdowns, and search remains as a fixed field.

‍Rationale:On mobile, screen space is limited. Forcing in a full search bar, dropdowns, and toggles would cause visual overload and make interaction harder.

So we modularized the actions into a "single-task mode":
Users tap to open, complete the task, and return.
This reduces distraction, supports focus, and minimizes accidental taps.
‍
Additional considerations:

• Sort is a medium-frequency action → using a drawer allows users to switch both criteria and direction together.
• Filter is a low-frequency but complex task → breaking it into categorized submodules supports scalability and better UX.
• Search is a high-frequency precision task → a standalone page improves visibility and focus.

Trade-off Summary:

PM / Engineering Collaboration:

• PM Side:
  ‍Confirmed most mobile users operate with one finger and prefer modular swipe + backflow behavior, so supported the split of Search / Sort / Filter.
• Engineering Side:
  ‍Concerned about added complexity in sort drawer toggle logic. We resolved this by simplifying to a radio + direction toggle, and reused components to reduce dev effort.
• Filter UI:
  ‍Originally considered tabbed pages, but avoided deep click hierarchies by choosing categorized drawers with top-level jump-back support.

Validation:
Benchmarked mature Web3 apps like Zapper, Zerion, and CoinMarketCap—all of which use a similar drawer-based modular mobile UI.

Why Use a Horizontally Scrollable Table on Mobile?

In the Club module of this product, the user’s primary task is to compare different users’ strategy combinations and total earnings — a typical “horizontal comparison” behavior. To support this task effectively on mobile, we made the following key design decisions:

Chosen (A):
‍A horizontally scrollable table card layout:

• Left columns frozen (e.g., Layer, User, TVL)
• Right section (strategies and earnings) scrollable horizontally

Not Chosen (B):
Use an accordion layout where each user’s data expands one at a time, limiting visibility to a single user’s strategy at once — making side-by-side comparison impossible.

‍Rationale:
Goal-driven interaction:
Users want to know “Who earns the most?” or “Who has the best strategy mix?”
These comparison tasks require aligned columns and visual parallelism across multiple users.
An accordion layout disrupts this flow and reduces comparison efficiency.

Data structure consistency:
We retained the same column-based table structure as the desktop version to maintain cognitive consistency across devices, making it easier for users to learn and adapt.

Visual design support:
To guide users intuitively toward horizontal scrolling, we incorporated:

• Left-right shadow overlays (indicate scrollable content)
• Card boundary insets (highlight scrollable zone)
• Frozen left columns (prevent user disorientation during scroll)

Trade-off Summary:

Validation:Zapper (Web3 Asset Tracker)
‍Uses horizontally scrollable asset cards + frozen user info columns for side-by-side strategy comparison.

CoinMarketCap / CoinGecko
"Compare" feature and token data tables use horizontal scroll for aligned metric comparison (e.g., TVL, price).
‍
‍TradingView Mobile App
Technical indicators (charts, RSI, volume) displayed in scrollable cards with frozen asset/time labels — familiar to financial users.
‍
‍Design Guidelines

• Material Design: Recommends horizontal scrolling for wide tables on mobile.
• Fluent UI: Supports "frozen column + horizontal scroll" for dense data layouts.

Prototype