Know what you sign
Signing transactions in web3 can be scary. You're about to confirm something, and all you see is a wall of code, a random hash, or some vague text like "contract interaction."

Most people (including me, sometimes) just cross their fingers and hit sign. But one bad signature and your wallet can be emptied in seconds. Not great.
I first ran into this about 10 years ago, as the only designer on MetaMask. Back then, just making it work was already a win. At Taho, in 2023, I got to take another stab at this mess and make signing a bit more human. Or at least less terrifying.
- Role
- Design Lead
- Business goal
- Reduce support tickets by 50%
- User needs
- Understand what I'm signing
- Trust what the wallet shows me
People didn't trust what the wallet showed them
Before designing anything, I did some light benchmarking so we'd know later if the redesign actually helped, or if we were just moving pixels around for fun. Signing took about 30 seconds on average, and around 35% of transactions were rejected.
The rejections were the interesting bit. When I asked people why, a lot of them said they rejected transactions just to go back and double-check things on the dApp, because they didn't really trust what the wallet was showing them.
I also mapped out what we thought people were struggling with and checked it against a community survey, feedback on social media and our Discord. Spoiler: a lot of it matched.

Showing things in the order people check them
Testing showed a pretty clear order to what people look at before they sign:
- What am I signing?
- Who am I signing with?
- How does this affect my wallet?
So that's how the screen is laid out: the transaction type in plain language, then the dApp you're interacting with, then the balance change in tokens and dollars. If you want the raw data, it's still there behind "View raw."
A surprising side note: most people didn't care much about the network fee, especially on L2s, so it moved further down.

None of the plain-language part works without engineering. The team added contract simulations, which is what let us show what a transaction will actually do instead of a hash.
Dropping the multi-step idea
I started wide with a bunch of lo-fi wireframes. One idea I liked was splitting signing into a few steps, so you'd get more clarity without everything hitting you at once. Progressive disclosure usually works well in complex flows like this.

It didn't survive testing. People wanted to feel safe, but they also wanted to move quickly, and adding 2 or 3 steps to every signature slowed them down more than it helped. So while the idea had some good theory behind it, it didn't fit how people actually sign, and everything had to work on one screen.
One structure for every transaction type
Swaps, approvals, signed messages and multi-token LP transactions all needed a signing screen, and they needed to feel familiar. Using our existing design system, I built a modular framework for the signing screens, so every transaction type follows the same structure.

I also made a set of molecules you can combine into any variation of the screen. Designers got a clear way to add signing to a new flow, and more importantly, engineering got a blueprint for building the components.

What changed
Compared to the benchmarks:
- Time to sign went from about 30 seconds to about 20.
- Rejected transactions dropped 23%, from a baseline of about 35%. Fewer people felt the need to leave the wallet and double-check.
- Support tickets dropped about 35%. Our goal was 50%, so we didn't fully get there, but it was a real drop.
What I'd push further
Hats off to the engineering team at Taho. Adding contract simulations and expanding the design system for all the new flows was a massive lift.
If there's one thing I wish we'd pushed further, it's warnings and error handling. We had the basics (flagged contracts and fake websites), and plans for more, but technically it was an extra lift we couldn't take on at the time. I'd love to pick that up in a next iteration.
