Overview

QuestPayments is a major service provider of credit card readers (EFTpos) primarily used for payments, particularly in the retail sector across all of Australia. Their technology enables businesses to accept cashless payments.

Quest engaged me to validate a proof of concept for a business product they envisioned and requested a report on potential improvements. Given their strong presence in the market with branded physical devices (EFTpos machines), they aimed to expand their business by offering software solutions for split payments in the retail sector. The project had a timeline of six weeks.

Problem Statement

The primary objective of this project was to enhance the proof of concept to determine whether further investment was warranted. The product aimed to facilitate a seamless checkout experience in which diners at the same table could either split bills or pay directly for their ordered items. The problem Quest sought to address was the inconvenience faced by diners in most restaurants, as they did not support split payments. This often led to someone having to pay for the entire table bill, causing financial inconvenience.

Users & Audience

The proto persona identified by Quest was a student, co-worker, companion, or friend dining at the same table in a restaurant. The inspiration for this concept stemmed from the daily lunchtime question faced by Quest staff: "Whose turn is it to pay the bill today?" Recognizing that this issue was not unique to their group, they envisioned a solution for a broader audience.

Roles & Responsibilities

The project team consisted of myself as the UX designer, a Product Manager, and a full-stack developer. My responsibilities included devising UX improvements, designing the UI, conducting a quantitative survey, recruiting internal participants, and scheduling lab testing sessions. A final report was to be produced at the conclusion of the 6-week project. To ensure effective collaboration, I held daily stand-up meetings with the Product Manager and conducted early sessions with the full-stack developer to address front-end and back-end changes. Given the internal nature of the project, we aimed to keep iterations to a minimum.

Scope & Constraints

The project's scope encompassed taking an existing proof of concept developed by the team, enhancing its user experience, designing an appealing UI, and conducting lab tests with 30 internal participants to identify usability issues. The budget was constrained, permitting only internal lab testing. Unfortunately, there was no budget for a discovery phase to validate product features or address additional pain points. Additionally, the product was largely built in Bootstrap. While the project aimed to improve the user experience, it did not include validation for product-market fit.

Process

As a contractor, I dedicated time to thoroughly understand the project's business goals and objectives to ensure the six-week deadline could be met. This involved gaining insight into the problem the product aimed to solve, understanding its future vision, and considering technical constraints that informed the proof of concept.

To gain deeper insights, I engaged in ethnographic research by joining the team for lunch, allowing me to observe dynamics and pain points. Early on, I raised technical questions regarding the development approach. For example, one assumption was that diners could access the bill using a QR code on the table. However, quantitative research involving 50 internal participants revealed that QR code adoption in 2017 was not widespread. This raised concerns about the user experience, as diners unfamiliar with QR codes might struggle to access the bill, potentially leading to unresolved payments and social discomfort.

After gaining a comprehensive understanding of the business proposition and product, I conducted desk research to identify best practices and competitors in the checkout experience domain. The tool of choice for designing the UI and creating early mockups was Sketch. Usability tests with the Product Manager and developer helped fine-tune button placement and color contrast.

Addressing the challenge of conveying who was responsible for each part of the bill in a group payment scenario, I opted for a gamification approach, using food avatars reminiscent of Google's document sharing icons. This model, validated by a well-known company, offered the potential to enhance user satisfaction. To reduce confusion, distinct and easily identifiable fruits were chosen as avatars.

Once the UI was approved by the Product Manager, I collaborated closely with the developer to swiftly implement necessary code changes. Simultaneously, I recruited internal staff for a proposed lab test, simulating a restaurant environment within the office complex. The invitation was sent with sufficient notice, setting expectations for the exercise without delving into overly detailed explanations. This approach aimed to validate the assumption that using a QR code to access the bill was the most effective strategy.

I conducted five tests, each with four participants, in a relaxed atmosphere where I explained the pretend exercise with no right or wrong approaches. Following the exercise, a survey was distributed to gather feedback on the exercise and the overall user experience in a confidential manner. All findings were incorporated into the report delivered to the business.

Outcomes & Lessons Learned

The project delivered as expected, providing quantitative survey results ahead of the lab test, UI files for the product, a comprehensive report of lab test observations, and an analysis of post-test feedback surveys.

I conveyed to the business that, at that time, technical limitations could impede adoption. I recommended a heavier investment in a discovery phase, involving discussions with restaurants and customers fitting the target persona to gauge the extent of the pain point and brainstorm alternative solutions.

The project taught me the importance of recording lab sessions and having an observer present, as detailed note-taking proved challenging, especially when multiple participants experienced a digital solution for the first time. To facilitate identification and observation of participants, I would have provided name tags in hindsight.

In terms of design thinking, I learned that multiple iterations and diverse design solutions should be considered during the ideation phase. The project's focus on validating a single assumption over six weeks proved costly. In hindsight, I would have advocated for a discovery and ideation phase before embarking