[DotDev 2026 Report Vol. 4] POS UI Extensions — Beyond Digital Checkouts, Lessons on UX for the Retail Floor

I'm Rossella, a front-end developer at Flagship, and this is the fourth installment of our Shopify DotDev 2026 report series. At DotDev 2026, one of the sessions I made a point of attending was a fireside chat on how POS UI extensions create better merchant experiences, featuring Harel Ishay (CEO of Easyteam and 2026 Build Award winner), Brian Edwards (Retail Product Partnerships at Shopify), and Sergio Vazquez Malvaez (Shopify Technical Consultant).

At Flagship, we aren't new to POS. We've already built custom POS extensions tailored to specific client needs and unique regional workflows.

But attending a session like this and stepping into a high-level discussion on the broader philosophy behind POS software is invaluable. Hearing from speakers who build public apps for a massive user base, alongside engineers from agencies with very different client requirements, enriches how we approach our own solutions. Plus, because markets in the US, Canada, and the UK are significantly more mature when it comes to native POS adoption, bringing those international perspectives back to our team directly strengthens our omnichannel strategy.

I went in expecting a technical walkthrough. What I got was a shift in how I think about building for the retail floor. Here is where it left me.

The half-second pause

The image that stayed with me afterward was small: the half-second after a customer taps their card. Online, that's a spinner nobody watches. In a store, it's a person standing across the counter from another person, waiting on that same half-second in silence.

Stretch it a little, and it stops being a loading state. It becomes an awkward pause between two people.

I'd never thought about checkout speed that way, as something that happens between two people, not between a person and a screen.

It became the lens I viewed the rest of the panel through.

Who are we actually building for?

The talk opened with retail staff turnover, which sits around 75% annually according to what was shared by the speakers.

As a frontend engineer, when I build online features, I rely on years of accumulated e-commerce logic. I know what a cart flow needs, how a standard checkout should feel, and what both first-time and returning customers expect from a storefront. The user brings a predictable mental model to the screen.

On a retail floor, those engineering assumptions disappear. The cashier handling the interface today might be on their very first shift, or gone in three months. They don't have the runway to adapt to custom quirks, let alone benefit from long-term familiarity.

When engineering custom POS extensions, we aren't building for a power user who gradually masters a complex tool. We are engineering for immediate muscle memory. Fewer state changes, one clear action path, and zero reliance on someone remembering a setting from last week. That's a very different technical brief than standard storefront development.

Every tap costs something different here

This is the part I found easiest to underestimate, coming from online work. A click on a website costs a user a fraction of a second, privately. A tap at the register costs the same fraction of a second. Except it's spent in front of a customer, which changes what it means. Three unnecessary taps isn't a minor UX friction on a retail floor. It's three moments where a cashier has to make someone wait.

I left thinking we should treat every tap in a checkout flow as something a merchant pays for twice: once in the time it takes, and once in how it feels to make someone else wait for it.

One workflow, not a settings screen

Building something configurable enough to fit every store is often a developer's default instinct. The speakers pushed back on that. Retail workflows do not converge the way online checkouts do. A boutique, a museum gift shop, and a hardware store do not run their floors the same way.

A good extension usually ends up shaped around one merchant's actual routine, not a menu of options that fits none of them particularly well.

This challenge becomes even clearer when comparing global markets. In the US, Canada, or the UK, POS workflows benefit from native card readers and streamlined tap-to-pay usage. But step onto retail floors in APAC markets like Hong Kong or Korea, and staff are navigating entirely different local realities, ranging from dominant regional digital wallets to external payment terminals that force cashiers to switch back and forth between devices. Every extra manual step adds friction to the employee's shift. Custom POS UI extensions are not just cosmetic UI tweaks; they are the architectural bridge that connects complex localized payment rails directly into a cashier's primary workflow, protecting them from unnecessary operational friction.

Designing for the whole shift, not just the sale. This includes time tracking, commissions, and returns, whatever staff are actually doing between transactions. Developers should also go in expecting platform constraints to design around rather than solve. For example, commission splitting among multiple staff on a single sale is not natively supported today, which requires deliberate UI planning.

There's no A/B test. There's a store.

This is the part that most changed how I think about validation. In digital development, validation usually means an experiment and a dashboard. It was highlighted how developers who build heavily for POS test, find bugs, and decide what to build next: you go stand in a store that is using your software, and you ask the people running the register.

You will have a backlog of actionable feedback before you are back at your desk.

Final thoughts

I did not expect the hardest part of building for POS to be social rather than technical. It comes down to a user who might have started this week, a tap that gets paid for in front of a customer, and a workflow you have to watch in person rather than measure on a dashboard.

Exchanges like DotDev reinforce that building custom POS extensions is not just about extending our technical capabilities, but about continuously sharpening our mindset. Whether we are solving a specific use case for an enterprise client or adapting insights from mature overseas markets, these are the human constraints that define how we engineer for physical retail.