Three taps to a ticket: designing a mobile point of sale

TicketingHub's point of sale runs on the phones and tablets of people who sell tickets in person: at a kiosk, at a bus stop, on the pavement next to the tour bus. I redesigned it from scratch, replacing the legacy app, and I was responsible for all of its design. Five engineers built it.

The redesign will get a case study of its own. This one covers three things I added after it: a way to sell in three taps, a way to sign in without an email address, and a dark theme. All three are live. You can use them here.

The brief: a sale in three taps

A sightseeing operator asked for a Favourites screen where staff could finish a sale in at most three clicks, for cash, card or voucher. The normal flow took more than five.

My first note in the ticket was that this would be a challenge. Even with favourites, a sale still means choosing a product, then tickets, then a time, then adding to the basket, then paying. I also split the brief. It asked for a landscape design for larger terminals, and a terminal needs a tablet layout, which is a separate piece of work. The scope was the phone in portrait.

The next day I posted a first flow as a recording: set up your favourite products once, then sell from one screen.

Two questions about the first flow

The feedback arrived as questions. Carl Pihl, who makes the product calls, liked it and asked what happens with many ticket types, such as military and senior, and with products sold in one-hour and two-hour versions. The engineer building it asked how the time would be chosen, and what happens when a product has mandatory questions.

I watched recordings of two other point of sale apps that Carl had pointed me to. Both went from favourites to tickets to payment, and neither asked for a time. So I merged Favourites and Quick Sale into one flow and left the time out of the main path.

In the shipped app the time takes care of itself. If the ticket has one timeslot that day, the app picks it. If it has several, the seller gets one screen of times. If it has none, the app says so.

What the client call changed

Then notes came back from a call with the client, with three requests:

• Squares for picking tickets, instead of plus and minus buttons.
• No calendar step when a date is not needed, because most of their tickets are valid all day.
• Straight to cash or card after the tickets.

I had also misread their current screen. I took the name at the top for a product with its ticket types listed below. One of the engineers pointed out that it was the company name, and that every button carried a product and a ticket type together, so one grid mixed several products. The revised design, a week later, is built on that: one square per product and ticket type.

Tapping a square adds a ticket, and tapping it again adds another. A badge counts them, and a red cross clears the square. A bar fixed to the bottom of the screen shows the number of tickets and the total, next to Checkout, which stays disabled until the first ticket is added. Tapping the count opens the basket, with one panel per product and a way back to add more. On the checkout the total comes first, the customer's details are optional, and the payment buttons are fixed to the bottom. From the dashboard, the supplier chooses which squares appear.

One adult ticket is three taps: the square, Checkout, the payment.

Signing in without an email address

The same operator came back with a second request. Their street sellers do not have email addresses. In the app they were using, a seller tapped their name and entered a PIN.

I designed a seller picker followed by a PIN pad. The engineer who built it set out what had to be true around it. The first sign-in on a device still uses email and password, so the app knows which supplier it belongs to. After that the device shows that supplier's sellers. There is always a way back to the password login, for someone who needs another account. A seller can change their PIN after entering the current one, and a forgotten PIN sends them back to the password login, where a new one is created. And the whole thing is a setting the supplier switches on. Both ways of signing in stayed available.

A dark theme in two days

The dark theme started with one line from one of the engineers: could I specify the colour palette for dark mode? We did not have one. I said I would need a day or two. Two days later I wrote in the ticket that it was 90% done, which was enough for the build to start, because so many things repeat.

They repeat because the screens never name a colour. Every surface, border and label asks for a role, and each theme supplies the value. The light theme is blue on a pale blue background. The dark theme is white on black with a single orange accent, which also replaces the blue gradient on the main buttons.

The app follows the device's own setting, through the prefers-color-scheme media query, so there is nothing to switch inside it.

What is not done

The landscape layout for tablets, the part I split off at the start, is still open. There is a basic outline, other work went ahead of it, and it is now back on the schedule.

Packages on the point of sale are covered in the packages case study, and the tickets sold here are the same ones customers buy online through the booking widget.

Outcome

Quick Sale, PIN login and the dark theme are live in the point of sale, on iOS and Android. The full story of the redesign, from the legacy app to this one, will follow in a separate case study.

Working together

I was responsible for the whole design of the point of sale, from the first screen of the redesign to these three additions. Five engineers built it.

If you are planning something similar, I am taking on new work. Write to hello@edigil.com or use the contact page.