PaySimple Mobile



Experience & interaction design, user research & testing, Sketch Library (UI kit)



Sketch - Wireframes & Design
Great Simple iOS UI Kit - Proof of concept
Craft Plugin (InVision) - Prototyping



Prior to this initiative, the PaySimple iOS and Android apps not only lacked parity with each other but failed bring the necessary features from the web app to the mobile platform. With that in mind, the Product, UX, and Tech team decided it best to begin again from the ground up - a single code base maintained internally.



To start, we had to uncover what our merchants truly needed in a mobile platform. Though we had hypotheses, we knew nothing could replace actually talking with merchants. After enough phone calls with merchants utilizing our legacy apps, we had two primary personas: the Field Service Provider and the Business Owner.

Field Service Provider: An employee of a business that needs to collect a payment for services rendered on site (home repair, massage therapy, lessons/tutoring, etc)

Field Service Provider: An employee of a business that needs to collect a payment for services rendered on site (home repair, massage therapy, lessons/tutoring, etc)

Business Owners: Not necessarily the one collecting payments, but needs a snapshot of his or her business health and incoming revenue on the go.

Business Owners: Not necessarily the one collecting payments, but needs a snapshot of his or her business health and incoming revenue on the go.

Prioritization & Requirements

Building for the Field Service Provider at the outset meant that not only would we be driving PaySimple’s most important metrics, but that of our merchants as well.

We determined our success metrics as:

  • Total monthly processing volume from Mobile 4.0 (new app)

  • Adoption of Mobile 4.0 by legacy app customers

  • Monthly active users who process a payment

We knew that being service providers, our merchants do a lot of repeat business. This meant that in tandem with building out a mobile Point of Sale solution, we had to include a lightweight customer management component. From our preliminary calls we knew that our merchants expected orders and transactions to be tied to the customer profile and concluded that an additional Order History or Reporting tab would not be necessary for the first iteration.

Final Project Requirements:

  • Easy and fast checkout experience

  • Ability to collect custom one-time and recurring payments

  • Access Catalog items (set up on web app) for quicker check out

  • Itemized digital receipts

  • Ability to attach a customer to an order and access saved credit cards & bank accounts

  • Customer Profile with order history, on-file credit cards & bank accounts, and contact information

In addition to the project requirements, the design requirements I set for myself were as follows:

  • Create an app that captures the PaySimple brand and feels like a holistic experience as a partner app to our web app

  • Intuitive, accessible, and easy to use - obvious intentions but something that needs to be included here

  • Self-explanatory

  • Friendly and appealing UI that doesn’t get in the way of our merchants’ goals



When I initially designed our browser based Point of Sale solution, I chose to approach it from the tablet/touch optimized experience. This gave a great starting point to adapt to a smaller screen size. Because the phone dimensions can’t accommodate all the information displayed on a tablet - I mapped out the phone-specific user flow for our two main features. Validating the flow with stakeholders early on was extremely beneficial in saving time during the wireframing stage. Click to expand the images below.



After establishing the project & design requirements, I applied some quick PaySimple brand styles to the Great Simple UI iOS kit and built a prototype using the InVision Craft Plugin in Sketch, screenshots below.

I know, I know, this is the section you want to see some phone pictures of my sketches. While I do appreciate a good away-from-computer sketch session to brainstorm ideas, I’ve found that I can produce a wireframe prototype more quickly with the help of Sketch Libraries & Sketch Runner.

Due to time limitations, I had to validate the concept’s usability internally. I had 10 PaySimple employees perform the following tasks:

  • Complete a recurring order with a saved customer. The customer would like to have their card on file billed on the 15th of each month.

  • Cancel the recurring order

Validating a successfully placed recurring order meant we could be confident about the entirety of the checkout experience.

It ain’t pretty, but it’s testable

Final Design & Dev Handoff

Luckily, the internal testing didn’t uncover any major issues with the initial design. The final step was to update styles across the prototype to better reflect the PaySimple brand. During this phase, I made sure to create a Sketch Library of reusable components to allow faster design for future mobile features. To handoff designs to dev, I uploaded all screens to Zeplin and documented interaction requirements (the initial prototype was really helpful for this as well).


Follow Up

Products are never done. After we launched the app to the public, I utilized UserTesting to re-validate our Point of Sale experience. To make sure the feedback from the UT Panel was applicable, I had each tester answer the following qualifying questions:

  • Are you a business owner that sells services (e.g., offers classes, personal training, massage therapist, home/repair/lawn care, legal, accounting or other professional services, etc.)?

  • Do you currently use or have you evaluated software that lets you accept payments and/or manage invoices and billing (e.g., Square, Shopify, Pay Pal, or other point-of-sale software)?

  • Is taking payments through a phone or tablet app an important part of your business strategy? Or, do you plan on investing in mobile payments in the future?

A panelist had to answer yes to each question to qualify for our usability test. We ran 5 tests for each device: iPhone, iPad, Android Phone, Android Tablet.


  • You just finished a job for Jean Michel Martensson. You need to charge him $325 for today's labor AND bill him $50 on the first of each month for ongoing routine maintenance moving forward.

  • He would like to use his credit card on file for all charges.

  • John Hanson calls you up and asks you to cancel his recurring routine maintenance.

  • Take a few more minutes to explore the app. Please talk through your experience. What is confusing? What do you like? If something didn't work as expected - please describe what you would expect to happen.

This step was incredibly valuable for us as it did uncover usability issues and bugs that existed in production across different devices and OS versions. Thankfully, in the grand scheme of things, nothing glaring came up in testing. We had some keyboard mask and screen size issues slip through our outsourced QA team but otherwise, our order of operations seemed to pass with flying colors. Nothing a few JIRA tickets couldn’t fix. We moved these tickets up in priority to minimize future debt and have a much more usable product because of it.

It does feel great to know that we had interpreted our initial interviews correctly, but a product is never finished!


Next Steps

As mentioned earlier, our initial build satisfied our Field Worker use case. Now, it’s time to start thinking about the on-the-go business owner. As we continue to build out our payment collection features, we will be moving forward with business health & reporting features.