AEscan

Before AEscan, aeternity had three separate internal tools for exploring the blockchain. Each one held capabilities that needed to survive the merge, but none of them worked together. Users had to jump between tools to get a complete picture of the network. Developers were frustrated. End users were lost.

I audited all three products, interviewed 8 developers and 4 end users, and analyzed the inherited Balsamiq wireframes from the previous designer. Some ideas were worth keeping. Most needed to be rebuilt.

What we found:

The brief was not just a redesign. It was a unification. Three products had to become one coherent platform without losing their most valuable capabilities. And the team was decentralized, open-source, and used to shipping without centralized design oversight.

I reviewed more than ten blockchain explorers to collect useful patterns, new ideas, and opportunities to improve on what was already out there.

The gap: nobody combined deep blockchain data with approachable visual design. Existing explorers were built by developers for developers. We had an opportunity to build something that served both audiences without dumbing down the data.

Every pain point in the three legacy products became a unification principle.

Alternatives we explored and rejected:

Most blockchain explorers open to a dense table of recent transactions. We inverted this. The AEscan dashboard is a summary: current price, market cap, network stats (TPS, latest keyblock, smart contracts, oracles, names), and a visual keyblock timeline. Users get the state of the network at a glance. Tables are one click away, not the default.

The search bar spans all data types: accounts, transactions, contracts, oracles, names, and tokens. Smart suggestions appear as you type. Filters let you narrow by data type. For developers, this means finding a contract address without knowing which section it lives in. For end users, it means typing a name and getting relevant results across the platform.

Dynamic tables are the backbone of any blockchain explorer. Instead of building a custom table for transactions, another for contracts, another for oracles, we designed one scalable table component. Configurable columns, sortable headers, expandable rows for detail, and consistent pagination. The same component renders transactions, contracts, names, and oracle data. Different data, same mental model.

Every entity in AEscan (transaction, contract, oracle, name) has a detail view with a consistent structure: summary card at the top (the glance), tabbed sections below (the deep dive). The summary card shows the 4-5 most important facts. Tabs organize the rest. Developers get the raw data they need. End users get the context they need. Same page, different depths.

I started by reviewing the three existing products. Each one held capabilities that needed to survive the merge. I documented every feature, every screen, every data type. Then I interviewed 8 developers and 4 end users to understand how they used (or didn't use) each tool. The experience map of the old workflow was sobering: users opened all three tools in separate tabs and manually cross-referenced data.

I reviewed more than ten blockchain explorers. Not to copy, but to understand what patterns worked and what didn't. Etherscan's density was impressive but hostile. Mintscan's dashboard was clean but shallow. I collected the best patterns: Etherscan's search speed, Mintscan's visual hierarchy, Blockchair's filter depth. Then I designed something that combined the depth of the former with the approachability of the latter.

Before any UI, I rebuilt the information architecture. The three legacy products had overlapping categories and inconsistent naming. I consolidated everything into a clear hierarchy: Blockchain (keyblocks, microblocks, transactions), Tokens, Contracts, Names, Oracles, Developers. Each section has a consistent sub-structure: list view, detail view, search, filters.

Every journey was mapped as a flow, then wireframed in low fidelity, then tested with stakeholders. The previous designer's Balsamiq wireframes were too prescriptive. I used them as a starting point, not a specification. Key stakeholder meetings realigned the team around the new architecture before any visual design began.

I built a component library designed for scalability. Dynamic tables, detail view templates, search patterns, chart components, and form elements. All tokens (colors, typography, spacing) were defined in Figma and documented for the open-source team. The system had to work for developers who might not have a designer on their team.

I led the product vision and design for AEscan, from audit through shipped UI and design system. The MVP launched and was followed by new features and continuous improvements.

If I revisited this project today, I would change three things: