BDX: Making Blockchain Legible

Overview

I led visual identity and product design for BDX, a blockchain-powered auction marketplace for public data storage. Starting from a zero brand, I designed end-to-end experiences for two user roles — Data Clients and Storage Providers — and delivered a functional MVP in four weeks.

Challenge

Public data has a permanence problem. Under centralized storage models, whoever controls the infrastructure controls the record. Data can be altered, restricted, or allowed to disappear when it is no longer convenient to maintain. BDX is built on a different premise: that public data should be preserved through open, competitive infrastructure, not locked inside systems owned by single governments or corporations.

To realize that premise, BDX introduces a competitive auction structure: Data Clients publish datasets and requirements, Storage Providers place bids, and clients choose based on price, performance, and fit. Transactions execute through smart contracts, with FIL token incentives creating a new economic framework for long-term data preservation.

The design challenge was to make this model work for users who had never encountered it before:

• An unfamiliar economic model: The auction mechanism is intuitive once understood, but novel enough to create an initial trust gap that the interface had to close.
• Two distinct mental models: Data Clients and Storage Providers, approach the platform with fundamentally different goals, requiring separate flows built on a shared system.
• Opaque technology: Blockchain-native concepts — smart contracts, FIL tokens, decentralized storage, had to be translated into plain language without obscuring the underlying value.

For BDX, the MVP was the primary instrument to attract early pilot users and build investor confidence. If the interface failed to make the economic model legible, the product’s value proposition would be undermined at its first public moment.

Approach

With a brand-to-product scope and a fixed four-week deadline, sequencing was everything.

• Brand as anchor: I established visual identity first, before touching a single product screen. I chose a dark base palette with high-brightness, high-contrast gradients, the dark tone signalling the gravity of a financial infrastructure product, while gradients drew attention to key actions and added energy to the auction experience. Setting this in week one meant every subsequent decision had a reference point.
• Role-separated flows on a shared system: I designed Data Client and Storage Provider experiences as distinct journeys, each mapped to the user’s actual mental model, while building both on a single component library to avoid duplication and accelerate delivery.
• Complexity hiding: Auction mechanics, smart contract execution, and FIL token logic were translated into plain-language copy and guided, step-by-step flows. Technical details surfaced only when directly relevant to a decision.
• Module-first build: I prioritized the modular design system before individual screens. Every component built for the MVP was immediately reusable, which reduced rework as the scope expanded.

Reflection

Designing alone under a fixed deadline changes how you make decisions. Every component, token, and naming choice has to be resolved on the first pass, and that pressure can produce surprisingly clean architecture.

The harder problem was emotional rather than structural: making data auctions feel worth engaging with. The answer was contrast. The product needed to feel serious enough to be trusted, but bright enough to feel alive. Setting that balance in the first week is what allowed the system to hold through later iterations.

BDX was eventually sunset; the platform did not reach the scale it aimed for. But the problem it addressed has not gone away. Who controls the infrastructure controls the record, and that question is only becoming more urgent.