IlluviDEX

I joined Illuvium just before the IlluviDEX launch, the marketplace that anchored a $72M land sale for Illuvium: Zero, as lead product designer. The remit started as launch UX and grew into product ownership: information architecture, feature design, prioritisation, and a feedback loop with the trading community.

IlluviDEX needed to host 20+ asset categories across four games without the catalogue collapsing under itself. New asset types were coming online from Illuvium Beyond and other titles. Power users were trading in volume and needed bulk operations that the launch IA didn’t support, while new traders needed an experience that didn’t punish them for not knowing how the ecosystem fit together. The marketplace also had to keep up with the pace of the games it served: features and assets shipping continuously, with real money on every change.

Three channels fed feature decisions, and each did a different job.

The Discord forum I stood up was the cheap early warning system. Reading it, and casually leaking early designs to the community, told us roughly where the pain was before we spent anything finding out properly. Targeted surveys with traders sharpened that into specific behaviours.

Useberry did the structured work. We used it two ways depending on the question: digging into a problem upstream when we didn’t understand it yet, or testing a Figma design before it went to build. Internally, shared prototypes and Loom walkthroughs put the work in front of the company and the other designers early, so issues surfaced before engineering time went into them.

Every feature then ran the same loop: spot the signal in the forum, take it to Useberry, design it in Figma with real components, build it with the devs, then measure whether it actually moved the behaviour.

The hardest call was structural. Devs and game designers thought of assets as a flat list, because that is how the codebase stored them. But some assets worked across more than one game, and a flat list cannot show that a thing belongs in two places at once. Structuring the catalogue the way the data was stored would have made the marketplace unreadable at exactly the moment it got large.

Traders didn’t share my game context, so I ran a closed card sort with pre-defined categories to learn where they would actually expect to find an ore, a shield, a sword. We built the structure around where people looked rather than how the codebase stored things: a per-game marketplace view, with dropdowns and asset-type grouping underneath that still surfaced assets shared across games.

After launch I ran tree testing to check the structure held up in live navigation, so the IA had evaluative proof behind it rather than a hunch. No other marketplace serving these games was structured this way, and it mattered commercially as well as usably: traders had alternatives, and the experience was the reason they chose this one.

A few patterns kept surfacing across surveys and the forum:

• Listings didn’t support negotiation, so trades stalled when buyer and seller had different price expectations.
• Power users were doing the same actions over and over (listing, transferring, batching) without bulk tooling.
• Players struggled to navigate large collections when assets in the same set were spread across many individual listings.
• Granular item info (abilities, traits) was buried, slowing down comparison.
• Onboarding and fund movement were rough enough to filter out new traders.

I sequenced the work around two principles: ship the things power users were screaming for, but don’t let the IA collapse under the weight of new categories. That gave us a roadmap weighted toward bulk tooling, navigation, and quality-of-life surfacing, with a ground-up IA rework underneath it so new asset types could land without breaking the model.

The features that landed against those findings:

• An Offers system so players could negotiate on price.
• Grouped Asset Folders to give an overview of unique types inside larger collections.
• A sitewide cart so checkout could happen in one pass.
• Batch Listing and Transferring for power users.
• An Ability Overlay to surface granular item info at a glance.
• The surrounding work: onboarding, fund transfers, account settings.
• A ground-up IA rework so the catalogue could host 20+ categories across four games without collapsing.

Offers were designed as a full negotiation layer rather than a single modal. The work covered received and sent offers, filtering and sorting, validation, fee visibility, buyer and seller states, and confirmation flows for accepting or cancelling an offer.

The sitewide cart needed to work across marketplace categories and keep users oriented while items, prices, and availability changed underneath them. That meant designing the happy path and the edge cases together: add-to-cart entry points, checkout summaries, price-change warnings, unavailable-item handling, and transaction failure states.

Traders were making buying decisions without being able to tell whether an asset was any good. The stats existed, but they were buried, and comparing two listings meant leaving the page. We surfaced an asset’s stats inline and added a rarity gauge, a single 0 to 100% number showing how good an asset was relative to the market.

It was not an easy sell internally. Illuvium’s Game Director later described his own reaction to it in a public dev blog:

My honest reaction was that it was stupid… That was my reaction, and it was wrong. People want to know how good something is immediately. And I did it.

Illuvium Game Director, Dev Blog #17

Each asset type needed the right information surfaced, and getting it wrong meant traders could not compare what they were buying. The source of truth sat with the game designers, not with me.

So I worked through it type by type. For every asset type I recorded a Loom for the game designers, gathered their information and feedback, and got explicit sign-off before it shipped. Slow, but it meant the marketplace showed accurate, trustworthy data across 20+ categories rather than plausible guesses.

IlluviDEX also carried a migration problem: existing users needed to move into Passport without losing confidence in their assets, wallets, or account state. I mapped the migration path across device sizes and designed the wallet-connect, login, and connected-profile moments that made the transition feel explicit.

Onramp is the step where someone gets real funds into their account so they can trade. For a player new to the ecosystem it is the make-or-break first move, and heuristic analysis and forum feedback both flagged it as brutal. It was also the single most valuable moment on the marketplace: a broken onramp lost the user and the trade at the same time.

I redesigned it, and then hit a wall. The real flow was bound by technical constraints well outside my control, something Illuvium acknowledged publicly in the same dev blog:

Our onboarding system… is not good enough. There are places where we don’t have the level of control we need to do what is required.

Illuvium Game Director, Dev Blog #17

Rather than stop there, I pushed the fix past my own remit. I worked with BD to bring in Layerswap as an external provider, sat in the integration meetings, and shipped the best available option with the devs. It still could have been better. But I would rather push a high-value flow as far as the constraints allow than accept a bad experience because the fix was not mine to make.

Illuvium Beyond added another layer of marketplace complexity: collectible categories, D1SKs, accessory metadata, card and list views, ownership states, and detail pages all had to fit inside the same marketplace model without becoming a separate product.

Alongside design I moved into product ownership: rewriting documentation, creating feature descriptions, user stories, and acceptance criteria, and prioritising the roadmap. The Discord forum sat at the centre of that: every shipped feature had a paper trail back to specific user feedback, and every prioritisation call was defensible against the community.

IlluviDEX continues to evolve on user feedback and now supports thousands of trades daily. The redesign and new features improved usability and streamlined asset management across the platform, and the feedback loop kept the roadmap connected to the people actually trading on it.

This was my first real run at product management on a platform this size, and the lesson that stuck was that high-traffic marketplaces don’t just test your design, they test your process. You can’t ship good features fast without good documentation, clear acceptance criteria, and a real user channel. Building all three in parallel with the design work was the thing that made the rest possible.