top of page

Mobile Payment App [2017-18]


A client approached my team with a need to redesign their mobile payment app. Their live app was designed few years ago and needed to support new technologies, fix usability issues and an overall stylistic update.


The goal of this project is to create a phone-based mPOS (mobile Point of Sale) app that can be used either as a stand-alone POS app, or as a companion to the web-based platform for line busting or pay-at-the-table scenarios. The target audience for the stand-alone app are retail or café (no kitchen printer needed).  We were responsible for designing the user flow, giving the app a contemporary look and feel, focusing on usability (the goal being no training necessary), and accounting for different device and payment types.


1. Review and prioritize requirements

Because this was a project for a client, we were given an extensive list of requirements. Using a tool called 'Airtable', our team organized the requirements and worked with the client to assign priority to them

2. Ideation

Once our initial questions were answered and we had an organized list of requirements we began to work on a high-level flow for the app and sketched out ideas for screens based on that.

3. Wireframes

We met with the client each week and used low-fidelity wireframes to test out concepts and elicit feedback. These types of wireframes helped to spark discussion and we discovered features that were left out of the initial requirements along the way such as:​ a need for variable-priced items and a demo mode for prospective customers​.  Using a tool like Airtable (this was the first time we tried it) allowed us to keep track of these evolving requirements and ensure that everyone was on the same page.

In addition to requirements and continued discovery, these wireframes invited people to discuss the overall flow of the app. I think seeing the screens helped the client see the flow we were describing and helped us learn more about user needs. For example, we learned that a 'Quick Add' screen was more helpful as a home screen so users could quickly start transactions, and that users need to be able to skip the cart and go directly to payment. Because we stayed in low-fidelity, we were able to iterate and easily incorporated these types of learnings into our design.

As concepts were discussed our designs and flows became more concrete allowing us to explore new areas of the app, like transaction history and the catalog of items. We always kept a goal of simplicity in mind with the idea being that someone could start using the app within minutes of downloading it with little to no onboarding necessary.

4. Visual Styles

We began to layer on visual styles as concepts were accepted and agreed upon. Fonts and color palettes were chosen and we tried to reuse components and create a consistent style throughout the app. We went through a few iterations, ultimately landing on a minimal use of colors for two reasons: so that actions were clear and distinct and because companies that adopted this app would have the opportunity to brand it.

Here are some screens from the app:

Point of Sale (no items)

We made this Point of Sale screen the default screen when entering the app, incorporating the feedback we received.

Because a transaction is started when an item is added to the cart the page title changes and a cancel option is provided.

Throughout the app, we kept main actions to the bottom of the screen. Here, we were able to reuse that space for the order information and access to either the cart or the 'Pay' screen.

We used a split button design to allow users to easily skip the cart, a requirement that came out discussion

Point of Sale (with items)

When a user has items in their catalog, they will see a different POS screen.


'Quick Entry' allows them to enter a price with a description and reuses the flow seen above.


We iterated on ways to display the amount of an item that was added and how to decrement that amount. We landed on a plus and minus icon as well as a badge above the item image.

The cart allows users to review their order and remove items from the cart entirely. Additionally, tapping on the number next to the item opens a quantity pop-up to add a custom amount easily.


We had a lot of fun designing the payment flow. We included a strong visual indication that users could pay by card or devices right away, while still having the options to manually enter a card number, and pay by cash or check. The 'Sign' screen has a few different states, with the one above combining tipping and signing together. This is the one part of the flow the customer sees and it offers and friendly, clean interface with the main emphasis on signing. When the sale is completed, users have the option to text or email the receipt to the customer, view the receipt or quickly begin a new transaction by clicking 'Done'. 

Transaction History

Transaction History is a collection off all past payments. We needed to include states for offline payments and refunds as well as provide information about the transaction so it would be easy for someone to find it. We used color and visual indicators to to this.

The refund was easy to design when we started to think about it as a transaction itself. We reused components such as the item list and pay screen while giving the user enough context to know what they're doing.

Challenges and Next Steps

This was the first payment app I worked on which offered some challenges. I had to learn certain lingo and ask a lot of questions to gauge what was important to merchants. I think having the weekly client meetings helped the design move along faster. We were able to get quick feedback and learn about requirements early on. This was important as we needed to meet a short deadline. We also were able to talk through decisions that we made and why, in certain situations, we veered away from ways that it was done in a competitor product.  It was also the first time in a while that I used Axure, which is very powerful for prototyping but different to use than Sketch.

The next steps are to work with developers as this gets built. We also need to gather requirements and help with user research for the upgraded version of this app which will be offered based on the adoption of this lite version.

bottom of page