JOBR Point of Sales (POS): Selling Made Simple

One App to Sell In-Store, Online, and On the Go - Built for the Counter, Designed for the Business

My Role:

Founding Designer

As the first and sole designer at JOBR, I didn't just design a POS - I built the entire point-of-sale experience from the ground up, across three platforms. From the cashier's first scan to the owner's end-of-day report, I owned every screen, every flow, and every decision. I defined the interaction patterns that made a complex commerce tool feel fast, familiar, and frustration-free for non-technical SMB owners and their staff.

My responsibilities extended beyond screen design. I shaped the product definition itself - pushing back on feature requests that would create cognitive overload, arguing for a design-system-first approach before a single screen was built, and making the case to leadership that simplicity for the cashier and power for the owner were not in conflict. These were product strategy arguments, made through design

The Problem

Running a small business meant juggling too many tools at once.

Small business owners were running their entire operation on a patchwork of tools - a different app for selling, another for inventory, a spreadsheet for bookings, and a notebook for cash reconciliation. Every day started with manual data entry before any real work could begin.

Cashiers made mistakes under pressure because the tools weren't built for speed. Managers had no visibility into what was actually happening at the counter. Owners couldn't trust their numbers because the numbers lived in four different places.

The deeper problem wasn't the tools themselves - it was that no single tool was designed for the full reality of running a small business. Everything was built for one job, which meant nothing worked well together.

The market needed a single, unified POS that worked across every device a business already used - and felt native on all of them.

The Challenge

Designing a POS that had to work across Web, iPad, and Mobile - serving three completely different users (owner, manager, cashier) with three completely different goals - without becoming three separate products.

The design challenge was unification without compromise. Every surface had to feel native. Every role had to feel like the product was built for them specifically. And the underlying complexity - 12 interconnected feature areas, 50,000+ products, multi-channel orders, real-time inventory - had to disappear from view for the people who needed it most.

For the web back-office and admin dashboard (analytics, payroll, inventory, product management), see the dedicated Admin case study.

Navigating Ambiguity

The hardest design problem wasn't any single screen. It was a foundational question with no clear answer: should a cashier ever see a delivery order while serving someone in-store?
The engineering team said no - keep contexts separate, reduce complexity. Early user interviews suggested cashiers were overwhelmed when both appeared at once. But business owners were explicit: a missed delivery during a busy floor shift was costing them 1-star reviews. Both things were true.
I ran a low-fidelity prototype test with three business owners, asking them to handle a 'counter sale + incoming delivery' scenario. What emerged was surprising - the problem wasn't seeing both contexts. It was not knowing which one was more urgent. Cashiers were freezing because the interface gave equal visual weight to a $4 coffee order and a 20-minute-overdue delivery.
That reframe changed everything. Instead of hiding one context, I gave them a visual urgency hierarchy - delivery orders gained a live countdown timer and a red urgency indicator once they crossed a threshold. Counter sales stayed dominant. The decision wasn't about separation; it was about signal.
This also had a product implication beyond design: it surfaced a need for an urgency-threshold setting that didn't exist in the backend. I documented that gap and worked with the PM to get it scoped. The feature shipped six weeks later.

Platform Design - One Experience, Three Surfaces

Early on, I had to make a foundational decision: build separate experiences for each platform, or design one coherent system that adapted. I chose the latter - and built a design system first, before designing a single screen.

This meant every component, every interaction pattern, and every piece of data was designed to work on a 27" monitor, a 10" iPad, and a 5" phone. The constraint made the system stronger. Anything that couldn't survive all three surfaces wasn't worth building.

Web served the owner and manager - full analytics, back-office control, bulk operations. Designed for depth, not speed.

iPad served the cashier at the counter - selling, checkout, cash drawer. Designed for speed, not depth. Every tap had to be intentional and every action had to be reversible.

Mobile served the owner on the move and drivers on delivery - quick status checks, booking confirmations, order handoffs. Designed for context, not control.

Same design language. Same data. Completely different jobs.

Building the Design System

Before I designed a single screen, I built the system that would generate all of them.

The JOBR design system started as a set of constraints: every component had to work at three screen densities, support two themes (light for the back-office, dark-capable for counter environments with screen glare), and remain legible for users who might be processing information quickly under pressure.

I defined four foundational layers:

Tokens - a single source of truth for color, spacing, radius, and elevation. Changing a brand color updated every component across all three platforms simultaneously.
Core components - 34 primitives: buttons, inputs, cards, drawers, modals, toasts. Each documented with 3-5 states (default, hover, active, disabled, error). Error states were designed to be calm and instructional, not alarming - cashier errors under pressure needed to be recoverable without embarrassment.
Composite components - the catalog grid, the cart rail, the checkout card, the booking row. These were the building blocks unique to JOBR's domain, designed once and reused everywhere.
Motion principles - three motion speeds: instant (0ms, for state changes while a customer is watching), quick (150ms, for panel transitions), and deliberate (300ms, for confirmations and completions). Motion wasn't decoration; it was feedback.

The design decision: a system built for constraint is faster than a system built for flexibility. Speed on the counter required zero ambiguity in the components serving it.

The payoff compounded over time. When JOBR expanded into service bookings 14 months later, the new Bookings feature was designed and handed off in 3 weeks - because 80% of the components already existed.

Design Decisions

The Login Problem - Who is at the Counter Right Now?

A shared device (iPad at the counter) used by multiple staff members created an immediate UX problem: whose session is this? Whose cash drawer? Whose sales numbers?

I designed a role-based login system where each staff member had their own session - with individual cash drawer batches, sales tracking, and permissions baked in from the moment they logged in. The Lock Screen feature meant a cashier could hand the device to a manager without losing session data. The Cashier home screen surfaced the user's name, ID, today's sales, and drawer balance immediately on login - so accountability was visible, not buried in a settings menu.

The design decision: identity had to be the first thing you saw, not the last thing you thought about.

The Catalog Problem - Products, Services, and Promos in One Place

When I first mapped out what cashiers needed to access at the counter, the list was overwhelming: physical products with variants, services with staff assignments, promotional bundles, and real-time pricing across multiple channels.

The instinct would be to build separate flows. Instead, I designed a unified catalog with three tabs - Products, Services, Promos - all searchable by barcode, SKU, or name. The visual grid layout used real product photography so cashiers could identify items instantly, even without reading. A persistent cart on the right rail meant adding items and reviewing the order happened simultaneously, not in sequence.

The design decision: browsing and selling had to happen in the same view.

The Checkout Problem - No Payment Left Behind

Checkout is where design failures cost money - literally. I found that most SMB POS tools were built around cash and card, with everything else treated as an afterthought. But JOBR's users were serving customers who expected to pay with reward points, gift cards, QR codes, and increasingly, crypto.

I redesigned checkout as a two-step flow: tip selection first (which primed the interaction positively), then payment method. Each payment method was a large, tappable card - not a dropdown, not a toggle. The customer's reward point balance was shown in real-time with its dollar equivalent, so cashiers could recommend redemption without doing mental math.

The design decision: every payment method had to feel like the primary payment method.

Transparency in the Cash Drawer

Cash discrepancies at end of day erode trust between staff and owners. Most POS tools made it worse by only showing numbers at closeout.

I designed the Cash Drawer as a live session - opening balance, running total, and closing balance visible throughout the shift. Every session was tied to a cashier's identity.

The design decision: transparency during the session prevents conflict at the end of it.

Booking as a First-Class View

Service businesses were selling time, not products. Bookings needed to be a coordination tool - not a calendar bolt-on.

The list view showed every appointment on one scannable row: client, staff, service, time. A live staff panel on the right showed who was active and how many appointments each had queued. Check-in was one tap.

The design decision: replace the whiteboard on the wall, not just digitize it.

The whiteboard metaphor was deliberate and intentional in the visual design, not just the structure. The staff panel used avatar indicators with warm color coding (green = available, amber = with client, grey = off-clock) borrowed from the physical world of a salon or workshop. It had to feel immediately readable from across the room - not just on screen. I tested legibility at arm's length before finalizing the size and contrast of each indicator.

Analytics That Answer Questions

Owners weren't looking at analytics because the tools weren't built for them. Raw tables don't help someone between serving customers.

I structured the dashboard in three tiers: Snapshot (what's happening), Investigation (why), Action (what to do). Every chart filterable by date and channel.

The design decision: analytics had to answer questions, not just display numbers.

In-Store and Online, Side by Side

The most stressful cashier moment: an online order arriving while already serving someone at the counter. Two contexts, one screen, no clear way to handle both.

I designed POS Home with selling on the right and a live delivery queue on the left - customer, distance, items, urgency, and timer - all updating in real time.

The design decision: in-store and online weren't two modes - they were two columns.

Loyalty That's Visible

Loyalty programs fail when they're invisible. Customers forget points. Cashiers forget to mention them.

I designed loyalty as a leaderboard with a podium — celebratory, not transactional. At checkout, reward balance appeared automatically with a checkbox to apply it. Opt-out, not opt-in.

The design decision: loyalty had to be seen by staff, not just stored in a database.

The podium was the most consumer-oriented design choice in the entire product. It had no functional requirement behind it - a table would have worked. But a podium communicates rank, celebration, and aspiration. It made top customers feel recognized the moment a cashier pulled up their

The Results

Across the 3 years I designed JOBR's POS, the product scaled from a single-category retail tool to a full commerce platform serving retail, food & beverage, and service businesses.

The design system I built on day one served all 12 feature areas without requiring a full redesign. The cross-platform architecture decision meant a single design handoff covered all three surfaces - compressing design-to-development cycles significantly. The clearest measure of the work: JOBR's onboarding completion rate (owner setup through first live transaction) became a product health metric, and the design of the first-run experience was cited in user research as a key driver of confidence for first-time POS users who had never used a digital till before.

Key Learnings

Speed is a feature at the counter. Every extra tap has a cost measured in seconds and customer patience.
Role-based design is about relevance, not just permissions. Each user had to feel like the product was built specifically for them.
Edge cases are where trust is built or broken. Returns, split payments, cash discrepancies - they happen every day. Quality lives here.
Design systems are the highest-leverage work. Every component built on day one compounded across three years and 12 feature areas.
Ambiguity is a design input, not a blocker. The best design decisions came from reframing the question, not from having more information. When stakeholders disagreed, that was almost always a signal that the real problem hadn't been named yet.
Delight is a product strategy, not a finishing touch. The loyalty podium, the tip-first checkout, the product photography requirement - none of these were in the brief. All of them shaped how users felt about the product. Feel is what makes people recommend software.

Page updated

Google Sites

Report abuse