Crystal Lite

01 — The product problem

Making raw blockchain data readable in seconds

Crystal Lite is a free, self-serve blockchain investigation tool for compliance teams and financial investigators, built for web on desktop. It lets non-technical users trace crypto transactions, assess wallet risk, and build evidence for reporting — without reading raw on-chain data themselves.

This mattered beyond the interface itself: Crystal Lite is Crystal's free, self-serve entry point into a paid platform, so how quickly a new investigator reaches a confident read directly affects whether they convert to a paying account — not just whether the screen looks clean.

The product had to work for two very different moments in an investigator's workflow: a fast first read of a wallet's risk ("is this address dangerous?") and a slow, detailed forensic dig through thousands of transactions ("show me every transfer over $10k in Q1"). Designing for both without the interface fighting itself was the throughline of the project.

02 — The UX challenge

One interface, two very different jobs

Raw blockchain data doesn't arrive with any visual hierarchy built in — hashes, multi-hop transfers, and mixed asset types, all equally dense. On top of that, the actual users span a wide range of experience:

• Raw blockchain data is dense, technical, and unforgiving — hashes, multi-hop transfers, and mixed asset types with no inherent visual hierarchy.
• Users range from junior compliance analysts to experienced investigators, so the interface had to teach itself without a manual.
• The tool needed to support both a quick-glance risk read and deep, exportable, evidence-grade investigation — at scale, across high transaction volumes.

03 — The wrong instinct

The pull toward simplifying it away — and why that's wrong

Faced with data this dense, the obvious instinct is to strip it down — hide the technical detail and present a clean summary. That instinct isn't stated anywhere in the project brief; it's inferred from having to consciously resist it, and it's worth naming here because resisting it is part of the actual design judgment.

04 — Research

Designing for a wide range of investigator experience

A note on rigor, stated once: there's no formal research phase behind this project — no recruited panel, no structured usability protocol, no scored results. What follows came from direct walkthroughs with investigators and internal compliance stakeholders, and from exposure to how Crystal's existing users actually work. It's directional, not statistically validated, and I'm flagging that here rather than re-qualifying every claim below.

Across the walkthrough sessions — roughly a dozen over the course of the project — investigators reacted to the flat-table version with visible hesitation in most of them: pausing, scrolling back and forth, asking where to even start. With the graph-first version, that hesitation mostly disappeared; people started pointing at nodes and narrating what they saw within the first few seconds. That shift, more than any single comment, is what pushed the graph to become the entry point.

05 — System design

Three layers, one system

Rather than one interface trying to do everything, Crystal Lite splits the work into three layers that hand off to each other. These aren't alternatives that were tested against one another — they're the structure chosen to resolve the fast-read-vs-deep-dive tension directly.

Each layer is entered from the one before it — landing into graph, graph into table — so an investigator moves from a 5-second read to forensic detail without switching products.

Getting the graph-first entry point built and validated inside the available timeline meant something had to give. The original scope included a persistent investigation-history panel — letting an investigator jump back into a past case without re-searching the address — but building that well meant designing session and state management that would have pushed the graph and drawer work back by weeks. I deferred it: a fast, trustworthy first read mattered more to the core job than letting people resume old work, and shipping the primary flow well beat shipping both flows half-finished.

06 — The key product decision

Organize the complexity. Don't remove it.

This is the decision the whole product structure rests on: fast risk read versus forensic depth was never a choice to make. The answer was to structure the experience — landing, graph, drawer, table — so investigators move between the two instead of picking one.

07 — Interaction

From flow map to forensic detail, without leaving the graph

1. Start with the graph. "Where did the risk come from?" — a fast visual read of fund flow and risk.
2. Select a node. The investigator chooses a relevant wallet or entity in the flow.
3. Open the detail drawer. "Why is this node risky?" — address risk score, volume, counterparty risk breakdown.
4. Move into the transaction explorer. "Show me the evidence" — the structured table for deeper investigation.

This is fast read → explanation → evidence, in one continuous motion instead of three separate tools.

Transaction detail drawer — input/output addresses, fee data, and block metadata, opened directly from a graph node.

The same flow also carries the states investigators don't think about until they need them: consent and legal moments, access gating for free-tier limits, and ownership attribution. These live inside the explorer layer and were designed to stay out of the way of the core investigative task while still doing their job clearly.

• Cookie consent and legal moments (cookie banners, EULA updates)
• Access gating for free-tier limits
• Ownership attribution on addresses

Supporting states — cookie consent, address detail, and dense transaction lists.

These were designed as first-class states rather than afterthoughts, not a separate architectural layer — keeping the product compliant without disrupting the investigative flow.

08 — Validation

What's confirmed, and what isn't

The same walkthroughs that shaped the research fed directly into validating these two decisions:

One signal worth naming: designing consent, EULA, and access-gating as first-class states — rather than bolt-on modals — meant legal and compliance review on those flows moved faster than it had on earlier features, and there wasn't a redesign cycle needed afterward to fix an awkward gating moment or a buried consent flow. That's not a metric I tracked formally, but it's a real, repeatable pattern worth calling a soft outcome rather than leaving it as "unmeasured."

09 — What I'd measure next

What should have been measured

1. Question: Does graph-first investigation actually reduce time to a first meaningful risk assessment? Measure: Time from address entry to first identified risk signal.
2. Question: Does progressive disclosure preserve investigator confidence, or does it make people second-guess what's being hidden? Measure: Task completion rate plus a perceived-confidence check.
3. Question: Does the table actually support deep investigation at scale, or just look like it does? Measure: Investigation completion rate, filter usage, task success at high transaction volumes.

10 — Design → development

Built to scale without a redesign

The explorer table needed to handle real transaction volumes, not just a handful of rows in a mockup, so it was built around a structured data architecture and modular components. Clear debit/credit indicators and consistent component patterns meant the table could grow — more filters, more columns, more volume — without a structural redesign.

Explorer view — address summary panel paired with a dense, filterable transaction table.

Component states — empty, loading, dense-data, error — were documented directly in the design file rather than left implicit, and I went through several review cycles with engineering to make sure the table's performance held up once it was handling real transaction volumes instead of sample rows.

11 — Outcome

What the layered system delivered

12 — Contributions

What this project actually asked of me

Next, I'd want real numbers behind the directional signals above — see Section 09 for what I'd measure first.