How I Designed a Blockchain App that Reached 200K Users in 6 months

Rolando Mathias
We’ve moved to freeCodeCamp.org/news
10 min readAug 24, 2018

Primablock is an Ethereum smart contract SaaS that handles the accounting and remittance work for the ICO pooling and investing process. My two co-founders and I started it as a side project for our small community, in response to friction in our workflows. In late summer 2017, we launched to ~50 people. A few months later, users started to pour in from around the world at a startling rate. During my tenue, we served a few hundred thousand users and processed ~$500M transaction volume.

In this article, I’d like to share with you my design process.

An early user testimonial from PB’s active Telegram support channel.

User research: Discovering the needs of the ICO investment community

We analyzed user behavior to understand the workflows and pain points of our target. We had the fortune of being part of the community we were building for, so empathy was a precursor.

“It’s precisely this sort of observation-fueled insight that makes innovation possible.” - Tom Kelley, The Art of Innovation.

From a high level, an ICO deal flow looks like this:

Bird’s eye view of a typical ICO deal flow. This is what we observed when we joined our investment community.

We segmented our user base into two groups: Admins and Contributors.

Admin

Our questions focused on different parts of the work flow, but we were precise about the wording to make our interviewees recounted specifics, instead of generalizing about an approach, which is a known user research pitfall.

  • The last time you created a pool, what frustrated you about it?
  • The last pool you administered, how did you keep track of each contribution?
  • Have you ever had to refund a pool? In the most recent time, what was the process? What frustrated you about that process?
  • How did you distribute tokens to your contributors? How did you calculate shares?
  • How has your workflow evolved from deal to deal?
High level flow before PrimaBlock’s solution, which shows all of the pains and pitfalls of their existing workflow.

Contributor

Similarly, the questions to our contributors also focused on the different parts of the workflow.

  • The last time you contributed to a pool, what concerned you?
  • The last time you received tokens, what concerned you?
  • Has any part of your workflow evolved from deal to deal?
  • Please walk us through contributing to and organizing X deal.

The critical incidents that affected all of the Admins: 1) solving the complexity around the accounting work and 2) the seemingly endless number of tedious wallet transactions. The common thread among the Contributors was trust. Because of the blockchain complexity, they didn’t trust themselves to make transactions properly, or trust the Admins’ to do error-free accounting.

The solution: Lowering barriers to entry with accessible design and blockchain tech

Mistakes on the blockchain are irreversible, so scams are a constant concern. Primablock’s UI pulls the curtain back on how the process happens, which gives users the ability to actually perform the transactions and peace of mind that they’re doing the right thing.

We created a platform on which anyone can interact with Ethereum smart contracts. Users are still required to send transactions externally (as I’ll explain later), but Primablock provides them with clear instructions on how to do so. Previous to us, only experienced, technical minds were able to figure out the type of information we made accessible.

A high level user flow of our solution which solves nearly all of the pain from their pre-PrimaBlock workflow.

Blockchain constraints changed the way we onboard

PrimaBlock is a two-sided platform that serves Admins and Contributors, both of which have the same end goal. The Admins, however, do most of the heavy lifting by creating the pools and setting the terms by which Contributors can invest. When I mapped the flow with all of the customizations, I was concerned about the abandonment rate. The alternative was to only require the absolute minimum (wallet address) and allow Admins to customize their pools after deployment.

These are all of the customizations we surfaced to Admins during onboarding:

All of the customizations we surfaced to Admins during onboarding. The big question was whether to postpone the optional ones until after initial onboarding. However, each customization requires a wallet transaction.

We front-loaded the customizations for two reasons.

  • I spoke with Admins about their workflow, and they always had customizations planned out before creating a pool.
  • Every customization requires a transaction on the blockchain, which costs gas. So, if we postponed customizations until after creating an Admin’s pool, they would likely spend more on gas and bear the tedium of more transactions.

Ultimately, since this is a serious financial process, Admins are very methodical and deliberate about creating pools so they expect to invest time during onboarding.

There are three versions of Admins onboarding.

Version one of onboarding included tool-tip definitions that require a hover to reveal important information. All first time Admins (and many returning) were surfacing this information, so we removed the need for extra interactions.

Version two surfaces the info on side panels, but we noticed:

  1. Users didn’t assume that the panels had relevant info, and
  2. It was annoying to look back and forth.
v1 shows all of the customization in 1 page. v2 presents them step-by-step with a side panel of explanations.
v3 onboarding flow includes 1) step-by-step customizations with in-line explanations, 2) a checklist confirmation, and 3) a deployment portal (with pre-filled data to make the transaction on mycrypto.com). Illustrations: undraw.co/illustrations 🙏

Educating noobs: our biggest challenge

ICO investing relies on blockchain infrastructure, which poses a steep learning curve because of its unfamiliar processes. Our first version fit our early adopters well for the types of deals we saw while building the product.

But, we ran into many issues as we scaled to new users and deal types that presented new use cases. To that end, the three of us added full-time customer support (via our Telegram channel) to our duties. The support work proved to be incredibly helpful to regain the beginner’s perspective and stay in tune with the rapidly evolving industry.

Side panel: in-app documentation

There are two levels of in-app support:

  • Tool tips use hover states to expose secondary information, mainly definitions.
  • Critical information used to address different use cases that come with the nuances of different deals is on the side panel.

We used our experience in customer support to create content and organize the side panel and FAQ.

Tool tips and side panels to cover important definitions and common use cases.

Abstracting away from the blockchain (comes with a cost)

PrimaBlock accepts the complexity of smart contract calculations and interactions from its users. The simplification has many value adds, but it requires the platform to give feedback to users so that they know what’s happening.

Our biggest shortcoming was not providing this feedback. The anxiety on users compounds because blockchain transactions are irreversible and can have long, inconsistent processing times. Blockchain products typically violate the Doherty Threshold, which states that productivity and satisfaction increase in direct proportion to a decrease in response time.

Since all of our users are accustomed to the speed of centralized networks, they have impatience with the decentralized sort.

Version 1 had typical loading spinners but they spun up to several minutes depending on user and network variables, leaving users in the dark. Here are two categories of information to give our users peace of mind: banners and contextual messages.

Various notifications for status updates and contextual messages about next steps in the process.

How I’d improve notifications (and the product)

With more resources, my team and I would have allowed Admins to write notes in a dedicated section of the UI so that their Contributors would have specific info about the status of their pool. Our notifications were helpful but they covered all possible use cases for a given pool status. They lacked customization. Contributors and Admins still had to communicate externally to clarify things. Additionally, users are subject to banner blindness in regards to the current notifications even though the info they present deserves high importance in the visual hierarchy.

Transactions are the core of everything

“The only problem I ran into was not setting my Gwei in Metamask high enough, so my order got held up and I missed the boat on one ICO.” - PrimaBlock user.

A user must perform a transaction with her wallet in order to take any action with a smart contract. PB does all of the calculations and provides the data that will get users the results they want.

It was important to expose the transaction data because it showed how we were replacing and improving their previous processes. We did this from the first version and users appreciated the ease.

Once we built trust and comfort, we added a shortcut to remove the number of interactions required to complete a transaction. In the below image, users can pre-fill all of the transaction data with one click (“Send with MyCrypto” CTA).

FIrst version of pre-filled transaction data. It was easy for users to relate this data to required inputs in mycrypto.com (formerly etherwallet.com). Second version adds a one-click CTA (“Send with MyCrypto”) so that transaction info doesn’t need to be copied individually. Huge time saver!

Even our early users needed tips on the finer points of making a fast, cost efficient transaction. Sometimes, not knowing this information means losing out on a deal because your transaction didn’t process fast enough. Other times, it means losing the money you invested in gas because you didn’t invest enough to make the transaction succeed.

Second version of pre-filled transaction form adds a one-click option and auto tool tips for questions that we received daily, even with hover state tool tips.
v3 pulls in data from http://ethgasstation.info. This solves another of our most common customer support questions.

Giving Admins control: the whitelist journey

When we were building v1, many Admins wanted to make their pools exclusive, to reward people in their community and/or not risk exceeding their ICO allocations. If an Admin wanted to enforce a whitelist manually, they would first need to make an effort to not let their contribution address become exposed to uninvited parties. These efforts were usually in vain, so they’d then cross reference all incoming transactions with an address spreadsheet. Then they’d have to manually refund (time + money) unwanted contributions.

We solved this tedium by creating a whitelist feature. However, version one had shortcomings, because we didn’t build for the nuances that many Admins needed.

  • First, we didn’t anticipate that whitelists would change, along with allocation amounts, during one deal cycle.
  • Second, as the industry evolved, KYC requirements became crucial as deals wanted to avoid the wrath of the SEC. Unwelcome guests have caused entire deals to collapse.
  • Third, because of the smart contract’s flexibility, there were different interpretations of the nuances of how the white list works, as shown by the quote below.

“One person I talked to was surprised that changing the max contribution threshold would evict people who previously contributed even though their contribution was higher than the new threshold.” - PB co-founder, Tamir.

In short, Admins wanted granular control over their lists and to be able to edit based on deal progression.

The whitelist flow gives Admins granular control over their whitelists and lets them see how updates to the list will affect the pool. 1 shows their existing list. 1A is a modal that allows them to add addresses. It detects invalid addresses and duplicates, which solves a common pain for Admins as they collect, copy and paste addresses from the spreadsheets. 2 shows how adding and removing addresses will affect the pool.

Visualizing pool history without hacks

“Hey wondering is there a way to find out what pools I have contributed to through Primablock? I’m worried about losing track of them all and don’t know how to find everything.” - PrimaBlock user.

We had a pool history feature on our roadmap from our early days, but we didn’t prioritize it because our early users were savvy with external resources (like Etherscan) to track their transactions.

One pain that not having pool history caused was that, if a user was searching for a pool they contributed to or administered, they would have to find the contract address and then search for it in the app. As we scaled and kept aiming to improve the UX, we wanted to present as much valuable info to our users from within our service. The need for this became more crucial as our users had to satisfy tax reporting obligations.

The pool history feature is a recent addition that allows users to track their PrimaBlock activity under one roof — no external sources needed.

We created this after having several months of live product experience under our belt so we nailed it 🔨 on the first try.

Winning growth strategies 📈

After the product was up and running, we started to think about growth strategies that would create network effects.

My co-founders and I brainstormed about possibilities within the smart contract constraints and we came up with chaining. Fortunately, my co-founders are wizards on the backend and are able to seemingly solve anything. Chaining was no exception. This allows users to create child pools that feed into parent pools.

Instead of building out the feature, we started with a concierge MVP to provide the service manually. It was well-received, however we ran into some push back from Admins because the chained pools undermined the whitelists. My team fixed that on the backend in no time and we were up and running 🏃🏾‍.

Chaining a child pool into an existing parent pool incentivizes more users to create pools. It’s a win for all parties.

Chaining was a big success because it opened up pool creation to the vast majority of users who didn’t have access to ICOs to make their own deals. Chaining incentivizes users to recruit people from their network who would potentially make money and ultimately pay fees. It was an all-around win.

Wrapping up

I left PrimaBlock in April 2018. It was a remarkable experience that I never expected to have when I made my foray into the blockchain as a casual investor. I am happy that I had the curiosity and passion to solve a problem that needed solving. I am even happier that I had co-founders/developers, Mickael Fourgeaud and Tamir Sen, whose work ethic and talent on the back end is unparalleled. They deserve most of the credit for the success of the product.

“[PrimaBlock] brand loyalty is unlike anything I’ve seen in the space.” - Hen Tekle, Angel investor/Advisor

I encourage everyone in the tech industry to put their whole selves into solving problems. You have the opportunity to create so much value around the world with some pixels and code (not to mention long days and late nights). I’m grateful to have worked with - and continue to work - with talented people. I’m more motivated than ever to see what else I can solve.

If you have any comments about PrimaBlock, please post here. Anything else, check out my portfolio.✌️

--

--

Rolando Mathias
We’ve moved to freeCodeCamp.org/news

Product Designer 💻📱crafting experiences in Stockholm. From Brooklyn. Crossfit'er 🏋️‍ https://rolandomathias.design