Across the ecosystem in 2017 and 2018 decentralized applications (dApps) were being built at a blinding speed. Unfortunately, the user experience was very poor—everything from confusing language to dead end flows made dApps accessible to only extremely motivated people. Most teams did not have a designer, but relying on Material and other existing component libraries was no help—they didn’t have the patterns required to interact or transact on a blockchain. Worse, accessibility (the Section 508 kind) was not even an afterthought...disappointing when the draw of blockchain centers on inclusivity and a second chance at an equitable internet.

Users were confronted with a range of challenges, never knowing what to expect. Most products saw a drop off as soon as the user was asked to interact with a wallet for this first time—their curiosity faded in the face of so much cognitive load. New users didn’t understand concept of gas, or whether or not their transactions went through.

It wasn’t enough to improve dApps only at Consensys, UX needed to work across the ecosystem. A rising tide lifts all ships—the success of any team was a win for Ethereum and a chance to learn what was and wasn’t working. Use cases needed to be validated on the merit of the problem it solved, not whether or not someone could figure out how to use the dApp.

Improving UX in this space meant attracting the right talent—senior product, service, and research designers. I began writing at IBM about designing for blockchain applications and it had received more attention than I had anticipated. Writing has the potential to influence more people for a longer period time than a conference talk, so I started with more articles.

I have a folder of screenshots like this to look at when I have had a difficult day. I highly suggest having a "nice things people took the time to write" folder.

By writing more thoughts on how to improve dApp design, profiling designers already in the space, and standing up the Consensys Design site and social media, I was able to lower the barrier for entry and normalize design in blockchain. I gave talks globally, both to designers unfamiliar with the space and to developers unfamiliar with design.


Moinworld, Hamburg Germany

Talks and writing only got me so far—it was time to put truly useful tools out there. Gradually I hired a team for the design system, and kicked off a design thinking workshop in the summer of 2018. We were calling it a design system, though we knew it would lack some of the same purposes of conventional design systems: there was no brand consistency to enforce across Consensys's or the ecosystem independent products, so we knew up front the ability to theme would be necessary.

We focused on our main persona: the ethereum developer with no design experience. Could we make it easy for this person to develop a dApp that had better UX and accessibility than what they would do alone? The team researched potential users, partnered with existing products, and made decisions about what to offer from the data gathered. I recruited a content designer to really dig in on the language we were using to tell users what was happening. He partnered with researchers to test language and what terms were tripping new users up. The team settled on the Metamask interaction and transaction patterns as the first pain points to tackle.

Rimble (named for repeatable + nimble = Rimble ...and also it had literally no competition for the name on Google 😂) is open source and will be v1 by the fall. It's already being used in multiple products and client projects at Consensys, and designers use the Figma design file for patterns, even when their product isn't consuming the design system.

npm package downloads of Rimble

I am really proud of the team I was able to lure in here to undertake a design system in probably the world's most ambiguous and changing environment—they are brilliant and inspiring. If I could start over, I think I would have reversed the order I did these things in—rather than speaking and writing so much about the problems to fix in the beginning, it would have been more efficient to start the design system first. Then I would have been able to come to events with a solution in hand and maximized my stage time.