How I Designed QuickBooks GoPayment
Individuals and small businesses all over the country make products and perform services for millions of customers every day. Oftentimes those products are sold and those services are rendered away from the small business’ storefront. The need for mobile Point of Sale systems is growing as more and more small business owners are bringing their business to their customers rather than making their customers come to them.
QuickBooks GoPayment is an app and card reader duo that allows small businesses and individuals to take credit and debit card payments with ease. GoPayment also integrates smoothly with QuickBooks, making it easier to manage accounting and taxes.
Intuit launched the first version of GoPayment in 2010, but the design was rushed and weak from both an interaction and visual design perspective. I joined the team in the midst of a complete redesign/rebuild from the ground up (including the code stack). I owned the interaction and visual design of the first time use (FTU) experience within GoPayment.
Business goal + design challenge
Working with the product managers, Willy and Mary, we established 3 main areas that needed some design love. Two of these areas were identified based on usage data gathered by Willy and Mary and one was identified through qualitative feedback in early user tests.
- Users are not making it through the signup process (from quantitative data)— unfortunately, as an app that moves money and takes on the risk of fraud, we can’t just let users hit “Sign Up with Facebook” and call it good. Before GoPayment users are authorized to take payments we need them to apply with Tax IDs or Social Security numbers.
- Users are making it through the signup process, but not taking a first payment or becoming an active user (from quantitative data) — through conversations with existing users and potential customers we identified one of the reasons for this drop off as a lack of confidence that they know how to use the app which leads to use-inertia.
- Users are having bad experiences with our app’s device permissions (from qualitative feedback) — many of the customers we watched go through the FTU flow would express confusion about what was being requested and why.
Constraints
As always, this project came with several notable constraints. As mentioned above, the signup flow could not be abridged in terms of input fields — reducing the information we collect would drastically affect our ability to avoid losses due to fraud. Our risk team also needs us to require location tracking for the app to function.
Additionally, with regards to device permissions I was constrained by Apple’s restricted dialog boxes, the phrasing of the permissions question and one-shot-only policy (on iOS devices you may only ask for location or microphone permission once — if the user chooses ‘Don’t Allow’ you may give instructions, but the user will have to leave your app and open the settings app to change the device setting). In order for the user to use the card reader plug-in we need them to allow access to the ‘microphone’ jack.
Research and empathy building
I began research by printing a large art board with our first time use flow and then creating swim lanes comparing our flow with competitors.
Then I invited 6 potential GoPayment users to come in and let me watch them sign up for GoPayment and try it for the first time. One of the stumbling blocks for most users was the device permissions. They would wonder why we were asking for that allowance or they would be in the middle of the process of taking their first payment and accidentally hit ‘Don’t Allow’ when it got to the microphone/card reader permission prompt.
I did some serious sleuthing on the subject and here’s what I found: There are two schools of thought when it comes to device permissions.
The best practice in most situations is to wait to ask for the device permission until the point of need (when you tap the camera button in SnapChat for the first time you can safely assume they will grant access). This works great for social apps especially when the request is intuitive to the user.
The other school of thought, and I would argue this is the exception to the rule, is to put the request up front, as part of the initial signup or getting started flow. The main reason apps use this strategy is because it eliminates the risk of fatally interrupting a seller’s experience with their customer. For apps that are used under pressure eliminating the risk of a mistap is almost always worth the annoyance of doing the setup up front. We also found that other payment apps employed this strategy.
This approach forces the user to do make sure their settings are prepped for a good experience with their customers. Some users we talked to told us horror stories of ringing up a customer and then accidentally pressing ‘Don’t Allow’ when they were prompted for access to the card reader. This meant they had to go to the settings app to redact their tap, losing face with their customers as they stand there waiting. As Brenden Mulligan points out in his article on The Right Way to Ask For Permissions:
Making it all worse is that when a user taps “Don’t Allow”, there is no easy way for them to reverse that decision. It takes 5 steps to grant access later, and there’s no way to help a user navigate to the right screen besides actually listing the steps out.
One rule that both schools of permissions thought completely agree on is that the reason for the request should be explicit and clear. This was something that was missing from our past design.
I also did a survey of apps outside our competitive space to find other creative visual and interaction treatments for simple walkthroughs.
Many apps combined some form of a text box with a pointer or floating orb to direct your attention. The best walkthroughs focused on the key functionality and transitioned smoothly. After the quick walkthrough you felt confident you could navigate the app.
Ideation
Armed with all this, I started mapping out a schematic diagram of everything we needed to keep track of (along with some things we may want to A/B test). This included the various signup forms, the three permissions prompts, and the key app walkthrough pointers. This schematic was shape-shifting pretty steadily throughout the duration of this project, but I kept updating it as new insights presented themselves and flows were changed.
Watching users signed up helped us find the places in signup where they were most likely to get stuck. For example, we learned that users don’t generally have their Federal Tax ID on hand so when I sketched out these early ideations I made the Tax ID optional. I really wanted to find some ways to expedite the sign up process for our new users so I experimented with cutting out the business category screens. I also played with messaging that built confidence that the user was in good company in signing up for GoPayment.
I created these sketches to quickly explore how the various approaches to walkthroughs and pointers that I found in other apps might work with GoPayment.
Prototyping, iterating + tradeoffs
Time to start using a mouse. I took some of the best ideas from the pencil and paper and started creating them digitally. My software of choice is Sketch 3. I used Flinto to build click through prototypes with different variations.
Click here to see one of the early prototypes I built to test a sign up flow with users. We got great feedback when testing with users; things like “I like that it tells me which pricing plan is the better value” and “I wouldn’t enter my bank account right now because I don’t have my checkbook on me and I don’t have my routing number memorized.”
Here are some of the early permissions interaction designs. These were intended to show the user up front how many things we were going to ask them for.
We found that the card approach got better feedback with the underlying reason being that the cards felt like quick chunked tasks that flew away after being accomplished — the “quick win” phenomenon. Plus the difference in the visual style helped to differentiate this phase of setup from sign up.
I also came up with mappings of what happens when you tap ‘Don’t Allow’ with one of the required permissions. You can try that in this Flinto prototype.
Here are some of the variations I mocked up for the walkthrough.
We prototyped several and liked the visuals on the concept below, but found that the green bar at the bottom covered or smushed critical parts of the screen.
So we tried a slightly altered approach.
We found that the floating instruction boxes allowed the user to see the app without altering the keyboard (a change that would’ve required unnecessary technical efforts) and it made the walkthrough a bit more engaging by moving around the screen a bit.
Results
The latest version of GoPayment was released to the App store summer 2015 with a portion of this work implemented in the launch. Some parts, including much of the walkthrough section are slated to be released later this year.
It’s still a bit early to measure how much the redesigned signup flow has affected the funnel and to measure how the permissions redesign has affected incidents in which users are kept from using the app because of device settings, but based on prototypes and feedback we’re very optimistic.
Special thanks to Jake, Brandon, Willy, Sherry and the rest of the mobile design team for your consistent awesome feedback and determination to make a truly great first experience with our app for people just getting started with their small business dreams.
If this piqued your curiosity, read more of my How I Design
design process stories.
And check out my portfolio at jacobmclaws.com.
