Quick read

Problem

The future goal of Paystone was to have all of their products under one platform, each of which use payment terminals. Their current system for managing their terminals were fragmented, and they planned to create a new fragment while developing Reputation Management, creating user frustration.

Process

By reviewing customer/user data, and examining industry standards, I was able to pitch to product and dev teams a streamlined way to manage terminals on a location-by-location basis, rather than the current free-for-all structure, and reflect a smoother onboarding expereince on the terminal itself.

Delivery

By working with the dev team, I was able to configure my prototype to work within the technical requirements of the platform. This created a smoother onboarding experience for customers with multiple Paystone products active.

Overview

Paystone was working on a new product to add to their roster outside of Payments and Gift/Loyalty: Reputation Management. This product would have the user assess their customer service before going to leave a review and allowing the business to attempt to mitigate any negative experiences. This interaction would begin on a payment terminal.

Payments and Gift/Loyalty were products that lived independently of one another. They both had separate back offices which meant if one client had both products, they had to manage them separately. This also included managing payment terminals separately. One of the goals for the Reputation Management product was to combine all three products into a singular back office platform. As we built out the product, we had to account for the integration of two other systems.

While reviewing user stories for upcoming sprints, I noticed that the plan was to build a new instance of terminal management for the product. Recognizing that this could create duplicated efforts when adding in the other two products, I took a look to see if there were ways we could simplify this process.

Research

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.

With the goal of the product being one hub for all of the users products,  we needed 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.

Flow mapping

With the solution set from my user research and competitive analysis, I brainstormed new ways that our users can add terminals. I began to rethink the user journey, where it should start, and how to manage it from two different devices. Below is the flow that I landed on:

Buy-in

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.

Prototypes

Below are the prototypes for the terminal product. The first set are for the Interim solution, the one that would go out with our MVP. The next set are for the Ideal state, the one we would build towards.

Interim solution

Ideal solution

Handoff

To ensure smooth communication with the development team, I created handoff documents for them to access while building the terminals. The Terminals team weren’t used to using the Abstract Tool that the Surveys team were, so I made sure all the information was available to them in these PDFs attached to each JIRA ticket for their access.

Conclusions

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.