Creating Inclusive Self-Checkout Terminals:
A Design Process
This was a design challenge I participated in previously. It’s a fictional project created to illustrate part of my personal design process. I had just 48 hours to provide a solution. Below, you can see what I delivered for this project.
Project background
A supermarket is planning to use self-checkout terminals to speed up the payment process for customers with less than 15 items. Each terminal is equipped with a barcode reader, a touch screen monitor, a weighing scale and a PIN pad that accepts debit and credit cards.
The Information Architect already defined a UX design process with the following methods and deliverables:
-
User Interview
-
Personas
-
Low Fidelity Mockup
-
High Fidelity Wireframes
Note: For this test, consider that you have unlimited time and resources to develop this project.
Task 1 - Do you agree with the chosen UX design process?
My answer: Firstly, a design process should be iterative. Digital products are rarely ever “finished” because of the constantly evolving factors and trends that necessitate ongoing improvements and new requirements. In this case, the most critical omission is the lack of validation and testing steps, which is risky since we are developing something new. Additionally, there’s no mention of scope planning, which is crucial for defining a project strategy and establishing an MVP. I would also advocate for working sessions and follow-ups with key stakeholders. Therefore, I believe a more comprehensive approach would include:

In the discovery process, we would focus on identifying our users' pain points and needs, and analyze how other companies are currently addressing similar challenges (benchmark research).
For scope definition, we would bring our findings to the business and development teams to build a strategy. Although this step is more business-oriented, I would involve a member of the UX team to represent the user’s perspective and ensure a balance between business and user needs. During this phase, we would also define the team’s strategy and our deliverables.
In the design phase, we would base our work on the strategy developed in the previous step. For this project, let's assume we start with low-fidelity designs. Once these designs are approved internally by stakeholders, we would proceed with user testing. Based on the feedback, the design process cycle would restart, incorporating insights from the testing phase to continually improve the product or service.
Of course, this is a high-level design process. We could also collaborate with developers and participate in QA validations to ensure the delivery of a high-quality product.
Task 2 - Propose a design solution for the self-checkout terminals
First, I want to emphasize that this project requires real-world user experience planning. For example, we need to accommodate people of different heights and those with temporary or permanent disabilities. Some key questions to consider include:
-
At what height should we place the monitor to accommodate users ranging from 198 cm to 130 cm tall?
-
How can we prevent theft of items?
-
How can we clearly indicate that this is a self-service terminal?
-
How can we make the terminal accessible for blind users, those with low vision, wheelchair users, or people with broken arms?
Addressing these concerns involves ensuring accessibility, which will require significant research. For this project, however, I will focus on the user and web accessibility experience within the application itself.
For the app, I began by mapping out the user journey. I approach this by putting myself in the shoes of various user personas, including those with impairments, to complete the primary objectives. This mental exercise helps generate ideas and anticipate potential errors. Although I don’t use paper or other tools in this initial phase, I explore numerous ideas. Ultimately, I aimed to implement a progressive disclosure method to allow users to complete their tasks efficiently. Here is the best flow I developed:

With the user journey mapped out, I proceeded to build the wireframes. I created screens using a tablet template oriented in landscape mode. I'll present the screens here and explain my thoughts for each one.
Wellcome screen

On this screen, my primary goal is to provide clear instructions and rules using concise text. For accessibility, I’ve used a larger font size to ensure readability. To streamline the user experience, the terminal is triggered automatically when the barcode reader or scale is activated. Additionally, I included a clock as a bonus feature to help users keep track of their time.
Product with barcode screen

This screen activates when a barcode is recognized. Here are some key elements:
-
Interactive Elements: Items highlighted in blue indicate interactive elements.
-
Your Items List: Displays all added items. Users can click on a product to view details or remove it if added by mistake. It’s crucial to keep the total amount visible.
-
Cancel Item Button: Allows users to remove individual items from their list.
-
Pay and Finish Button: Triggers the payment screen. It’s prominently displayed to ensure it's easily noticeable, as it's a critical action.
-
End Session Button: Allows users to cancel the current session and start a new one. A confirmation dialog should be presented before proceeding.
-
Product Information: The main element on this screen, providing details to verify the added product. It includes the product name, brand picture, and price, all displayed prominently for easy visibility. I’ve chosen not to include an option to increase the quantity of the same product here, considering multiple units of the same product as a single item to simplify the process.
Weighing product

This screen appears when the scale is active. Here’s how it works:
-
Item Selection: Users are prompted to select an item from a list. A search bar is included to facilitate finding the product quickly.
-
Product Pictures: Images of the products are displayed to help users identify items, especially if they are not familiar with the names of vegetables, for example.
-
Card/List View Toggle: Users can switch between card and list views. This feature makes the interface more dynamic based on the user's preferences. In a real project, I would verify which view should be set as the default based on user feedback.

This screen represents the list view mode, which provides the same information as the card view but in a different layout. The list view offers a more compact presentation, making it easier to browse through items in a more linear format.

After the user selects an item, this screen displays detailed information, including:
-
Name: The name of the product.
-
Picture: An image of the product.
-
Price per kg: The cost per kilogram of the item.
-
Weight: The weight of the item as measured by the scale.
-
Total Price: The calculated total cost based on the weight and price per kilogram.
Product not found

If the barcode cannot be properly read or the product is not found, a message is displayed with the following options:
Pay and Finish Button: This button is given less prominence in this context, as the primary goal is to allow the user to locate the product.
Yes Button: Provides an opportunity for the user to search for the item from a list.
No Button: Selecting this returns the user to the previous screen, allowing them to retry or make adjustments.

This screen is similar in view and usability to the weighing product screen. Key features include:
Search Functionality: Users can search for the item by typing. The list dynamically filters and updates based on the user’s input, starting after three characters are entered.
Suggestions: Based on the user’s search query, suggestions are provided to help them find the item more efficiently.

If no matching items are found, this screen provides:
Guidance Message: Offers instructions or suggestions for the user to proceed, such as contacting a store employee for assistance.
Options: Users can choose to either continue adding items or finish the purchase. This ensures they can complete their transaction even if the item cannot be found in the system.
Limit of items exceeded

If a user attempts to exceed the item limits, the system will:
-
Restrict Adding More Items: Prevent any additional items from being added beyond the allowed limit.
-
Show Message: Display a message informing the user of the restriction and providing guidance on their next steps.
-
Options: The user can either proceed to pay or end the session. They also have the option to remove items from their list if desired.
Since users can start a new session after finishing, this is an aspect to discuss further with the team to address potential misuse or to implement additional controls.
Payment

After selecting "Pay and Finish," the terminal displays the available payment methods. Users still have the following options:
-
Remove Items: They can remove items from their list if needed.
-
Return to Previous Screen: Users can go back to the previous screen to make adjustments before proceeding to payment.
This ensures users have flexibility to make final changes or review their choices before completing the transaction.

After choosing a payment method, the screen provides:
-
Instructions: Clear, step-by-step guidance on how to complete the payment process using the selected method. This might include:
-
For Card Payments: How to insert or swipe the card, enter PINs, or follow on-screen prompts.
-
For Mobile Payments: How to use contactless payment options or scan QR codes.
-
For Cash Payments (if applicable): Instructions on how to insert cash or use a coin slot.
-

Message that the payment has been successfully made and the message to wait for the payment voucher to be printed.

A message just in case the user adds the wrong card password asking to re-try the action.

A thank you message is shown when session is finished

Confirmation dialog if the user hits the button “End session”, it’s important to have to avoid mistakes and lose all the work and even worse, slow down the whole queue.
High Fidelity Design/UI Design
For the UI design, I’ve incorporated the supermarket's brand colors to ensure visual consistency. For typography, I opted for the “Segoe UI” font family, known for its high legibility. Given the creative freedom I had, I decided to experiment with some colors that might present accessibility challenges. Specifically, I played with various shades of green and teal.
Below are the proposed fictional logo and brand colors:

The color contrast of this brand and white background are:


WCAG rule 1.4.3 says that the color contrast for regular text should be at least 4.5:1 for regular text and 3:1 for large text and WCAG rule 1.4.11 requires at least 3:1 for graphical objects and UI components, logos and non-interactive elements are an exception. With these guidelines in mind, I experimented with darker shades of teal and green to ensure compliance and maintain visual appeal.


With these guidelines in mind, I established the primary colors needed to build accessible visuals. The final result is as follows:


I applied a consistent shade of teal to all interactive elements and used lighter shades for non-interactive elements, such as backgrounds, to ensure compliance with WCAG success criteria. After meeting these standards, I further checked the design for colorblind accessibility. The results are as follows:

The colorblindness check indicates no significant issues. For the final UI test, I focused on meeting WCAG 2.5.5 criteria,which requires a minimum touch target size of 48x48 pixels. Upon review, I found that the list of items did not meet this criterion. I have since increased the touch area to comply with this requirement.

The touch area for the list of items was increased from 40x90 pixels to 65x90 pixels, ensuring accessibility compliance.
Overall, my design decisions focused on making the project as accessible as possible. I rely on WCAG guidelines as a valuable resource to enhance usability and maintain design consistency. I hope you find the solution both practical and engaging.
If you have any questions or would like to discuss this project or other topics further, please feel free to reach out via email. I’d be delighted to continue the conversation.