Point of Sale Web App for Customizable Products

Prototypea hybrid web app/pos system containing the business logic to eliminate manual sale processing time, reducing work from 3 months to real-time.


Business Problem

Big Picture

Interviewing Stakeholders & SMEs

Technical Questions

Sketching the Flow

Testing with Admin Users

Figma Wireframes

Figma Prototype

Designing for Failure


Discovering the Need

Understanding the idea

Business Problem

My client takes orders on several thousand customized products based on qualification data stored in a database only accessible back at the office. They spend months checking files to validate the buyer eligability and then placing orders from the manufacturer.

My goal was to turn this this into a normal sales experience for.

Big Picture

Business Context

During informal interviews with various stakeholders, many UX and process issues made themseves apparent. This particular opportunity emerged while speaking with the Director of Marketing.

The company hosts 2 conferences a year where they sell a variety of customized products to qualifying individuals. Their biggest conference attracts upwards of 15,000 people, and all sales processing is done manually.

Because of limitations with their database it was impossible to determine a buyer’s eligibility and order the products in real time. In fact, it took 2 employees 3 months of manual paper processing and database querying to complete this.

Goals & Challenges

WIth their team, I would design a system which presented buyers the products only for which they were eligable. Automatinc the paperworkd to “on-site, real-time”

Then, I would assemble all the information and specifications for a development team to quote.

We had 3 months produce a working product. 


As the UX Consultant, I worked with 2 client-side subject matter experts and the Director of Marketing for user and business process insights.

I worked with internal IT to gain understanding on how data was accessed, stored, and delivered.

I also worked with a 3rd party development team to clarify questions and prepare documentation to produce a quote.

Interviewing Stakeholders & SMEs

My first interview was with the Director of Marketing. The problem was expensive and he’d thought about it for some time. We covered the following in our initial interview

  • what were our opportunities for digitization here?
  • how was this web app going to solve the expensive problems?
  • how do we see this web app integrating with the sales process?

In addition to:

  • how do the staff presently tend to buyers?
  • who are the buyers?
  • what are some insights and challenges which shaped the current process?
  • what are some problems with the current process?
  • how does staff process the orders after the conference?

From this meeting, we outlined how a buyer might go through the process of buying a plaque.

The Director and I walked through this a number of times until all high-level concerns were incorporated.

From this, I listed several questions we were going to need answered as well. For instance:

  • Who are the users?
    • What about user translations and keyboards?
    • How will users input their addresses in a foreign language? How can we verify these addresses?
  • What devices would they actually use?
  • How would we be getting the user-device to communicate order information to the Clover device, and back to the user-device?
  • Which Clover devices can scan UPC or QR codes?
    • Are there QR versions we need to consider? How does the information need to be formatted for the POS to properly record the data?

Technical Questions

This kicked-off numerous questions about the business logic of the app. For example, For instance:

  • What processes currently approve users for purchases?
  • What exactly are they verifying and how?
  • What information from the database would be needed to process orders?
    • What data are they accessing
    • What is the db schema for plaques, members, and orders?
    • What member tables do we need to include?
  • What is all the validation logic?

I wanted to have these answered and the assets in hand to make sure we looked at each major moving part of development to reduce uncertainties.

Sketching the Flow

While continuing to discover more details about the workflow, I sketched out the screens and general UI elements that seemed necessary on sheets of paper.

To inform the core structure, I referred to:

Requirements for validating users
Commonly seen eCommerce and checkout processes


Testing with Experts

Afterward, I walked through the full process with the subject matter experts (SME), continuing to make notes, modify elements, and rearrange screens.

We changed the flow 2-3 times thanks to the challenges the SME presented with a decade of experience.

Validating Member Identity:

  • Challenge 1: We would need to allow users to address name and designation changes (due to marriage and training) for different plaque years. I’ll outline challenge 1 in the next section below.
  • Challenge 2: How would we validate member identity? I kept this in mind when proceeding, I didn’t want the automating aspects of the software to obviate the security value of human appraisal. So for the final interaction with the cashier, I incorporated critical information to be used for the purpose of noticing potential identity issues.

The final few steps pertaining to checkout were not yet complete at this point. Would we be using the website to process payments? Would we need to communicate with a Clover device? Accounting had not yet decided which route to take, so I described a few possible alternatives from a high-level to begin identifying uncertainties.


New Insight & Restructuring the Flow

Below on the right are the appx 13 steps taken through the purchase flow. On the Left is an image of step number 4. Step number 4 is when the user edited their name and designations as they should appear on the plaque. I hadn’t foreseen the issue caused by introducing this step so early.

  1. Language Selection
  2. Enter ID Number
  3. Confirm Identity
  4. [ Customize Name & Designation ]
  5. Browse Product Catalog
  6. View & Add Products to Cart
  7. View Cart
  8. Approve Terms
  9. Enter Shipping Details
  10. Confirm Shipping Details
  11. Cashier Handoff
  12. Cashier Confirmation
  13. Scan & Charge Purchase

What happened when users wanted to buy a plaque for a previous year but had a name change or added credentials to their name?

The SME realized we might be able to move that entire section later in the process, as a user adds the plaque to their cart. This can be seen applied in the video to the right.

  1. Language Selection
  2. Enter ID Number
  3. Confirm Identity
  4. Browse Product Catalog
  5. View & Add Products to Cart
  6. [ Customize Name & Designation ]
  7. View Cart
  8. Approve Terms
  9. Enter Shipping Details
  10. Confirm Shipping Details
  11. Cashier Handoff
  12. Cashier Confirmation
  13. Scan & Charge Purchase

Figma Wirefames

When the flow and UI appeared largely to have stabilized, I wireframed the results in Figma. I paid particular attention to making sure all necessary elements and critical flows were represented.

We walked through this twice. As the pages began to take a more definite shape, we began incorporating greater flexibility for edge cases. Challenges and questions were identified and addressed for the web app’s RFP.

Some details to ask questions about

There were 4 product page templates which would render depending on the type of plaque being chosen. This information was included in a spreadsheet.

Why do users need to edit names on plaques?

Global Audience – names are often translated, rearranged, or nicknames are added.
Married – names may change through marriage.

Figma Prototype

After the wireframes were made and carefully reviewed, I connected all the elements and turned it into a prototype. I then walked through this prototype with the SMEs 2-3 times over the course of a few days, allowing for both active and passive thinking.

A few more modifications were made as additional considerations came up.

For instance, the app needed to provide clear language switching options without resetting form data. If a Korean user got stuck on a screen, an English speaking user would need to see where in the process the user was.

Designing for failure –

What would happen when users got frustrated and with the web app?
What happens when a cashier spotted unusual names on ordered plaques?*¹
*¹ This was actually a somewhat normal risk. Folks with higher membership tiers would purchase plaques for their friends and change the names on the plaques – changing names was part of the customization process.

To address this, the person’s name from the client’s database (source of truth), and the name on the plaques were both provided to the cashier during checkout.


I outlined all the steps of the process in a document, included animated gifs, and handed off all the technical details regarding databases and outputs.

Here are some examples of the prototype as included in the specifications document.