Paystone

At Paystone, I worked on improving the onboarding and management experience for payment terminals — physical devices used across multiple Paystone products, including Payments, Gift & Loyalty, and the upcoming Reputation Management tool.

Onboarding flow allowing for one code to onboard the Paystone products associated with the customer account

Overview

All of their Payments products and Gift & Loyalty products had its own isolated backend, forcing clients with multiple Paystone products to manage separate logins, activation codes, and terminal setups. As Paystone began building Reputation Management, it became clear that introducing a third onboarding system would worsen an already fragmented experience. My goal was to propose and prototype a unified terminal onboarding experience that could scale across all Paystone products and lay the groundwork for a consolidated platform.

Success metrics

Seamless

Can we redefine what onboarding is for Paystone so that setting up your terminals as a new/returning user won't disrupt your current workflow?

Easy for the business owner

Can we create an onboarding flow less complicated than the existing approach and one that is easy for our end-user to be able to follow without assistance?

Problem

To get an understanding on how to tackle this problem, I investigated existing customer research on new client onboarding, as well as other companies involved in point-of-sale and payments.

From our new clients, I discovered the following insights:

Clients often neglected their back office application due to the lack of a compelling reason to access it.

The process of inputting activation codes manually for each product they had was frustrating for clients. A third code would not improve this.

Conducting a competitive analysis, I discovered the following insights:

Competitors managed their terminals on a location basis. Each location had their own roster of terminals associated with the business.

Competitors used their products back office to generate setup codes for each terminal.

3 key decisions

Manage terminals on a location-by-location basis

To push this into something realistic to launch, I refined the scope to create a vision for the MVP, a release that could be iterated on and expanded. With my capabilities in web dev being limited, I didn’t want to push too far in what could be done with this kind of a platform. The core functionality would strictly be single game stat tracking

One code for our customers to use

With the core functionality set, I sought out to learn Javascript, and then React, to simplify the development of this platform

Testing

To keep up with the speed and pace of a real game, I would need to test this beyond a sanitized testing environment. When the coded prototype was ready, I would test it at a real pick up game.

Process

My research had me look at the current onboarding flows for our terminals. The existing onboarding flow for the user was disconnected from their back office account. The idea behind this direction was to allow them to set up their terminals as quickly as possible, and was partly due to the fractured nature of their two product offerings. Currently, products were activated were through separate long activation keys the user had to punch in manually for each product they paid for. Existing user research showed that this process was arduous and frustrating, which led us to believe that adding in a third long activation code would be unlikely to improve the process.

The previous flow chart for terminal onboarding.

Current state flow diagram

With the goal of the product being one hub for all of the users products, the goal was to think of a way to manage terminals that would interact with all three product offerings. This hub would have to account for the locations the users business had, and how many terminals per location would be active. To get an understanding on how to tackle this problem, I investigated other companies involved in point-of-sale and payments. This led me to the new and revised flow based on how our competitors operated.

My revised flowchart for terminal onboarding.

Propose flow diagram

Collecting my research and mapped out user flows, I presented my findings to both the development and product teams at Paystone. After highlighting the reduction in future efforts beyond the MVP, the product team was on board and we meet with the developers. While they appreciated the simplicity of the solution, the current architecture for the terminals was more complex than we initially anticipated. While the solution to integrate all services under one code was feasible, it would delay our initial release and would have to be done in a different sprint cycle. However, they were able to set up the framework for this solution in the interim by adopting a method similar to Googles OAuth token system.

Leanings

This exploration was a lesson in working with an agile team. Release times are the biggest priority and certain features/developments need to accomodate for that. While we weren't ready to ship the feature for the trial run with the MVP, we were able to put into place the conditions necessary to develop it down the road.

Designing connectivity between payment terminals and back-office applications.