Add Product Services

Order point-of-sale devices online

B2B Web design, E-commerce, FinTech

Case Study

Project Overview
The Problem:
Currently, the only way to order a point-of-sale device from Elavon is to call a sales representative. To stay competitive in today’s market, Elavon needs to provide a way for customers to order what they need without speaking to a sales representative.

The Solution:
Design an e-commerce experience that allows users to order point-of-sale devices for their business.

The Results:
This is a net-new experience and has not yet been released to production.
My Contributions
My Role:
  • Executed end-to-end UX design process
  • Worked closely with Product Manager to define requirements
  • Worked closely with software developers to ensure designs implemented accurately
  • Defined user journey and task flows
  • Performed competitor analysis
  • Designed wireframes, mid-fidelity, and high fidelity mockups
  • Conducted user research using UserZoom
Product screenshots
This is a net-new experience, so the minimum viable product (MVP) version of the project focuses on the ability to purchase 2 point-of-sale devices, Moby/5500 and talech Terminal. The entry-point for this experience is an existing marketplace within an Elavon account management portal.

The long-term vision for the Add Product Services project is to design and build an e-commerce experience that allows Elavon’s customers to shop for hardware, software, and other services via a marketplace that is product agnostic.

Background

Users and their journey

Users

People using this experience are current Elavon customers who own a small to medium-sized business (SMB).

They need to purchase a point-of-sale (POS) device to take in-person payments for their business.

A smaller subset of these users also need to upgrade their outdate POS device to a new smart device, the talech Terminal.

Journey & tasks

Using personas developed by the research team, I defined the user’s journey and tasks they would need to complete in order to successfully order a POS device.

Image describing user's journey through the product.
Journey map
Task: Navigate to marketplace
Task: Add to cart

Designing while defining

Initially, requirements for this project were unclear, so I put together screens from other projects to start defining a potential flow. We new were starting with the Moby/5500 card reader & talech Terminal, but weren't sure how the user would pay for the device, what branding we would be using, or if other products would be included in the MVP release, etc.

This exercise helped me to collaborate with my Product Manager to further define requirements and uncover questions and gaps.

Initial entry-point wireframes

Is it usable?

Unmoderated usability testing

After refining the requirements, I created a prototype using Figma, developed a usability testing plan, then used UserZoom to conduct an unmoderated usability test.

Methodology

Participants: 
16 SMB customers

Key Measurements:
Task success and qualitative feedback

Research Objectives: 

Success Criteria:

Results

Wins

Pain points

Final designs

Implementation

I iterated based off of the usability testing results and ran the flows through a few team design critiques. I worked with my development team to annotate the designs as needed to ensure accurate implementation.

Note: See links below the final flows for Figma prototypes.

Final entry-point

After the final designs

New requirements

After completing the UX design for the talech Terminal flow, some new requirements from the business came in that resulted in a redesign of the initial talech Terminal flow.

New requirements: 

  • The product is now a bundle - hardware & software
  • There are 2 connection types the user will need to choose from (connection types have different pricing)
  • If the user is renting more than 1 bundle they can mix & match connection types
  • The user can order a maximum of 5 devices (per order)

Can we repurpose anything?

Based on the new requirements, my first step was determining how to incorporate the connection type selection.

The product page already had a quantity selector, but adding another decision to that box would add too much complexity to an already complex and text heavy page.

I also looked at the landing page I had designed for the initial talech Terminal flow to see if the quantity/connection type decision could be added, but again determined that it would probably increase the cognitive load of the page too much.

Product page selections box
Landing page hero banner

What are competitors doing?

To get a better idea of how competitors might approach this problem I looked at Toast, Stripe, and Square. I also reviewed Home Depot and Nordstrom as indirect competitors/inspiration.

They were all pretty different and none seemed to have a similar connection type selection problem that I did, but I was able to identify some key findings.

Key findings:

  • Price/total clearly displayed
  • Order summary clearly displayed
  • Description or overview of device/items included

Redesign: Getting started

Initial UI explorations

Based on my findings from the competitor review, I began exploring potential design solutions.

I created a prototype that displays these explorations in detail with annotations and reasons why I didn't pursue specific designs.

Initial explorations prototype
Initial exploration of the product page

Further iterations & usability testing

After my initial explorations, I designed 2 quite different solutions. The designs were so different and the open questions were big enough that I decided I needed to conduct some user research.

I created a research plan and ran an unmoderated usability test in UserZoom with 15 participants. The goal of the usability test was to determine which design, option 1 or 2, resonated more with users.

Results: 
Option 2 was clearest, with 93% of users rating it “very clear”. However, 60% of users still rated option 1 as “very clear”.

Option 1

Option 1: make all selections on one page.

Question: Is it clear that the user can mix and match connection types?

Option 1 prototype
Option 2

Option 2: make all selections in the cart page.

Question: Is it too jarring for the user to land directly in the cart? 

Option 2 prototype

Fine-tuning the design

Based on the research findings, I began fine-tuning the “Option 2” design, where the user makes their quantity and connection type selection directly in their cart. However, a new problem arose during this process: How to communicate the maximum of 5 devices per order?

I designed 2 different potential solutions to this problem: Display a warning messages or error message when the user enters a quantity >5 or use drop-down selectors that would change available inputs based on the quantity.

Warning message
Dynamic selectors

Based on feedback from a design crit that the dynamic selectors would be good for preventing errors but would make errors difficult to recover from I went with the warning/error messages approach.

Additionally, it would have taken my software engineers more time than we had to develop the dynamic selectors.

Fine-tuning selections prototype

New new requirements

Due to complexities configuring the connection types on the backend, we were made aware that we needed to change the design again.

New new requirements:

New final design

Based on these new requirements, and very limited amount of time given to the software engineers to implement the design, I removed the cart page from the flow entirely.

Final design prototype

Partial view of the final design

What's next & reflection

What's Next

After the MVP release, the plan is to begin discovery to help inform how to position software offers in the marketplace in a way that customers will understand.

Reflection

This was a project with a quick turnaround time and was the first project I worked on at Elavon, so there was a steep learning curve.

I had interesting constraints to work with, such as, the entry point in the account management software. The various constraints proved to be a good opportunity to solve some complicated problems. The team also lost our Product Manager in the middle of the project, so it was a great opportunity to heavily collaborate with the Product Owner and Software Developers to make sure we were building what we should when we should.

With the new requirements I was able to advocate to get a 2 week design sprint before the developers needed to start on the implementation, so I had to iterate and test very quickly. To help avoid last minute changes in requirements, our team learned that we need to more proactively communicate what we’re planning to implement with the backend team we have dependencies on.

Want to work together?

If you like what you see and want to work together, get in touch!