Tipper is a sexy-idea-turned-side-project exploring the possibilities of new payment technologies. In creating Tipper, I partnered with a technical co-conspirator and owned the design of the product from market analysis and concept all the way through the polished design of an iOS application and accompanying website. In doing so, I learned many valuable lessons about designing for consumer trust (absolutely table stakes in the financial space), pair programming between design and development, and the challenges of altering consumer behavior in a massively entrenched market.
Hacking White Space
For all its controversy, Bitcoin is an incredibly flexible and secure digital asset enabling entrepreneurs and companies to explore new payment systems. One such adaptation is a new class of payment that amounts to roughly less than one USD (and as small as a fraction of one cent) known as 'Micro Payments' that opens new use cases in various markets. Historically impractical due to the transaction fees needed to support legacy payment systems, there is now a fervent community hacking this freshly exposed financial white space unconstrained by fees.
In particular, there is one use case that has me especially interested. Perhaps due to my background in (and love/hate relationship with) digital advertising, I see a future where third parties (advertisers) needn't participate in the commercial monetization of nominally valuable web content brokered between publishers and consumers. Today, consumers pay with their attention, quality of experience and personal data when publishers embed disruptive advertising and tracking within free content. The content is "free" because it is advertiser-subsidized, but the consumer still "pays" in non-monetary costs.
Assuming a first-world consumer can stomach a 1-cent cost per ad not shown (less cluttered, less data, less tracking), the economics are unquestionably favorable for publishers as well, who stand to make roughly 10x per user compared to standard advertising rates. The system designed to support this paradigm will look something like the following, with the user's wallet passively paying publishers in micro amounts of digital currency the same moment content is consumed.
Bootstrapping a Micro Payments Platform
Before we get ahead of ourselves and try to change the world, we need a way to get users installed (web or app store), banked (convert USD to BTC), and configured (approved) to start sending payments passively. We also have the problem of getting publishers onboard our system, a practically insurmountable challenge we'd conveniently ignore until we garnered some form of consumer traction.
As we considered the design this product, several decisions were made to limit the potential audience size in favor of streamlining the product. Some examples are the platform (iOS), the credentials (Twitter), the payment system (Apple Pay) and the actual currency used (Bitcoin). If you slice your addressable audience pie with this many constraints, you’re going to end up with a much smaller pool, however, you are much more capable of making an excellent product for this small pool of users.
“Better to make a few users love you than a lot ambivalent.” - Paul Graham
We landed on Twitter as the ideal train upon which to hitch our early-stage wagon, largely due to the simple/open nature of the network (Accounts and Likes), but also because that's where the nerds like to hang out, and nerds LOVE Bitcoin. Getting users installed and configured to start sending Micropyaments along with their Twitter 'Likes' proved to be a much easier (yet still challenging) way to test and iterate on a live payments platform. With this strategy in mind, our system design resembles the following relationships and flow of data.
The design process begins at a 10,000ft view. In order to build something graceful enough to feel like magic, we first needed to understand all the touch points between players, objects, and programs that make up the guts of our system. Shown below is this first visual map.
If this seems confusing, that's because we're optimizing for inclusion rather than education at this point. In a pared down version, we've isolated the most important two aspects of our system: user actions (likes) and tipper actions (tips).
Seeking a unified solution for our application, we identified three MVP functions to focus our experience
- History - inbound and outbound "tip" history
- Balance - live value of currency held in systems
- Funding - set of actions to take when funding is needed
Sketching these out individually and intertwined, we played with various versions in low-fidelity states before committing to anything in code.
Through much exploration, we would find that combining Balance and History into the main screen, while dedicating primary navigation to Prompts and Settings would provide the best user experience. Prompts (or Notifications) was included after user testing identified a need to prompt specific actions from the user, such as topping off your account with more funds. Here we see the high-fidelity mocks that were born from multiple sketch cycles. Designing in Sketch allows us to prepare all the assets - first for prototyping and finally for development.
Wiring up a quick prototype, we see our planned microinteractions at play, such as how the pages scroll, how new pages enter view, and how icons change depending on view state. Still no code, and yet we're able to continue testing assumptions and iterating our design based on a very realistic experience.
New User Onboarding
We now have an app that we understand, but in order to design an app that new users understand, we need a new user onboarding flow, or NUX, to educate newcomers on our platform.
1. The first thing a new user sees is our Splash page, complete with appropriate branding and intelligible product positioning. "Attach Bitcoin tips to Twitter Likes.” Doesn’t get much simpler than that!
Across the bottom of all onboarding screens we’ve designed a large, persistent white bar, requiring as little effort and intelligence as possible to usher users through the education and permissions prompts.
2. Ah, we’ve got some personality here! Nothing too crazy, but we want to welcome you with our simple stick figure (and hope you’re fully recovered from whatever traumas suffered at the hand of Microsoft’s Clippy).
Again, working with very simple language here, our goal is to communicate the kindergarten-level education to our users without scaring them off.
We included a snip here about the actual value of the Bitcoin being sent for tips, since 0.005 BTC is a foreign metric for most of us. 10c was our initial capital amount given it wasn’t too much or too little. You can throw around dimes all day without much concern, and at the same time, those dimes add up to dollars!