Designing for Blockchain: What’s Different and What’s at Stake
How to design for trust around a “trustless” technology.
Blockchain technology is redefining the concept of trust and transforming how we think about the structures of everyday life, from identity to economics, and government. It pushes designers to think systemically and at larger scales — redefining our role and value on teams that are committed to building the decentralized future.
Blockchain is serious stuff. Many projects are dealing with people’s identities, large amounts of money, sensitive information, and replacing legacy systems that we may not even fully understand yet. I believe in the power and potential of blockchain, but I also know that we can’t realize the decentralized future if we are not designing for and solving problems that people actually have.
My goal these days is to get more designers in this space: more empathy, more user research, more design thinking, and more focus on meeting users where they are right now.
People often ask me, “What’s different about designing for blockchain?” A while back, I would have said not much, “it’s the same old human-centered design stuff.” However, I have started to change my mind, and so I want to give a better answer. That answer starts with asking the right question: What does designing for trust really mean?
Designing for Trust 1.0
Back in mid-2016, I started working on blockchain at IBM — at first on developer tools to get a blockchain network up and maintained, and then for a short while on a potential identity product. At that point, I wasn’t really aware of the larger picture of blockchain beyond what we were doing at IBM and on the Hyperledger platform. The cryptocurrency craze hadn’t really started yet. I never saw any crypto coverage on TV, and my friends certainly didn’t know what I was talking about.
While on-boarding to the blockchain team, I remember watching a video about Bitcoin that explained how this whole movement started. But Hyperledger didn’t have a cryptocurrency, which, if I’m honest, was confusing at first. All of the cool stuff about how Bitcoin worked — the mining, the rewards for mining, the safeguards against double spending — wasn’t there. Bitcoin had a branding problem though, and the blockchain people at IBM wanted to be taken seriously, so we didn’t really discuss cryptocurrency.
What we focused on were business outcomes of blockchain: cost savings, efficiency, reduced time for tracking goods on a supply chain. I still had a lot of questions about incentivizing and private networks, but I was new, so I went with it.
Then, for a short time I worked on an identity product. I saw the huge potential of self-sovereign identity on blockchain and I was hooked. Here was a chance to really help people — the undocumented, the trafficked, the edge cases, those with stolen identities. This was an opportunity to give people back control of their data and help them, not centralized institutions, monetize it, if they wanted. This is when blockchain started to feel like a revolution. When you take away all the barriers and give control back to people, the little fish can compete with the big fish.
In early 2017, I wrote about how we were designing for blockchain at IBM — what I am now calling Designing for Trust 1.0. I had been seeing really unusable apps with no clear flows. We were constantly chasing engineering decisions, contorting the user experience to fit what had already been built. So I came at the problem with just good old regular, human-centered design principles. There was a real jargon issue and a lot of emphasis on showing hashes. I think this was because most of the apps were intended as demos to other developers who would want to see that kind of thing. No one was really talking about end users.
So my colleagues and I took our best guess with the information we had and attempted to make design a bigger part of the conversation. But it was still largely a superficial layer, an add-on. We were trying to shoehorn in and retrofit an experience that felt trustworthy.
The gist of our design ethic was:
- Avoid jargon and non-actionable data.
- Be consistent. Use a design system.
- Use existing UX patterns.
- Create active guidance and feedback.
- Allow for and anticipate mistakes.
- Design for the global nature of blockchain — localization, device agnostic.
A big part of designing for blockchain was just looking legit. A lot of this is done through consistent visual design. No frilly animations (where things move when the user didn’t explicitly tell it to) and lots of talking users through a process. None of this was new information though. These are things any good designer would employ when users are encountering something new and complex.
Into Ethereum
Then, in July of 2017, I joined ConsenSys, a venture studio primarily focused on building applications and platforms on Ethereum. As I write this, we have 47 active “spokes” — what we call our ventures, like startups — that work on blockchain-based approaches to education, bounties, land registries, data science, accounting, music and copyright, science fiction universes, healthcare, and supply chain, among many others. What this meant for me as a designer is that suddenly I had a lot more information, user groups, and data to pull from when thinking about what designing in this space means.
Whereas before I had dismissed the cryptocurrency aspect as separate from the “real problems blockchain can fix,” at ConsenSys I was seeing what kinds of things it allowed us to do in that effort. While I suspect most people interact with cryptocurrency as their introduction to this space, I had come at it backwards. Late to the game, I was now asking, “What does it mean to collaborate with a large group under no centralized authority? What is possible when value can be transferred with no middlemen?”
Design Starvation
Even though blockchain has been around for almost a decade now (since Satoshi mined the Bitcoin genesis block in 2009), there are still just not enough designers, or enough understanding of what designers actually do. Until last year really, this was fine, because most of the Web3 users have been people who were very interested and motivated. In the beginning, much of this was happening in the command line and these users understood the system already. They will put up with nonsense. But blockchain success — this rumor of a decentralized future — depends on adoption by not only highly skilled and interested users but everyday people who are trying to do their jobs, purchase goods, or just have fun.
Growing pains like the Cryptokitties congestion crisis back in December 2017 was rough on some of the infrastructure teams, but it brought a lot more casual users into the space and forced a lot of teams to reevaluate their user experience. Cryptonerds are starting to get much more interested in the power of design, and I want the design community to be ready.
Designing for Trust 2.0
When talking about what is different about designing for blockchain applications, it’s important to first stress what isn’t different. Designers need to lean on a human-centered design process more than ever, and then add in systems thinking, mechanism design, and game theory.
This is a very developer-centric space right now. Designers are pressured to get to interfaces quickly and expected to “make it pretty.” It’s understandable — the visual output feels tangible and more real to those who don’t understand design process. However, it is an absolute mistake to jump straight to high-fidelity visual design or “re-skin” a prototype that has already been made, or so help me, make a logo for a product with no defined experience.
Design Thinking
People get really excited about blockchain and sometimes just want to make something — anything — that uses it, whether or not anyone really needs it. We have to rely on a solid process that ensures we know whose problem we’re solving and how we’re going to know if we’re indeed solving it. One strategy for working through this test and figuring out if you really are solving a problem is design thinking exercises.
“Design thinking” is just a way of approaching problems that focus on a human being. For instance, let’s all agree and validate what the problem even is first. Then it’s stuff like mapping, prototyping, and validating assumptions as a group — because all parts of a product team (business, design, and engineering) need to be involved.
Low-fidelity
Evaluate ideas and solutions when they are still on napkins. You can’t focus on the important things (like, is it solving the problem? Do we have a hierarchy of actions to be taken?) when you’re distracted by colors and button styles and typefaces.
User Research
Once you’re in here and understand blockchain, it’s already too late for you to design objectively for most users. More importantly, you are not your user. So obviously you need to research and test quite a bit. Remote testing and recruitment tools have come a long way in the past four years, so there’s no excuse.
However, I think the most effective strategy is participatory design, bringing users into our workshops. Not only can you watch them use things, they can give immediate feedback, and ideate with you. It’s a little more complicated upfront — signing legal documents, sourcing users in a certain location, and working out compensation or incentives—but the payoff is exponential.
Collaboration
Collaborating well is critical in this space where it’s highly unlikely any one person on the teams understands all areas perfectly. At ConsenSys, most of our teams are remote (decentralized!) and so we have to come up with new strategies to create that “everyone in the same room” dynamic: being able to move quickly, passively know what your team is doing, and showing each other what you mean when words aren’t working.
Designing for Trust Around a “Trustless” Machine
Last year, a colleague of mine said, “Just because blockchain technology is built to eliminate the reliance on trust doesn’t mean users will trust the machine or network.” Like I said before, at the time I saw this as a call to make interfaces that feel more “trustworthy” — to be more honest about what was happening via the interface.
However, I think “designing for trust” goes much deeper than that. We have a hard time right now separating the experience from the technology. I notice it most when I see user stories for a sprint — it is so easy to confuse user needs with network/system needs. So I have attempted to define these layers, and I think the real key is being able to tell the difference between them.
I think we’re really talking about three, though maybe more, layers that you are designing for or around: the machine itself (blockchain), human systems, and the perception of trust.
1. Trusting the Machine
The first design layer is mitigating the aspects of why users can trust the blockchain. That means designing around an existing system, helping people interact with the machine in the least painful way possible, and educating users on what’s happening. Designers have to understand how blockchain works to understand what can and can’t be changed in order to design experiences around things like gas, wait times, smart contracts, and private key management.
While it’s important to educate and empower users, sometimes from a design perspective it’s necessary to work toward abstracting away certain features, so that they will not be part of the experience in the future. Of course, there’s some debate around whether or not users should know and understand everything about the systems they are participating in. But it’s unreasonable to expect every user to know the technical inner workings of the blockchain. Casual users, for example, do not need to deal with gas—but for right now, it is still part of the experience. The CryptoKitty Crisis perfectly captured this design dilemma. MetaMask’s lead developer Dan Finlay describes it:
The main issue was that users were sending a transaction that was underpriced in gas, as the market had moved up without them, and were waiting for days for it to go through. But they didn’t know that, and it just seemed like the whole Ethereum Network was broken.
We came up with a small solution on MetaMask: For transactions that were taking a long time, we showed a button that let people resubmit the transaction with higher gas prices. That little button basically solved the whole problem. It allowed people to participate in the gas auction. Long term, it’s important that we’re empowering users to not be passive passengers in the games of crypto-economics, but to be active players. We learned that you can’t simplify away the gas auction. At times, people need the power to bid higher.
In the blockchain ecosystem, collaboration becomes critical: designers and researchers working closely with engineers to solve these hurdles for our users. It’s also about understanding where we are historically—we design for what we’ve got now with an eye and roadmap for the future.
Until the ecosystem develops robust scaling solutions, designing around the machine part of trust also means appreciating how much time transactions take on the blockchain. We have to pay attention to the user experience of these pending states: we’ve been trained by technology these days to expect immediacy, so even if we know a transaction will take a while, it still won’t stop the feeling of frustration or panic.
Key management is another critical user experience for designers to consider. Because there are no third parties to manage users’ digital identities in the blockchain space, users must sign transactions with private keys. The tradeoff between security and design is longstanding: design is about creating the best possible experience for a user; security is about creating the worst possible experience for an attacker. We must balance the freedom of giving people complete control with the dangers of giving people complete control.
When people talk about the benefits of blockchain, they often use the word “frictionless.” But let’s talk about what that means — removing middlemen, wait times, third parties, etc. — in some ways those things actually serve a good purpose when dealing with fallible human beings. Part of our job as designers is gauging at what time and how much friction we can add back in.
2. Trusting One Another
Beyond fostering trust in the blockchain, designers need to help users trust the mechanisms that people use to collaborate with one another. This is different because these are things we can change as designers, where before we were just designing for the least painful interaction with the blockchain mechanics.
When “systems thinking” was first suggested to me by a colleague as a skill set in a job description for a product designer, I reacted poorly. Seriously? Yet another thing we have to be able to do between user research and wireframes and design thinking and prototypes and front-end and visual design and testing?
I had seen some articles last year proposing that we find a bridge between systems thinking and design thinking and it all seemed exhausting. But then I realized designers are already thinking at a systems level, an example being Design Systems. Designers for sustainability, circular design, and social platforms are constantly thinking this way and blockchain by default is for groups of people, so there’s no getting out of it. A blockchain designer is a de facto systems thinker.
Because we now have a way to eliminate middlemen and quickly transfer value peer to peer — in addition to smart contracts — we can talk about things like:
- Micro-tipping: incentivizing things we want more of. Kauri is exploring how to incentivize getting and giving quality help for Ethereum developers.
- Staking: having skin in the game and giving the group a reason to think you’ll act in the group’s best interest.
- Token curated registries (TCRs): mechanisms that allow large groups of people, who don’t know or necessarily trust each other, to organize themselves. Civil uses a TCR to manage the quality of their journalism platform.
- Governance: how do groups of people decide things? Who gets to vote? Who decides who gets to vote?
- Crowdsourcing: aggregation and curation of ideas, the wisdom of crowds, prediction markets, and the power to pool money.
Even though mechanism design is an entire field dedicated to studying the design of protocols that incentivize rational actors to behave in socially desirable ways, it still assumes rational actors. Usually, we don’t understand people well enough to predict their behaviors with accuracy. Each stakeholder in a system still has to have an experience mapped and designed for them, and each must be researched and tested.
This is where we marry human-centered design with systems thinking, mechanism design, and cryptoeconomics. People won’t participate in a system for the sake of a system: we have to examine the incentives and how they map onto what someone is trying to accomplish. Designers need to understand and be interested in aligning incentives to properly design an experience that will be at least usable and delightful, and that also sustains the larger system.
3. Signaling Trust
The last layer that blockchain designers must create is an overt demonstration of trust — everything that humans are conditioned to perceive as trustworthy. This design principle carries over from Designing for Trust 1.0 and is mostly about good design:
- Explicit control. An interface should behave in a way that a user would expect. It shouldn’t do things the user didn’t explicitly tell it to do
- Reduce anxiety and cognitive load. Complex interactions are slowed down and paced out
- Guide with consistency. Visual elements give cues to the users so they know what to expect — elements like shape and color take on meaning within the interface
- Respect established conventions. Don’t make users learn new patterns unless it’s absolutely necessary
There are other ways to surface and demonstrate trustworthiness that bad actors are often too lazy to mimic. Badges from an outside authority — like twitter verified accounts or approved merchant seals — are one obvious way. Another is actively seeking out what makes your users confused or anxious and solving for that. Civil is striving to combat fake news and in their research, they learned that content consumers don’t really understand how to assess journalism for accuracy or quality. They came up with “credibility indicators” to educate their consumers on why they should trust certain information.
Designers Are Protectors
I want to end with one last, and most important, aspect of designing for trust: ethics and protecting our users. The “trust machine” fails if people end up getting harmed by what we’ve made. Like I said in the beginning, the truth is that blockchain affects the most intimate part of people’s lives — like money, identity, and health — but the space often still feels like the wild west.
One of the most compelling aspects of the blockchain is the transparency into the state of the network at any given time. However, this radical transparency can sometimes be a cause for concern. If anything should link your real life identity to your address, then everything you’ve done is out there. Personally, I am concerned about data triangulation — innocuous pieces of data that become sensitive in combination with other data. We have to think carefully about what data goes on the blockchain and what data we steward off-chain. Privacy solutions like zkSNARKS present opportunities to smoothly transact on the blockchain without revealing transaction data.
Much of the danger for users exists in the space between them and the blockchain. In addition to being an attack surface — the sum of different points where an unauthorized user can attack (entering or extracting data) — this is where people forget or lose their private keys. This is where the scams live.
Just because these issues are not happening on the blockchain, they’re still part of the blockchain onramp. We have to do everything we can to educate and protect people. When things go wrong in this space, users will blame blockchain regardless.
The whole reason I got into this space was because I wanted to help people, but some days I am worried. I’m worried about Black Mirror episodes in real life, replacing legacy systems with blockchain before we fully understand what we’re replacing, and building systems that only incentivize profit, addiction (like our current social platforms), or bad behaviors we can’t yet anticipate.
A Call to Action
Designers, we need you in here. Almost all of the projects have the potential to change the way we do everything, and you have the skills to influence whether that change is positive or negative. There are a lot of big ideas and pressing philosophical questions, and we need people bringing empathy to those conversations. We need people who know how to ideate, test, research, iterate, experiment, and ship product.
If you’re new to the space, don’t just read articles. Actually participating is the best way to learn fast. Install Metamask, buy a Cryptokitty. Buy a digital currency on Coinbase and then spend it on Overstock (or Craigslist!).
It’s more than cryptocurrency, so explore other communities. Check out Ujo’s Creator’s Portal and Cellarius’s storytelling platform. Try a design task on Bounties or Gitcoin. Do a tutorial on writing smart contracts or building a dApp — especially if you’re not a developer. Just struggle through it. Put your fingers on the blockchain.
And don’t be afraid to ask questions. Everyone is new and we’re figuring it out together. At ConsenSys, we’re always looking for product designers, systems and design thinkers, design researchers, and more. Check out our open positions here. We need your help to build and design a decentralized future that people can trust.
Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. ConsenSys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about ConsenSys and Ethereum, please visit our website.
