Ticket vending for merchants

Project Overview

• Timeframe: 3 months
• Team size: 4
• Role: UX Researcher, UX/UI Designer
• Target user: Merchants, cashiers, vendors
• Platform: Android tablet
• Tools used: Sketch, InVision

While at Intific I created designs for applications in the transportation sector. For this project, I created a tablet-based application that enables vendors to sell transit tickets to customers using smart-card technology. What made this project both complicated and interesting was the sheer number of unknowns involved. I was designing for multiple clients (transportation agencies within different cities, globally), different ways that different cities determine ticket price, and different kinds of transit systems. Beyond the infrastructural constraints, I had to account for whether a specific client wanted to allow its users to create accounts, and that merchants would not be able to cancel transactions once value was deposited onto a card.

I worked with a mobile developer, project manager, and quality assurance analyst in an agile environment. Ultimately, I went through multiple iterations and created countless wireframes. I was able to perform contextual inquiry with users, and validate my design with users in San Francisco, which is one of the most complicated and oft-complained about transit systems in the US. After receiving the go-ahead from all stakeholders, I worked on incorporating Material Design for the UI.

Please note, below is only a small cross-section from a larger app.

THE EVOLUTION

The checkout page was the most complicated and most important screen for a user. Users frequently cited pain-points including miskeyed ticket options and difficulty finding the correct transit operator. The photo below is a prime example of the VeriFone UI and lack of information that it displayed. The value listed is for a transit ticket, however this is not clearly presented to the user; this frustrated users and lead them to periodically selling customers the wrong product.

The VeriFone design did not account for how real-world customers phrase their needs. I eased the burden on the user by creating a design that displays a large amount of information in an easily digestible format. This allowed users to rapidly parse options and quickly move through transactions.

On top of the VeriFone system burdening users, the ticketing system also had a number of pitfalls at the user’s expense. It was not able to process cancellations in an easy or fast way. Employees may be penalized for selling the wrong ticket or putting the wrong value on a customer's card. I created a UI that could be quickly navigated but still  helped users enter accurate information, while allowing easy edits throughout.  

Throughout the project I juggled business rules, unknowns, and user needs; I found ways to efficiently convey necessary information and prevented users from miskeying, or making errors. The wireframe allowed me to understand how to represent the necessary information and a possible way of laying it out. By exploring and learning about Material Design I was able to make the design both aesthetically desirable and simple, ultimately pleasing the user.

Material Design

I made the decision to explore Material Design because I wanted to:

• Create interactions that users expect and understand
  • Our users were split between iOS and Android; I wanted to take advantage of this and utilize code libraries that already exist so that users would be presented with a consistent framework that they've already been exposed to. Although the hardware was not set I knew it would be an Android based device. Considering most users have encountered Android in some form, why reinvent the wheel? This eased training burden and curbed possible learning gaps.
• Present a pleasing look and feel
  • Users previously had to run transactions on VeriFone devices that are so old they are no longer being manufactured. However, the VeriFone UI is brutally simple. I did not want to sacrifice simplicity for a pleasing design so I gave them both. This delighted users.
• Elevate a simple and easy to understand layout
  • I did not sacrifice functionality in this design. Users can now see all of a customer's information in one place as well as everything that they've added to their cart. The ease of use of this layout prevents users from miskeying and making costly errors, as the system is not able to cancel transactions.
  • The app can pull niche information from an API. My design accounts for this and presents that information in relevant areas. For example, the confirmation page explicitly tells users when a pass will expire, this is valuable because it lets users know what the timeframe of the ticket is that they are selling. Although this may seem minor it has a heavy impact on users. It alleviates customer confusion and complaints regarding how and when to use their purchase.
• Ease the burden on the developer
  • My wireframe incorporated many unique elements. While the developer would be able to create complicated and new interactions for me, I wanted to create something more efficient for all parties involved.

CLICK TO EXPAND

CLICK TO EXPAND

CTAs + THE USER'S LANGUAGE

The Calls To Action were a complicated sticking point between the stakeholders, team, and myself. I advocated for straightforward wording so users would understand what each button meant. Stakeholders wanted to avoid using monetary and value-related language. The stakeholders did not support my design's use of the following words:

• pay
• buy
• sell
• ticket

The issue the stakeholders had with these words related to the nature of the app: money is not being transferred through the app itself and stakeholders worried about implying monetary responsibility. However, I advocated for these words because they most closely track with user understanding and expectations.

FEATURED IN

My designs are featured in this Cubic video, showing how our transit applications can serve riders, merchants, and transit inspectors.

UnderstandING our users

In order to get the team aligned on whom this design serves and what their most pressing needs are, I created user archetypes. While this is not an in-depth look at each user group, it covers the most relevant factors that drive them.

Key takeaways:

• The system must allow them to recover from their mistakes; our users want to avoid costly and uncomfortable customer interactions.
• The system must be robust enough to keep up with tech-savvy users and customers who are used to instantaneous interactions.
• The system must be simple as not all users are technology-literate, they cannot afford to expend extra energy learning a confusing workflow.

USER ARCHETYPES