Earlier this month at the 2018 CoinDesk Consensus Hackathon in New York, my team signed up to build a supply chain blockchain app to track NYC produce from farm to restaurant. When I asked the on-site local sustainability worker who the users were, she told me that some farmers who needed to use the app were “70 years old, don’t check their email and can’t use the current Excel spreadsheet system”.
I was stunned. How were we supposed to build a blockchain app for a 70-year old farmer who can’t even figure out Microsoft Office?
Challenges like this will only grow more common, as at least 80% of people in the world do not know what blockchain is. Unfortunately, dApps (apps with some data or logic on a blockchain) for regular people today have bad user experiences. Aside from a few that have tens of millions of dollars of institutional support and dozens of support staff, these dApps consist of poorly-designed pyramid schemes, casino games, CryptoKitties knock-offs and of course, Ether Shrimp Farm.
I didn’t handpick this dApp just to prove my point — according to dappradar.com, this is legitimately one of the most popular dApps today. Yikes.
Our dApp took a crack at this for the Consensus hackathon, and won first place in our division for our solution. In this article, I’ll be sharing 6 key principles for designing dApps for non-technical users, using the process behind our hackathon dApp as a case study. If you’re interested in dApps, blockchain, UX or design, this article is for you.
Before diving into the design principles, I’ll skim over the basics of our project here.
Using blockchain technologies, create a prototype to give trackability and transparency to GrowNYC food supply chain, from farm, to warehouse, to retail outlet, to consumers.
Hard at work deploying our local blockchain (left). Printing out and testing multiple QR codes (right).
Excuse the handwriting…
Based on information I gathered about our less tech-literate users, I developed quick user personas of the people that would need to use this solution. User personas are not meant to be actual people, but humanized approximations of who real users might be to make their problems more concrete:
It may seem a bit fluffy, but humanizing these imaginary users in detail helps you gut-check yourself at various points in the development process.
Gas price and GWEI? Will a 70-year old farmer care about that?
Explaining hashes and showing full timestamps? Maybe that’s unnecessary for a 42-year old tired mother who just wants to know where her apple pie came from.
Use personas to make sure you’re building the product for your end users, not for yourself.
After building our personas, we pieced together the user journey for our app. The below graphic explains how users chronologically would use Localtrail. A package of food is tracked from the farm where it was grown, to the retail location where it’s consumed.
A walkthrough of how various stakeholders in the process use the Localtrail app for a given package
Hick’s Law is a simple concept: the more choices you put in front of your users, the more time it will take them to make a decision. When our users include 70-year old farmers or stressed-out mothers, reducing complexity in data entry and management is critical to the app’s survival. This applies to all apps, but those stakes are even higher when dealing with blockchain, where it’s easy to go overboard with data**.** Here are three helpful tactics:
We favored simplicity over detail in our data model — for each package, we prioritized the fewest number of data points possible for trustless verification, like the type of food, the quantity of the food and the quantity metric. Adding extra mandatory fields usually increases the abandonment rate of a form, so extraneous data like purchase information didn’t need to be on a blockchain. If you’re using a public blockchain and are subject to gas, being rigorous about what data is pushed to the blockchain becomes even more important.
A few things that need to be considered for a complex user flow:
Your brain generates dopamine after completing a task — gamifying experiences with points or levels is a classic tactic to keep users coming back for more, especially when dealing with boring tasks like data entry. Particularly for blockchain-related data, a single moment of frustration in the flow can cause a user to leave and move on to one of the hundreds of other things they have to do that day. Because of this, it’s critical to give users visual answers to questions like “how far through the process am I?” and “am I done, or is there more?”
The farmer flow is broken up into smaller chunks, making a complex process very simple
Taking the above into account, we landed on the above flow that had more steps and less complexity per step. One long scrolling screen might be more time efficient, but I pictured Winston squinting at his screen in direct sunlight on his farm, his thumb hitting the wrong form fields scrolling through his low-end Android. So we opted for a direction that had many simple screens, one after another, asking for only the minimum viable data that would be posted on the blockchain.
We also opted for a visual timeline that conveys to the user that there are discrete steps in this process and while in the middle of this process, they can go back or keep moving forward. One inspiration here was Intuit’s TurboTax app, which does a great job of splitting up the impossibly complicated task of filing taxes into many bite-sized chunks.
Here’s a list of things that 1. don’t help Winston the farmer do his job, and 2. might confuse him to the point of giving up on the app:
Frankly, it’s not important for a farmer or a warehouse worker to know that their transactions are being posted to a blockchain at all. For a supply chain app built on a centralized server, would we explain the nuances of server redundancy or AWS Lambda in the farmer flow?
The earlier principle of collecting “minimum viable data” applies to showing data as well — we should only show the minimum blockchain data necessary for the specific problem space and users. Blockchain data scares most people. That’s why we removed that data from the Farmer Flow.
We can apply this concept to the End Consumer experience as well, where people at places like restaurants are scanning a QR code to see where their food came from. Here’s how I prioritized the data:
By adding more friction to the consumer experience as the information became less relevant to the users, we’re valuing their time, but providing an option to see more if they want to do so. We’re not taking away control from users by making it harder to see data — we’re being respectful of their busy lives.
When users are about to make permanent decisions with lasting consequences, clarity and transparency need to be baked into the design. For Localtrail, it’s not important for these users to know that their transactions are being posted to a blockchain — but what is important is for them to know that submitting or verifying package data is irreversible.
Convey security without conveying blockchain
To get this across, we added careful copy that emphasizes that submitting that data is final and cannot be edited once posted. We abstract the technical cause of that to the fact that we’re storing their data in “a transparent, secure way”, and incorporate the familiar iconography of a the lock and the cloud, two concepts that users in 2018 are familiar with, to convey the immutability of their data storage.
It is not important here to the farmer whether package data is in the process of being appended to the blockchain vs. has finished being appended. Each step in the flow requires the right type of data to advance and our app was built on a permissioned blockchain (no gas), so there’s no way for a transaction that was submitted to fail. Even on public blockchains, after a transaction is submitted you can provide muted updates through notifications and small modals while the user does something else.
Instead of a loading screen while the data is appended to the blockchain, we provide Winston immediate actions to take, designed with priority in mind
What’s truly important is clarity around what their next action should be. Most dApps lack a post-transaction assurance that the user can move on, which can be frightening for less tech-literate users. We provided a prioritized set of buttons: a higher-priority “New Package” button (likely what the farmer’s next action will be), and a lower-priority transparent “View All Transactions” button.
We designed the app to help Winston focus on his most important tasks, not add unnecessary cognitive load.
Our choice of the name Localtrail and the tagline Community-first transparency in the supply chain was intentional_._ Most blockchain-enabled companies have the words block, chain, bit or eth in their name. That might be OK if your users are developers or enterprises, but for regular consumers, it’s better to focus on the actual problem you’re solving.
We wanted to reinforce our focus on the user and their problems in their local community. Even in the logo, you don’t see any chains or cubes — ours is a farm, the origin of the community supply chain**.** Jia Wu showed me an existing supply chain solution, Provenance — that takes a similar approach.
Provenance.org’s landing page — nary a mention of blockchain in sight!
Nowhere in the site until you click on “Technology” do you see a mention of blockchain. Their “Every product has a story” tagline focuses on conveying their mission and the value they provide to customers. That’s how it should be done.
There’s a perceived tension in the blockchain community between the traditional UX mantra of simplifying the user’s experience for them, and the decentralization ethos of giving full control and transparency to users. In my mind, this tension shouldn’t exist.
Hashes and Merkle tree proofs might instill confidence for dApps in banking or enterprise-grade data storage. But if we’re talking about consumer-facing dApps where most to all of the users have no idea what blockchain is — we have to be able to let go of the desire to aggressively prove trustlessness as much as we can. All that data isn’t helping anyone if only 1% of users understand what it means.
The most successful startups focus relentlessly on connecting with their users and making something that people want. That doesn’t change just because some of the code or data lives on a blockchain. We will only achieve mainstream adoption of blockchain if we deliver great user experiences.
All of the Consensus 2018 hackathon participants (left). Our awesome team (right).
Thanks to Saya Iwasaki, Sara Sodine, Elan Kiderman, Bo Ren, Vijay Menon, Charu Jangid, Dan Shipper, Tarik Bellamine, Brian Flynn and Mitch Kosowski for their feedback on this article. Thanks to my awesome teammates Rachel, Paco, Saif and Piers. And thanks to beltran and Sarah Baker Mills for influencing me with great pieces.