Background

Fivestars in the past year built a payment product from the ground up. While that was incredibly impressive to bring to market so quickly, we still had a long road ahead in terms of having feature parody with other competitors. One of those significant features was offline mode - being able to process transactions without an internet connection. 

Here are a few of the issues and challenges Fivestars and our merchants face:

• There will always be impediments to processing payments

  • Unplanned & planned outages

  • Fivestars, merchant and externally driven issues

• Merchants use Fivestars in a wide variety of environments

  • Different wifi providers

  • Different physical setups in their stores

  • Different hardware combinations

  • Different geography

Team

The people I worked with on this project were my product manager, my design manager, head of product, and my entire engineering scrum team. 

Problem

As we started to plan how we wanted to tackle offline mode, we wanted to solve as many scenarios as possible, allowing the merchant to process as much as possible.

Here are the main scenarios we were looking to solve:

• Authentication is down

• Pay server is down

• Router is off

• High Messenger Latency

• Messenger down

• High upstream latency

• ISP down/upstream down

• Wifi setting off

• Everything down

Goals

A few of our goals when starting out were

1. Process transactions in as many scenarios as possible

2. Make this a seamless experience for both the consumer and cashier

3. Communicate clearly that the cashier is offline mode

Research

Research was an integral part of building offline mode. When we send out surveys to merchants to ask what features were most important to them, offline mode would consistently be at the top. Research also studied competitors to see what were we would need to build to at least be on parody with them. Those included POS players such as Square, Clover, and Toast.

Process

Initially when I started working on the project, I foolishly thought this would be an easy task - simply remove all the Loyalty API related screens from the flow (sign-in and rewards). But as I began to dig deeper into this, I found that no internet connection changed everything.

Because this was such an engineering heavy project, it began with very early talks with engineers. Since they had not found a solution before I started designing, we were working in parallel, sharing information as we progressed. 

One of the first tasks we needed to figure out was which scenarios would we solve. Would it be when the ISP was down, when the API was down, or when everything was down? There were long list of scenarios and each of those would drastically change the flows of offline mode. After we figured out which scenarios we would and wouldn’t solve, it gave us a clear path towards designing a flow for offline mode.

The next problem to solve was how would we think about offline mode from a high level. Would there be two different flows - an online mode and an offline mode? Would we allow bouncing between those two flows if we were to come online mid-transaction? Would there be a hybrid flow with screens that would restart a transaction if it went offline? After building out wireframes for each of these scenarios, we decided on two different flows - an online and offline. We felt that this would make for the easiest engineering framework and easiest way to think about offline mode. 

After deciding on how we would think about offline mode and a general idea of the flows I began to wireframe more. One of the big things we had to think about was rewards and loyalty - a key component of our product. Without an API that was up, it’s something that we would have to remove from our offline mode. Simply removing all of loyalty would throw off both our consumers and cashiers. We decided to insert our sign-up screen, allowing consumers to collect points, but not redeem rewards - satisfying our consumers and cashiers.

Another problem we had to tackle was how we would allow merchants to enable offline mode. Because there was so much risk associated with offline mode, we wanted to be sure that we were communicating the risk involved and limit the possibility of fraud. We explored many options of password and passcode protected settings. After consulting with research we found that there wasn’t enough concern from merchants to warrant building a password system, especially for an MVP. Without a security system, we designed a straightforward system where a cashier or merchant could go to their settings app, click offline mode, then enable it. Once enabled they would be prompted with all the legal risk associated with offline mode. They then could change the daily or total limits of offline mode. 

After knowing the basic flow, and how a merchant would enable offline mode, we needed to think about all the alerts associated with offline mode. One of the big goals when starting our process was to communicate clearly that a cashier was in offline mode. That included designing status indicators for when you were in and out of offline mode, alerts that reminded you that you were offline, and alerts when you were over offline limits. 

Testing

After having the main components for all of offline mode I then began testing flows. I relied on usertesting.com to test my flows and answer a few questions. 

1. Were cashiers aware they were in offline mode?

2. Could they easily complete a transaction?

3. Were they any security concerns?

I ran about 3 tests and tinkered in between, until I felt confident that the designs were solid enough to move forward with. 

The future. 

After working with my PM, design manager, and multiple engineers we go the first draft of offline mode approved. I’m confident that this will continue to move our product forward and help our larger company goal of boosting merchant NPS. We know this is a huge problem, and I believe we built a solid solution for our merchants.