Burn and Merge: Onboarding Tidbits from a Burner Wallet Party

Amy Jung
Amy Jung
Apr 10 · 6 min read

Huge thanks to the Burner Wallet team: Austin Thomas Griffith & Brian for the quick, bespoke technical tweaks, and Jeff of Deepwork for helping host!


One Friday, I decided to throw a party and the designer in me thought it would be fun to user-test features of the Burner Wallet. [Disclaimer: I don’t work for Burner Wallet —it’s a project I’m very excited about]

If you don’t invite people on Twitter, did it even happen?

In a couple of days, we managed to get a bespoke-ish Point of Sale + transaction system up and running. The final flow came out of a balance between working with the existing interface and my desire to push for new onboarding flows. No big deal for Austin, who kept cool while running the Burner Wallet with 2,000+ people at ETHDenver and multiple crypto speakeasies.

Let’s have the users do less

This started as a party with my non-crypto friends (yes, I have those) who usually nod politely as they try to squirm away from the topic of crypto. So I really wanted to try a different onboarding experience that fed curiosity and didn’t feel so “blockchain-y”. Previous Burner Wallet events required hosts to print physical QR codes per item for attendees to scan. In order to get the experience to feel more native with an end to end digital experience, we tweaked the flow a bit. Instructions simplified:

To get your beer at the party, you would receive an email to open your pre-loaded wallet, pick a beer on tap (numbered from 1–50), choose the size/option, write your order (beer number) plus an emoji for a quick, verbal identifier. Click purchase. Pick up at the bar.

We reduced the flow to just 55 seconds from receiving pre-loaded funds to ordering a beer. No host interaction required until you pick up your beer. All mobile. Check it out:

You’ll see 3 new things:

1. Burner Wallet Links!

We wanted to see if it was possible to mass distribute pre-loaded wallets through links. Like an event ticket, instead of independently getting your “drink vouchers”, you’d just open your email and receive a wallet with your $! This could be useful at large events or happy hours to cut out an extra step at registration for getting your vouchers. Plus, no more losing your tiny paper tickets. Heyooo.

But what really happened: As you see in the video, it worked, but not everyone received the emails! (Damn you Eventbrite) Therefore we had a lot more people who we had to onboard directly through the “Receive” function. Additionally, I had to manually set up the email per person since each image is hyperlinked with a unique link per pre-loaded wallet. But hey, premature optimization is the root of all evil.

2. Euros!

Since we were in Berlin, the Burner would have to be in Euros (originally USD). The orders are received and placed in Euros!

What really happened: Since we had about 5 days to work out the whole event, Austin didn’t have time to hardcode without the risk of breaking the whole thing. There’s a 0.88 conversion rate, but it’s a bit buggy. **Important note: we used a sandbox of BURN tokens instead of xDAI/DAI.** But actually, who’s working on the Euro pegged stable coin?!

3. “ATH” — Automated Teller HUMAN

One of the hypotheses I wanted to explore was: would people ask, “okay I used it. What’s next?” If so, what IS next? To keep the momentum going, we decided to set up an ATM of some sorts. Give me Euros and I will top off your Burner so you can order more. Imagine there’s an event with a happy hour that ends after two hours. You want to keep drinking, but ran out of funds in your wallet — load up at the ATH!

What really happened: I ran out of bandwidth to tell everyone about this. We had two out of forty people participate twice for a total of 35 Euros. There were some people who wanted to do multiple transactions so I just gave them some funds + a special party NFT to have them test the “Send & Recieve” feature.

Other notes:

  1. It was a packed Friday night, so the transactions were actually coming in quicker than the bartender had time to fill!
  2. A couple of people asked, “okay, what app do I need to download?” NONE! It runs on a web browser! #Winning
  3. Also, Austin had the brilliant idea of giving everyone 8 Euros — enough for one and a half beers. So whatever you had leftover after your first purchase, you can send the rest to a friend or stranger and get a full beer; making you transact with each other. We managed to get some people to do this, but honestly, it was a lot to explain. We focused more on the ordering flow… Next time!

Nitty Gritty: Simplifying the Vendor Interface/PoS

I chose a place with 50 beers on tap. So many options! Great right?! No. That gave 50 options with all different prices… in addition to 2 sizes (so up to 100 different possible order combinations). We had to reduce the cognitive effort for both the vendor and user.

A logistics nightmare

For each order, the bartender/cashier needs to know two things:

  1. The name/number of the beer (all beers are numbered from 1–50)
  2. The size of the beer (there’s a 0.3L and 0.4L)

We decided to adapt their system and simplify to a number system + Small/Large.

Still, each beer had a different price, so if we narrowed to 2 options (beer number + size), we would lose the accuracy in prices-to-beer ordered. Therefore I calculated the average prices and increased the range to four consumable options, referencing “Craft” as the more expensive cost, and grouping the beers:

  • €3.80: “Small Regular” (#1–20)
  • €4.80: “Small Craft” (#21–50)
  • €5.80: “Large Regular” (#1–20)
  • €7.00: “Large Craft” (#21–50)

Unfortunately, since users were purchasing in-app, this required them an extra second to think about grouping their order into one of the four categories (instead of a bartender inputting the order).

From the PoS side: As the bartender/cashier, you would see the latest transaction come in. Here, you’d see the size, the number of the order, and an emoji or name to identify the buyer.

Wishlist:

Ability to swipe/confirm that a transaction has been completed. Once in awhile, we had to click around to see which transaction has been filled.

Some people (in crypto!) thought it was too many steps. Fair enough. There a couple of ways we could optimize the steps:

  1. If there is a bespoke webpage per event, you can eliminate one step by turning the “Vendor” button in the homepage into “Order” to send the user directly to the order page.
  2. “Purchase” button should say “Select”
  3. Instead of “Send to Address” it could say “Cart” or “Order”

The Entire Flow In Action

Final Thoughts

It was fun to bring together a bunch of Berlin people and I learned a lot. I love all the new projects popping up in the space, but right now, I love focusing on testing and iterating existing forms to make some lemonade out of the lemon tree. Austin’s done a great job of allowing people to roam free and play with the Burner Wallet. If you think this is cool, consider donating to the team. Yay cool open source projects!

More Burner Wallet Fun:

The Repo | Redesign #1 by ETHWorks | Redesign #2 by Patryk Adas

Amy Jung

Written by

Amy Jung

Tech + Design + Strategy. Formerly Design Ops @ConsenSys, Co-grower of raw-haus.co & www.sharedrealities.co