Case study · Web3

Chromia Explorer

Making on-chain data easier to find, understand, and act on.

Chromia Explorer began as a basic transaction viewer. I led its end-to-end redesign into a more useful analytical product — one that helps developers, dApp users, providers, and other ecosystem participants navigate the network, investigate activity, and make sense of on-chain data. The redesign is fully live.

Project overview
ProductChromia Block Explorer
DomainWeb3 / blockchain analytics
PlatformWeb
My roleSenior Product Designer
TeamPM, front-end and back-end developers
Timeline6 months
StatusFully released

Chromia is a Layer-1 blockchain that combines blockchain infrastructure with relational database technology. Chromia Explorer is the public interface to its on-chain data: users rely on it to track transactions, inspect network activity, explore assets, and understand how the ecosystem is performing. I was responsible for the design process from initial research and problem definition through to product design and final validation.

Who this was for

Explorer is a public product — anyone can open it — but a public product without a primary audience becomes an average product for everyone. Four groups used it, and I prioritised them rather than designing for all four at once.

Primary

Blockchain developers

They used Explorer most often and most deeply — not for a one-off lookup, but as a working instrument during debugging and integration. They were the group the research flagged hardest: the two sharpest findings were both theirs. And their needs were the most demanding, which made them the right constraint to design against — an interface that lets a developer filter a large transaction set by several criteria will also serve someone looking up a single transfer, whereas the reverse is not true.

Secondary

dApp users

The largest group by volume, with the shallowest sessions — usually a single question about one transaction or asset. They needed the entry points, not the depth: a search that forgives an imprecise query, plain-language labelling, and a clear starting point on the dashboard. Their requirement was mostly that developer-grade density should not be the first thing they meet.

Secondary

Providers and governance participants

A small group with high stakes. They needed network-level visibility and a view into governance decisions, which is what the Proposals, Accounts and Signers pages address. Low in volume, but the product loses credibility without them.

Tertiary

Investors and asset holders

Their needs sat mostly on top of what the other groups already required — asset distribution, CHR metrics, top networks — so they were served by extending existing surfaces rather than by dedicated flows.

This ordering is what the design strategy rests on. Depth first, calibrated to developers; approachability layered on top so the depth does not become the default experience.

The starting point

The existing Explorer exposed blockchain data, but did not help users interpret or act on it. The product had limited metrics, fragmented navigation, unreliable search, and static transaction tables. Important information was technically available, yet difficult to discover and investigate. This created different problems for different audiences:

The goal was to evolve Explorer from a passive transaction viewer into a reliable analytical tool — without overwhelming users with the complexity of raw blockchain data.

Understanding where the product failed

I ran three research channels, each answering a different question, so the redesign would follow recurring evidence rather than assumptions.

01

Five in-depth interviews with stakeholders and team leads

Context and constraints. These were internal, not user-facing. They gave me the history behind the product: which complaints the team already knew about, which limitations were deliberate trade-offs versus accumulated debt, what the backend rebuild would and would not make possible, and what the business needed Explorer to do for the ecosystem. This is where I learned that search had never had a dedicated backend — which reframed it from an interface problem into a capability problem.

02

A survey of 30 developers and blockchain users

How widespread the problems were. This was the primary source of direct user evidence, used to rank issues rather than size them precisely. At n=30, and with a self-selected sample of people already engaged enough with Chromia to respond, I read the results as a priority order rather than as a measurement of the wider user base.

03

A feedback form embedded in Explorer

What breaks in context. Continuous rather than a single snapshot, and captured from people mid-task instead of recalling the product afterwards. It kept surfacing issues after the research phase closed, which made it useful during design as well.

Four problems appeared consistently across all three channels. The figures below are from the survey (n=30, [X] of whom were developers):

76%of developer respondents struggled to find specific transactions
70%wanted analytical depth the product did not offer
60%of all respondents found Explorer difficult to navigate
53%of dApp users found the interface confusing

What made these findings actionable was not the exact percentages but their convergence: search and navigation ranked first in the survey, dominated the in-product feedback, and matched what stakeholders already suspected but had not been able to prioritise. That combination shifted the project from a visual refresh to a product-level redesign focused on discoverability, data clarity, and analytical depth.

What this research could not tell me. I did not run one-to-one sessions with end users, so I had users' answers but not their behaviour — I could see which problems mattered, not how people moved through the interface while hitting them. The in-product feedback form partially covered that gap by catching issues in context rather than in recollection, and the stakeholder interviews supplied the constraints. Where I still had to choose between interpretations, I designed the option that stayed usable if I was wrong.

Design strategy

I organised the redesign around three principles.

01

Prioritise meaning over data volume

The interface needed to surface the most useful network signals first, while still allowing experienced users to explore details.

02

Make search a core navigation model

Users should be able to move from an open-ended question to a specific blockchain, block, account, asset, signer, or transaction without restarting their journey.

03

Support investigation, not just observation

Transaction data needed filtering, structured pagination, and richer context so users could answer questions instead of manually scanning lists.

Challenges

01 — Turning the dashboard into an analytical entry point

Problem

The old dashboard provided a small set of metrics, but the hierarchy did not reflect the questions users came to Explorer to answer. The clusters section was difficult to interpret, dApp information was neither interactive nor informative, and the experience was inconsistent with the wider Chromia product ecosystem.

Decision

I redesigned the dashboard around a clearer information hierarchy and expanded the range of immediately useful data. Key network metrics were elevated, cluster distribution was simplified, and a visual breakdown made the relationship between clusters easier to understand at a glance. I also introduced Top Blockchains and Top Assets sections, giving users a fast way to identify relevant networks and tokens before moving into deeper analysis.

Outcome

The dashboard became an analytical starting point rather than a static status page. It now helps users understand network activity, discover relevant assets, and decide where to investigate next.

02 — Designing search across a multi-chain ecosystem

Problem

Search was one of the most important and least reliable parts of the old experience. Without a dedicated backend, it frequently returned errors or failed to load results. The flow also depended on users knowing the correct data category in advance. If they entered an unsupported format or searched in the wrong context, they often had to start again.

Decision

I introduced a dual-layer search model: global search for discovering information across the Chromia network, and blockchain-specific search for accessing the most recent data within a selected chain. The new interface lets users browse and search blockchains in a persistent left-hand panel, pin frequently used networks, and move directly into a selected blockchain's detail view. New backend infrastructure enabled dynamic queries, faster execution, and access to more up-to-date transaction and block data.

Outcome

Search became both a discovery mechanism and a navigation system. Users can move between the ecosystem level and a specific blockchain without losing context or rebuilding their query from scratch.

03 — Making transaction investigation scalable

Problem

The old transaction page displayed a static list with no meaningful filtering or sorting. Users had to scan records manually and could not refine results by transaction type, sender, receiver, or date. Important details such as status, token amounts, confirmations, and timestamps were difficult to access.

Decision

I designed an advanced transaction view that supports multi-criteria filtering and richer data presentation. Users can narrow results using relevant parameters, inspect a broader set of transaction attributes, and move from a blockchain detail page into a deeper investigation flow. I replaced infinite scrolling with structured pagination, which made large result sets easier to navigate and created a more predictable interaction model for a data-heavy product.

Outcome

The transaction experience moved from passive browsing to focused analysis. Users can define what they are looking for, refine the dataset, and review relevant results without manually searching through an endless list.

Extending Explorer beyond transactions

The redesign established patterns that could support a broader ecosystem rather than solving only isolated pages. I extended Explorer with:

These additions expanded Explorer from a utility for checking transactions into a product that supports analytics, asset discovery, and governance transparency.

Outputs
Impact

The redesign is fully live. To evaluate it, I re-ran the original survey with the same instrument and the same audience segments [N] weeks after release, so every figure below is a change against a pre-redesign baseline I had measured myself.

+77%Search usability — average rating improved after release; difficulty finding transactions no longer a top-reported issue
+68%Navigating on-chain data — satisfaction rose, driven by dual-layer search and the persistent blockchain panel
80%Analytical features — of developers now regularly use the new analytical views
+72%Interface quality — satisfaction with UI/UX, driven by restructured tables and aligned navigation

Sample: [N] respondents across developers, dApp users and providers. Self-reported measures — survey-based, not instrumented analytics.

Beyond individual metrics, the project changed Explorer's role in the Chromia ecosystem. It became a clearer and more actionable interface to the network — supporting everyday lookups, deeper technical investigation, asset analysis, and governance transparency within one connected product.

Reflection

This project reinforced that transparency in a data-heavy product is not achieved by showing more information. It comes from helping people understand where to begin, how data is connected, and what they can do next.

The most important design shift was moving from page-by-page improvements to a shared product model: clearer hierarchy, search that preserves context, and reusable patterns for exploring complex datasets. That foundation made Explorer more useful for current users and easier to extend as the Chromia ecosystem grows.

← Back to all projects