Glacis Labs dApp

My role on the project was Lead Product Designer. I managed an international team consisting of a junior designer and outsourced graphic and motion designers, and of course, I did a lot of hands-on work myself.

Tasks and Context

When I joined the project, the company needed:

• •brand identity
• •dApp
• •website
• •investor presentations
• •media materials.

I outsourced the media materials and supervised them iteratively, and took on the rest myself.

dApp

After defining the visual direction, I moved on to the dApp. Its main job is tracking transaction status online. Sounds like a pretty standard scan app, but I was asked to show statuses graphically, and the tricky part is that one transaction can go through five bridges. It looks like this (diagram from the developers):

The app also needed an analytics block showing the total number of transactions over a period, gas cost, transaction speed, the most popular Chain Paths, and so on. And of course it needed an extended filtering block, so the user could customize the charts as much as possible.

The app's audience is developers (85%) and web3 product users (15%), primarily Western. High data density is welcomed, and diagnostic speed (quickly understanding why a transaction failed) is a priority.

After the V1 design was done, the junior designer left and the input got more complex: Glacis Labs launched a second product, AirLift, which expanded the analytics section and introduced one more variable into transactions. So, V2:

Main Page

At the top there is mini-statistics for the whole dApp. It gives a new user a sense of the ecosystem's scale and transaction volume, and gives a returning user a way to track changes ("wow, there used to be 10 networks, now there are already 21, they are growing fast").

Next comes the list of recent transactions in a table view, which feels familiar to the audience and is standard for scanners. There is a search field for quick checks, filters for when you are looking for patterns, and sorting by time. At first we split transactions by product into Glacis Core and AirLift tabs, but after testing we merged them into one table, removed the extra step, and kept product filtering instead.

Transaction Details

Clicking a row in the table opens the transaction details. Under the header I placed the transaction time, status, and product. Then comes everything that might be useful: Message ID, From/To, Source / Destination, and so on, with copy buttons everywhere they matter. Below that is the detailed transaction status. In this example it goes through two bridges, Wormhole and LayerZero, and each has its own status. The user can see that the transaction already passed through Wormhole, while LayerZero has not completed it yet, but is close. They can also see the alternative paths the transaction could have taken.

For mobile, I made this block more compact, but expandable by rotating the screen:

In case of error, the system automatically triggers a Retry, displayed in the dApp interface:

Two tabs appear: “Main data” – current status (or how it was executed), and “Retry data” – list of retries. There can be multiple retries (devs say 99+, but haven't seen that yet), all visible to the user. They can track exactly at which stage and bridge the error occurred – making execution transparent.

If the transaction details page loads slowly – we see this wonderful loader:

Analytics

Analytics is available for Glacis Core and AirLift – charts and datasets differ. Chains Overview is in development.

Light Theme

Looks like this: