Tipper is a companion app for Twitter exploring the possibilities of new payment technologies. In creating Tipper, I owned the design of the product from market analysis and concept all the way through the launch of iOS and web applications.
The Design process focused on nurturing consumer trust (absolutely table stakes in the financial space), trading addressable market size for consumer value proposition, agile pair production between design and development, and altering consumer behavior in an entrenched market.
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,' enabling new use cases in various markets. Historically considered impractical (due to the transaction fees necessary to support legacy payment systems), there is now a fervent community exploring this fresh financial white space, newly unconstrained by fees.
In particular, one use case 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.
It's worth pausing for a moment to re-state that never before has it been possible to transact in tiny amounts of capital in real time between trusted parties.
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. Having decided to optimize the entire experience for a selective market, we need to visualize all the touch points between players, objects, and programs that make up the guts of our system. Shown below is this first visual map.
In a pared down version, we isolate the most important aspects of our system: user actions (likes) and tipper actions (tips).
Confident about what we want to design, it's time to evaluate how it will be designed.
We identified three MVP functions to focus on for our functional design:
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. The New User Experience is a crucial touchpoint in the user journey that can truly make or break the way a user feels about (and ultimately continues to use) your service.
1. Splash Page
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 more simple 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.
We want to welcome you with our cute stick figure (and hope you don't suffer PTSD from Microsoft’s Clippy).
Working with very simple language, our goal is to communicate the kindergarten-level education to our users without scaring them off. "When you do A, we'll do B."
We included a snip about the actual value of the Bitcoin being sent for tips, since 0.005 BTC is a foreign metric for most of us. 10¢ was our goldilocks number given it isn'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!
3. Apple Pay
Getting users to actually put money into a system is an extremely difficult task. The question of where to place this request could be debated to no end, but we decided to do so upfront in hopes of converting early, while including an option to skip and return later.
By using Apple Pay, we've once again sacrificed a portion of our addressable user pool while gaining a massively streamlined payments UX. Two taps and you're done. Entering payment credentials? Ain't nobody got time for that!
Notice the moniker for “Bits” below the “$” amount. This was a custom created font that allowed us to represent Bitcoin in an amount greater than 0 (while $5 of BTC is worth around 0.02 BTC).
Notifications need pre-prompts! The Notification channel is perhaps the most valuable an app can have to a user (the digital equivalent of going steady) so custom prompts should speak directly to the value you are offering. In this case, we've framed it as a way to tell you about the money you’ve received.
"These can be configured in Settings," is just another way of saying "trust us for now and change this later if you wish."
5. Experience + Investment
The true moment of experience and investment comes at these last two steps, where we show users what Tip stories will look like in their feed and then inform them that our Tipper Bot is about to Like their Tweets and send them a few tips. The effect is threefold:
1. The user experiences a real-time example of how the system works, seeing Likes on Twitter result in Tips on Tipper.
2. The user’s account becomes cash positive (even if they didn’t purchase BTC yet), meaning they will now start sending tips with their Likes.
3. Tipper’s persona extends beyond the app where Tweets carry links back to Tip stories on our website, exposing stories to this user's friends and followers.
6. Greasing the Rails of Retention
By the time our new user sees their home screen for the first time they are greeted with active an dashboard of inbound tips and system notifications. Since their account is already carrying capital, the next Tweets they Like will generate outbound tips and bring more accounts into our system as recipients, whose tips will be waiting for them should they convert as well.
Bringing these assets into the prototyping stage, we put together an iOS demo for user testing and iterations before shipping polished specs off for development.
As mentioned previously, I also led the strategy and design for Tipper’s web presence. As a crucial component of the user journey, the web product serves three major use cases:
Landing page for user’s to find and download the app and/or learn more about the service (FAQs, T&C’s) -- this type of page typically accompanies a mobile app and there are many templated services to support quick and easy web hosting but we opted for a custom design for the elements described next.
Live feed displaying the real-time transactions happening on the network via twitter stream (including user handles and transaction links to the blockchain) -- this effectively serves as the "pulse" of the service, giving visitors a glance at what's happening and promotes a perception of activity.
Discovery mechanism for users who visit via links from twitter (unique transaction stories) -- this is our viral loop opportunity to convert newcomers who find us by way of Tweeted transaction stories.
Sketching for Desktop and Mobile
It was important to design with both desktop and mobile in mind, given our users are on either platform. Typically, I like jumping back and forth between these platforms when mocking up UI designs, allowing the constraints of mobile to inform a clean and limited design on desktop.
One useful additional elements on desktop is the "text-to-phone" link, allowing users to get a direct download link on their phone instead of figuring out how to download a mobile app from their desktop. On mobile, we can just send users straight to the app store since they're already on the necessary device.
Ship-Worthy Web Assets
The high-fidelity design phase is an opportunity to breath character into our mocks, like the backgrounds and layering that chunks our elements into intuitive sections. Once finalized, designs are spec'd and sliced for easy implementation on the development side.