• Home
  • More Projects
  • About
  • Contact
  • Mobile Payments Application

    Overview

    Mobile Payment

    When Elo Touch Solutions wanted a payment application to demonstrate capabilities of the contracted mobile point-of-sale solution, to be installed on their custom hardware, Omni Integration subcontracted me to design an interface for the out-of-the-box functionality. I was tasked with ensuring that the UI held up to shipped application standards, while facilitating intended usage in both demonstrating payment process capabilities and in-house case testing.

    Project Goal

    Design a multi-faceted mobile payment processing application UI that effectively demonstrates software solution capabilities.

    Duration

    Jan 2020 — May 2020

    My Roles

    User research
    UX design
    Interface design & production
    Developer support
    Project management

    Uncovering User Needs

    I first started by learning more about similar mobile-based payment applications to understand common use cases and popular usability complaints. Due to the types of apps examined, most vocalized issues had to do with efficiency and mis-taps resulting in transaction processing hiccups.

    After tagging and categorization, several specific findings were:

    1. Tip presence and amounts should be configurable for smooth customization to the user’s business..Tip presence and amounts should be configurable for smooth customization to the user’s business.
    2. Having most recently-used payment method pre-filled will likely save time in the long run, but could potentially lead to the seller forgetting about it and mis-categorizing a transaction.
    3. Additional charges such as taxes and other fees are important information to businesses and can help validate final price to customers in some instances. Should be included on initial payment summary as well as receipt.
    Usage Flows

    The research was also used to base expected process flows and user goals, in conjunction with technical use cases previously written by the mobile development lead.

    Initial Design

    With all of this information, specific experience-focused UI requirements were drawn alongside the technical ones as a basis for the initial wireframe. The specific requirements of the interface were deduced from the technical documentation, which was a significant opportunity to practice self-sufficiency and technical fluency.

    These included pre-filled selections, other various shortcuts, and visual aids for payment entry.

    1st Draft

    The first draft included a log-in flow, update flow, dashboard, purchase/refund flow, item lookup, transaction history, and application-level settings. Secondary ‘experience’ requirements included pre-filled selections, other various shortcuts, and visual aids for payment entry.

    Prototype Design & Iteration

    Over several weeks, we began to refine the application interface design. We explored several different UI options for various parts of the app, with routine usability evaluation helping to ensure that every feature and interaction remained satisfactorily efficient and clear.

    Usage Flows

    After the 3rd review session, I was made aware that the eventual application would be utilized in B2B sales, which resulted in additional research into relevant use cases. Several options were explored in order to facilitate the sales process, including contextual screenshot functionality and persistent navigation options, but were ultimately abandoned in favor of simplicity.

    2nd Draft

    A draft from midway through this period illustrates just how much we pared the original application design down, allowing for a complete transformation into a significantly more streamlined UI.

    Production & Development

    3rd Draft

    After several weeks of iterative changes, we finished designing the UI of the final demo payment application. The final design was intended for use in both B2B sales, software testing, and shipping to customers as a default interface for the combined software/hardware solution. The UI, as a result, had to facilitate use in demonstrative, QA, and real-world environments.

    Several ways in which we attempted to integrate this expected usage into the interface:

    Usage 1
    Usage 2
    Usage 3
    Usage 4
    Usage 5
    Fun spinner

    Development took place over the course of about 6 weeks, with regular scrum meetings providing opportunities for regular review and feedback. My responsibilities consisted of providing specifications through Adobe Xd, general assets through Adobe Xd and image exports, special assets such as the processing spinner, and notes containing information regarding screen flows, microinteractions, and otherwise concerning potentially unclear intended behavior. I was also on-call to provide input and answer questions throughout the process.

    Result & Takeaways

    The final payment application fulfilled all of it’s requirements, and is currently being prepared to be loaded onto the custom hardware for use in B2B sales and testing.

    The project provided me with further opportunity to work in a fast-paced agile environment, with rapid iterations on the design helping to generate and refine several potential directions for the application.

    As an independent contractor and the only member of either team experienced in UX/UI design, I also had the opportunity to work from purely technical information in an unfamiliar field, and to practice self-managing and scoping work in highly variable conditions.