Order point-of-sale devices online
B2B Web design, E-commerce, FinTech
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.
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.
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.
After refining the requirements, I created a prototype using Figma, developed a usability testing plan, then used UserZoom to conduct an unmoderated usability test.
Participants:
16 SMB customers
Key Measurements:
Task success and qualitative feedback
Research Objectives:
Success Criteria:
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.
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:
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.
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:
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.
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: make all selections on one page.
Question: Is it clear that the user can mix and match connection types?
Option 2: make all selections in the cart page.
Question: Is it too jarring for the user to land directly in the cart?
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.
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.
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:
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
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.
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.
If you like what you see and want to work together, get in touch!