July 12, 2018 | 7min read
Blockchain Designing for Trust. Interview with Sarah Baker Mills
Sarah Baker Mills is a Product Design Director at ConsenSys, a venture production studio building decentralized applications and end-user tools for blockchain ecosystems, primarily focused on Ethereum. We had a great pleasure to host Sarah at our MCE 2018 Conference. She cares about making blockchain more accessible, inclusive, and focused on solving problems for human beings—while making a design practice more efficient and transparent.
I think when you first start, it’s just understanding the mechanics and how things work, so you know the current limitations—the same as any designer needs to understand the materials and tools they have to work with. It also allows you to know what must be done on a blockchain and what doesn’t. Then, I think it’s helping your team separate the blockchain needs from the human needs; it’s easier to get these things confused than one would think.
Designers also have to develop ways for prototyping, not just individual experiences but whole systems. I can’t think of a dapp (decentralized application) that involves only one persona; they are, by nature, for groups of people to collaborate and transfer value. Lately, at ConsenSys we’ve been “live action role-playing” mechanisms like voting and staking as a way to uncover user problems early on.
Sarah Baker MillsProduct Design Director,ConsenSys[The biggest challenge] is helping your team separate the blockchain needs from the human needs; it’s easier to get these things confused than one would think.
What do you mean by “designing for trust” and how does really designing a blockchain app differ from designing e.g. a banking app?
I think “designing for trust” can be confusing. Yes, the experience needs to be and feel trustworthy, especially when new users are anxious. They’re dealing with important things like sensitive data, identity, and money. Designers are pretty good at this though—being consistent, lowering cognitive load, etc. The biggest difference is that we can’t rely on people understanding what is happening because they’ve used a banking app before and have preset expectations. We have to be clear about what’s happening and choose our words carefully.
When I talk about designing for trust, I usually mean the value of the trust blockchain gives us. Designing around the mechanics of what affords us that value can be tricky. Being able to do anything with large groups of people you’ve never met, without a middleman, is both amazing and at the same time scary. The work that a centralized organization or middleman does—and has historically lost our trust doing poorly—shifts back to us. Users now have control over their data, identity, and money. We’re not sure if the majority of people are ready for that though, so we’re still experimenting and testing. People lose their private keys and send things to the wrong address all the time, and there is no one to call for help.
For this space in particular, I would say a comfort with ambiguity is an asset. Being deeply curious and unafraid of complexity while having the urge to externalize, build, and experiment is key. I find that designers that do well are secure in their process and champion their user when faced with hype, “just make it pretty”, and a fast-moving environment.
On the whole, I think designers are having to grow their facilitation and systems thinking skills, not just in this space. There’s too much for one or even two people to understand well; we have to be better at collaborating and building together as well as looking at things holistically.
Tell us more about ConsenSys’ activities and the way you collaborate with developers - from the perspective of Design Director?
All designers lead design on their spokes and collaborate with developers in their own ways. The “spokes” are autonomous start-ups and do what works for them. However, I think the most successful teams I see are the ones where everyone is invested in UX—I see engineers doing user interviews and testing with their designers.
From my perspective, I’m here to support designers in their efforts. It’s a flat, mostly remote, organization; so, it’s a challenge for sure. Bringing in Design Thinking facilitators, that specialize in remote facilitation, has really paid off. They help spokes make human-centered product decisions as a group, so developers are not left out of understanding or contributing to the experience. Our design researchers have been helping spokes source users to come in and ideate with the teams—participatory design is hands down the best way to ensure people want and can use what we make.
I am always cognizant of the importance that developers have in the ecosystem—if they are having a hard time building on a platform, they won’t do it. Adoption of Ethereum not only depends on design, but on it being easy enough to build on that people can get their ideas out there as fast as possible. That’s a big reason we’ve started work on a Design System: we want to bake in the best of what we’re learning about UX patterns, accessibility, and performance to a system that allows developers without design resources to get farther.
I was attracted at first to the complexity; it seemed like a big challenge to wrap my head around the technical aspect. When I started working on identity, I got a bigger picture of the implications and possibilities. It’s a real chance to give power back to people—over their finances, their data, and their identities. It’s amazing to work in a space and with a technology that has the potential to improve people’s lives globally.
To be honest, I also just really like this community. I could be designing birdhouses and still be happy because these people are really interesting, open-minded, and kind.
Whom to follow, what to read and where to look for inspirations as far as designing for blockchain is concerned?
Crypto twitter is pretty rich with information and some real personalities but can get overwhelming. I especially like MyCrypto and Neeraj. I think if you get the Week in Ethereum newsletter, you can decide what looks interesting and follow from there. Anyone that talks more about building than price is a good bet.
Something I’m trying to be better about is reading books about the industries that are being disrupted or evolved. Things become a lot more meaningful when you understand the history and current practices of things like finance, identity, and economics. So if books-I-haven’t-read-that-are-in-my-Amazon-cart count, then it seems like a lot of people are reading Debt: The First 5,000 Years.
I typically don’t advocate a lot of reading and social media to get started—jumping in somewhere and fully experiencing what is good and what still sucks from a UX perspective teaches you more than Medium articles. I suggest exploring Metamask, Coinbase, Gitcoin, Bounties, Status, and uPort among many others. Just mess with stuff and do tutorials, especially if they aren’t meant for you.
It seems that “educating users on what’s happening” when it comes to blockchain is a challenge. How does it differ from designing guides or onboardings for other platforms or services?
I wouldn’t say it’s so much a challenge; it’s just that no one’s really doing it. There still aren’t enough experienced designers in this space. If people were testing with their users, they would be catching these problems immediately.
I should clarify that there’s a difference between educating people about blockchain in general (kinda hard) and communicating with your users in an interface when they encounter things they haven’t dealt with before (low hanging fruit). For example, I see a lot of users confused as to why they can’t perform an action, and it’s usually because they haven’t unlocked Metamask. It’s not something people are used to having to do, and dapps need to anticipate that type of thing and help people out.
Other than that, I think the difference is mostly about adding in a tolerable friction before irreversible actions and things people need to take seriously, such as private keys.
Sarah Baker Mills
Product Design Director, ConsenSys