Most B2B shop software is sold to founders. The founder evaluates it in a quiet moment, with a cup of coffee and an hour to spare, and is impressed by an onboarding flow with a warm illustration on every screen. Then the founder goes back to running the shop, and the software gets used by the team — third shift, six orders deep, on a Saturday morning when the espresso machine is acting up.

That gap between buyer and user is the single most important thing to internalise about building software for independent shops. We've come to think of every kiosk screen as a Saturday-morning test: would the new starter, three shifts in, get this right while someone is waving at them with a wallet pass and a question about oat milk?

The quiet bias of typical SaaS

Most SaaS UI assumes a particular user. They're at a desk. They have a keyboard. They've had time to read the help docs. They have a vested interest in becoming proficient because their performance review depends on it. They're, broadly speaking, a knowledge worker.

Shop staff are none of those things. They're standing. They're holding something with one hand. They've been on shift for four hours and have another four to go. They didn't choose this software; the owner did. Their incentive isn't to become proficient — it's to get through the day without breaking anything. SaaS UI patterns built for the desk-and-keyboard user actively work against this audience.

Specifically:

  • Tooltips that require a hover are useless on a touch device.
  • "Are you sure?" confirmation dialogs train staff to dismiss everything reflexively.
  • Settings screens with twenty toggles are a debugging nightmare during a rush.
  • Multi-step flows feel slow when there's a queue forming behind the counter.
  • Error states with stack-trace-style language read as "broken" to a non-technical user.

Each of those is a small thing. The sum of them is a piece of software the team avoids using whenever possible, which means the merchant doesn't get the value the founder evaluated and bought.

The Saturday-morning test

We use a single test internally to gut-check anything we ship to the kiosk: imagine the screen at 10:14am on a Saturday at an independent coffee shop. The orders are stacking up, an espresso shot has just gone wrong, and the new barista — who started a fortnight ago — is being handed a phone with a wallet pass. They have eight seconds to mark the redemption and get back to the queue.

For that scenario, three things matter and almost nothing else does. (1) The screen has to show what the member is entitled to without scrolling. (2) The redemption action has to be a single, large, unambiguous button. (3) The confirmation has to be visible without squinting and audible without leaning in.

That's it. Everything else is a distraction. We've cut features that didn't pass that test even when founders asked for them in onboarding calls — founders ask for analytics on the kiosk; staff want a button. The right answer is to put analytics on a different surface.

Three concrete decisions this changes

1. The kiosk is a browser tab, not an app

Apps require staff to install something, log in, and remember which device they're on. Browsers don't. The PerkClub kiosk runs at a URL the merchant bookmarks. Staff don't install it. They tap a tab. The cost of staff turnover — common in independent shops — drops by an entire layer of training.

We covered the related decision on the consumer side in why we built PerkClub on Apple Wallet, not a mobile app.

2. Confirmation states are visible, not modal

Modals interrupt the flow. The kiosk uses inline confirmations — a soft green border on the redemption tile, a ticked entitlement, a quiet sound. Staff see the redemption land in peripheral vision while their attention is back on the espresso machine. There's no "click OK to dismiss" required.

This is a small UX choice with large operational consequences. Modal dialogs cost attention. Inline state doesn't. Multiplied across a Saturday's redemptions, the saved attention is the difference between a kiosk staff like and a kiosk staff resent.

3. Errors say what to do, not what went wrong

The kiosk's error language is closer to a friendly note than a developer log. "We couldn't reach the network — try again in a moment, or wave the customer through if it keeps happening" is what we ship, not "Network error: unable to fetch redemption_state (HTTP 503)". The staff member doesn't need the diagnostic; they need the next action.

We give the merchant a developer-grade view of errors elsewhere — in the dashboard, with log lines, request IDs, and timestamps. The kiosk surface is for action; the dashboard surface is for analysis. Mixing them up is one of the most common mistakes I see in retail software.

What we listen for

The most useful feedback we get isn't from founders. It's from staff who message us directly to say "the redemption screen is the easiest part of my morning" or "I had to ask my manager what to do when the pass scanned but the kiosk didn't beep". Those notes are how we know if the Saturday-morning test is working. Quantitative measurement of staff usage tells you what's happening; a one-line message from a barista tells you why.

The takeaway, for software people

If you build SaaS for any business with frontline staff — shops, restaurants, salons, clinics, anywhere where the user isn't sitting at a desk — design for the user, not the buyer. The buyer evaluated your product. The user has to live with it. Most of the product's value, in the long run, accrues to whoever made the user's day easier rather than the buyer's onboarding flow prettier.

On the PerkClub side specifically: see what the kiosk does, and how the redemption flow works. The team-facing surface is what we spend most of our time on.