From Payment Terminal to Merchant Tool

Owned: operational flows, staff and shift management UX, settings, reporting patterns, and consistency across device formats and branded variants. Worked with: product and engineering, extending the payment foundation and preparing the work for the merchant product team. Staff access, shifts, tips, loyalty and reporting raised questions a payment screen never had to answer: who is acting, what they’re allowed to do, and which working period an action belongs to. On a shared device those can’t stay implicit. I treated task switching and interrupted attention as design constraints; the target behaviour was completing the merchant task with identity, permissions and shift context always clear.

I treated the existing payment experience as the foundation for a broader merchant tool, deciding where familiar patterns carry into operational work and where a different task needs its own structure. Recognisable patterns support transfer of learning for staff; shared components reduce variation for engineering.

A staff profile represents the person. A device session establishes who is using that device. A shift represents a period of work and its activity. They’re related, but they must not silently stand in for one another: signing in, managing a profile and starting or ending a shift have different meanings and consequences. The separation also made the engineering questions explicit: which state changes, who can change it, and where the change should show.

The experience was designed for terminal and tablet formats and under different brands. Reusable patterns and theming keep meaning consistent: familiar actions, understandable states and a recognisable hierarchy. Where a format or implementation genuinely needed a different journey, I made the variation explicit rather than forcing one flow on every variant.

Some actions need supervisor authorisation. My focus was the interruption itself: keeping enough context for the staff member and supervisor to understand the request, and a clear route back to the task. Required controls stay; the design question is how attention and recovery work around them.

Ending a shift can affect one person’s work or several active shifts, depending on the operator’s permissions. The action label, selected scope and confirmation have to agree, so someone knows whose work will be affected before they confirm. Here friction is useful: the consequence deserves attention. Active-shift views and reporting, starting with date and status filters, then give people a place to review what happened instead of relying on memory.

When the work moved to another product area, the rationale and unresolved requirements became part of the deliverable. I documented why identity and shifts are separate, which patterns are reusable, where variants are intentional and what each authorisation step controls. The handover is complete, and the receiving team now extends the work on that basis.

Delivered: an operational model around the payment foundation, now live: staff management, session and shift distinctions, permission-aware actions, approvals and reporting, extendable across form factors and brands. The leadership contribution was connecting what could have been separate feature requests: identity affects shifts, shifts affect reporting, and authorisation affects the transaction. Observed: the handover is complete, and the merchant product team now owns the product and extends it from the documented model. Still to measure: can staff tell session state from shift state, understand whose work an action affects, continue after authorisation and find the relevant activity in reporting?