← Back to Home
Case Study 01
Fintech
POS
Design System
POS Payment Experience
POS Payment Experience
POS Payment Experience
A concept for a calmer, more accessible POS sale flow, shaped by three years of designing payment terminals for Greek acquirers.
A concept for a calmer, more accessible POS sale flow, shaped by three years of designing payment terminals for Greek acquirers.
View Prototype ↗
Project Type
Independent Concept
Independent Concept
Role
Product Designer
Product Designer
Platform
POS Terminal Application
POS Terminal Application
Tools
Figma
Figma
The Challenge
The Challenge
I’ve worked on five POS applications for payment providers, all under NDA. The same issues came up again and again: components that changed from screen to screen, accessibility treated as an afterthought, and screens trying to do too much at once. Teams often tried to reduce friction by removing screens, which only pushed more decisions into fewer views.
A POS is used by people who never chose to be “tech users”: a waiter taking payment at the table with one free hand, or a shop owner in their sixties at a busy till. This concept asks what the core sale flow looks like when it’s designed for them.
I’ve worked on five POS applications for payment providers, all under NDA. The same issues came up again and again: components that changed from screen to screen, accessibility treated as an afterthought, and screens trying to do too much at once. Teams often tried to reduce friction by removing screens, which only pushed more decisions into fewer views.
A POS is used by people who never chose to be “tech users”: a waiter taking payment at the table with one free hand, or a shop owner in their sixties at a busy till. This concept asks what the core sale flow looks like when it’s designed for them.
Design Approach
Design Approach
Clarity over step count. Each screen asks for one decision. An extra screen with a single clear question is easier than one screen with three.
Built for one hand. Primary actions and navigation sit at the bottom of the screen, within thumb reach, because handheld terminals are often used on the move.
Calm, functional visuals. A flat, high-contrast palette replaces the decorative gradients common in this category, so that status and amounts stand out.
Consistency through a system. Every screen is built from shared tokens and components, so the merchant learns the pattern once.
Clarity over step count. Each screen asks for one decision. An extra screen with a single clear question is easier than one screen with three.
Built for one hand. Primary actions and navigation sit at the bottom of the screen, within thumb reach, because handheld terminals are often used on the move.
Calm, functional visuals. A flat, high-contrast palette replaces the decorative gradients common in this category, so that status and amounts stand out.
Consistency through a system. Every screen is built from shared tokens and components, so the merchant learns the pattern once.
The Solution
The Solution
The sale flow moves through amount entry, installments, card presentation (tap, insert or keyed entry), payment method, PIN, processing and signature, and ends with a confirmation offering an SMS, email or printed receipt. Each step has a single job. The transaction amount stays visible throughout, so the merchant and the customer can always check what’s being charged.
Not every merchant accepts every payment method. Some only take cards, while others also accept QR payments through IRIS, Greece’s instant payment network, or MOTO (mail and telephone orders). Instead of showing every merchant every option, payment methods are switched on in Settings. A card-only merchant never sees the method selection screen and goes straight from amount to card. When more methods are enabled, a single selection step appears and leads into the matching flow.
The sale flow moves through amount entry, installments, card presentation (tap, insert or keyed entry), payment method, PIN, processing and signature, and ends with a confirmation offering an SMS, email or printed receipt. Each step has a single job. The transaction amount stays visible throughout, so the merchant and the customer can always check what’s being charged.
Not every merchant accepts every payment method. Some only take cards, while others also accept QR payments through IRIS, Greece’s instant payment network, or MOTO (mail and telephone orders). Instead of showing every merchant every option, payment methods are switched on in Settings. A card-only merchant never sees the method selection screen and goes straight from amount to card. When more methods are enabled, a single selection step appears and leads into the matching flow.
Behind the Design
Behind the Design
Image placeholder
Persona
A waiter taking payment at the table and a shop owner at a busy till. Different settings, same need: get the payment right on the first try.
Image placeholder
Design System Foundations
Color, type and spacing tokens that keep every screen consistent, so the merchant learns each pattern once.
Image placeholder
Iconography
A purpose-built set for payment methods, statuses and actions, readable at a glance on a small terminal screen.
Image placeholder
Buttons & Components
Reusable components with defined states, sized and placed for one-handed use.
Image placeholder
Core Screens
The full sale flow, from amount entry to receipt.
Image placeholder
Edge States
Declined, timeout and retry: the moments when clear feedback matters most.
Image placeholder
Persona
A waiter taking payment at the table and a shop owner at a busy till. Different settings, same need: get the payment right on the first try.
Image placeholder
Design System Foundations
Color, type and spacing tokens that keep every screen consistent, so the merchant learns each pattern once.
Image placeholder
Iconography
A purpose-built set for payment methods, statuses and actions, readable at a glance on a small terminal screen.
Image placeholder
Buttons & Components
Reusable components with defined states, sized and placed for one-handed use.
Image placeholder
Core Screens
The full sale flow, from amount entry to receipt.
Image placeholder
Edge States
Declined, timeout and retry: the moments when clear feedback matters most.
Image placeholder
Persona
A waiter taking payment at the table and a shop owner at a busy till. Different settings, same need: get the payment right on the first try.
Image placeholder
Design System Foundations
Color, type and spacing tokens that keep every screen consistent, so the merchant learns each pattern once.
Image placeholder
Iconography
A purpose-built set for payment methods, statuses and actions, readable at a glance on a small terminal screen.
Image placeholder
Buttons & Components
Reusable components with defined states, sized and placed for one-handed use.
Image placeholder
Core Screens
The full sale flow, from amount entry to receipt.
Image placeholder
Edge States
Declined, timeout and retry: the moments when clear feedback matters most.
Outcome
Outcome
This concept brings together what I’ve learned across five production POS apps: one decision per screen, controls within thumb reach, and a flow that only shows what each merchant needs. It’s prototyped but not yet tested. My next step is to put it in front of real merchants and let their feedback shape the next version.
This concept brings together what I’ve learned across five production POS apps: one decision per screen, controls within thumb reach, and a flow that only shows what each merchant needs. It’s prototyped but not yet tested. My next step is to put it in front of real merchants and let their feedback shape the next version.
Outcome image placeholder
Designed for better payment experiences.
Designed for better payment experiences.
Explore more projects ↗
Explore more projects ↗