A case study using one of the Consensus ’18 hackathon-winning dApps
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.
Hackathon Context
Before diving into the design principles, I’ll skim over the basics of our project here.
- Challenge — The CoinDesk challenge we addressed:
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.
- Team — Our team consisted of 1 front-end developer (Rachel), 2 back-end developers (Saif, Piers) and a developer straddling both and handling the QR code recognition (Paco). I was the UX designer and also collected user and data model requirements.
- Constraints — We started hacking around noon on Saturday, and submissions were due by 1pm on Sunday. So we had only 24 hours to conceive, design and build the solution.
- Technology — We built a mobile application with React Native that each member of the supply chain (farmers, warehouse workers, etc.) would use to enter in and verify package data. We built on the Hyperledger runtime engine and used JavaScript and Hyperledger Composer native languages for the logic and data model.
Hard at work deploying our local blockchain (left). Printing out and testing multiple QR codes (right).
1. Use user personas to frame the problem around people, not blockchain
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:
- Winston, 70-year old farmer**,** white**,** a U.S. Navy veteran, uses an old Android phone, needs his grandson to manage his emails
- Truong, a 29-year old warehouse worker and father of three, Vietnamese immigrant, just started taking night courses for his limited English
- Katrina, a 20-year old CUNY student and Greenmarket intern, white, manages a part of the farmer’s market**,** majoring in Cinema Studies
- Cristobal, a 37-year old associate chef at a local restaurant, Mexican-American, responsible for buying produce in the mornings from the local markets for the day
- Denise, a 42-year old part-time florist and mother of two who brought her family to dine at the restaurant, African-American, just moved to NYC from Mississippi
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.
2. Make complex data entry as easy as possible
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:
Collect only the minimum viable data
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.
Design the flow based on the context
A few things that need to be considered for a complex user flow:
- Device: People prefer bigger screens for complex tasks and data entry, but we were locked into mobile given the need for on-the-go code scanning and data entry. Mobile websites have twice the bounce rate and a third of the engagement of desktop, so you need to fight to keep their attention.
- Type of data: If you’re asking a series of yes or no questions or users just have to select an answer, visualizing it all at once is palatable. But when you’re mixing freeform text boxes, drop-down menus and calendar popups — break up the flow to make it manageable for users.
- Number of data fields per package X packages per day: The farmer had to enter in 7 different data points for each package, sure. But we also had to multiply that by dozens of times per day because of the amount of produce some farms were shipping.
Show explicit progress to keep users engaged
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.
3. Abstract away the blockchain as much as possible
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:
- The hash of his blockchain transaction, full string or truncated
- His participant address
- The block ID containing his transaction (if this was on mainnet)
- The etherscan.io link to the block in which his transaction is being mined (if this was on mainnet)
- The knowledge that his transaction data was stored on the blockchain
- The knowledge that his blockchain provider is Hyperledger
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:
- Above the fold — show the farm, its location, and how fresh the food is (given harvest date). This is maybe 85% of people — these diners are busy and seeing that the food is fresh and it’s from a real local farm is good enough.
- Normal View of the receipt — additional details like the address of the farm and the exact harvest date. A very small number of people, perhaps 10% of consumers, might fall into this group. Partly for boredom or curiosity, they will look at the additional data and then move on with their life.
- Expanded View of the receipt — the previous information plus the actual field of harvest (sometimes different than the farm itself), the timestamp of the various steps of QA, and a tool tip that taps out to an explanation of how blockchain was integrated into the product. A tiny, tiny number of enthusiasts (maybe 5%) will care enough to examine the detailed journey the package of food has gone through.
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.
4. Be transparent when dealing with irreversible actions
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.
5. Don’t hold your users up while their data posts to the blockchain
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.
6. Remove blockchain from your name and branding
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.
Final Thoughts
dApps are still apps, and apps need to be usable
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).
If you enjoyed my thoughts, please clap, leave a comment, reach out via email (kevin0kim@gmail.com) or Twitter — I’m trying to become more active. My next post will build off of this one, breaking down existing popular dApps from a user experience standpoint.
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.