A tracked item cannot enter the cart incompleteA tracked item cannot enter the cart incomplete

A customer buys three strips of paracetamol. Two come from a batch that expires in October, one from a batch that expires next March. Tigg POS used to record that sale as "Paracetamol 500 mg × 3". The invoice could not say which batch left the shop, or whether one of them had already expired.

The same gap showed up with phones. A shop sells two handsets, scans both serial numbers, and the cashier then taps "+" on the cart row to make it three. The cart now says three phones and knows two identities. A month later, when one comes back under warranty, nobody can say which unit it is.

Before this work, the POS treated every product as a quantity. A cart line was product × unit × quantity, and two lines with the same product and unit merged into one. That works for tea and biscuits. It fails for anything where the units are not interchangeable.

The brief asked for batch and serial number tracking across Tigg. The problem underneath it was narrower and harder: identity has to survive every step, from product setup to the sale, the invoice, the return and the report. A settings toggle does not do that on its own.

The CEO wrote the brief as eight design tasks, one per surface, in July 2026. I was the only UI/UX designer on the team.

So the claim is specific: I designed all eight surfaces and built the POS frontend. I did not build batch and serial tracking end to end. The accounting screens and the backend belong to other people.

Constraints that became requirements

• Two independent switches. The brief said a business can turn on batch tracking, serial tracking, or both. A product can be flagged for either, but a product flag only counts when the organisation has that switch on.
• VAT-inclusive prices. Many Tigg businesses price with 13% VAT included. A batch carries its own selling price, and that price has to reach the line as the final price, without VAT being added a second time.
• Barcode scanners. A scanner types characters and presses Enter, fast. The field has to accept a stream of scans, reject a duplicate, and keep focus where the next scan goes.
• Warehouses per location. Whether a serial is in stock depends on the location's default warehouse. A location without one cannot check serials at all.
• The server knows the truth. Only the backend knows whether a serial is in stock, already sold, or eligible for return. The POS can check for blanks and duplicates locally; everything else is a question it has to ask.
• Devices. The POS runs in desktop and tablet browsers at the counter.

There was no merchant interview or usability test for this feature. I want to say that plainly, because the rest of the case depends on reasoning rather than observed behaviour.

What I did have:

• The brief and the CEO. The CEO explained each task when it was assigned. Across my work, what I know about user problems comes mostly from QA, support and the CEO.
• Zoho, which I used as a reference product at the time.
• Domain modelling. Working out what a batch, a serial number and an order line had to carry, and what the server could answer, was most of the early work. It is technical discovery, and I count it as research.
• Designing in the browser. I designed the POS flows directly in code, prototyping them in the running app against sample data before the real stock endpoints were ready. That let me feel how a scanner stream, a focus change or a held dialog behaved, which a static frame does not show.

A competitor review, done later

While writing this case in 2026, I compared the shipped design with public documentation for other products. This review was not part of the original work.

Tigg ended up between Odoo's permissive "record it if you can" and ERPNext's heavier bundle model. Identity is required at the sale. Expiry is a warning.

Who I designed for

These are assumption-based proto-personas, drawn from the brief and the product's scope, not from interviews. The shop types are illustrative.

• The counter cashier at a pharmacy-type shop, with a queue. Needs the next required field focused, nothing half-finished in the cart, and errors that say how to fix them.
• The electronics shop owner, handling a warranty return of one unit out of three. Needs to return a specific serial and see each unit's status.
• The admin setting up the business. Needs two plain switches that say what they hide.
• The inventory person, looking for stock that expires in the next 30 days, per warehouse.

I arranged the eight surfaces along the life of a tracked item: switch the feature on, flag a product, bring stock in, move it through documents, sell it, inspect it, and drill into it. Seven of them are covered here.

Two switches, four modes

The organisation settings got two cards in the style the existing inventory settings already used, each with On and Off. The copy says what Off does, because that is the surprising part:

Batch Number Tracking. Track stock in numbered batches with their own manufacture and expiry dates. Turning this off hides the Batch field on order lines, even for products still flagged as batch-tracked.

The product form then gets two Yes/No questions, "Batch Tracking" and "Serial Number Tracking". They are hidden for service products, and hidden when the organisation switch is off, so an admin never sets a flag that does nothing.

The two levels resolve to one of four modes per product: untracked, batch, serial, or both. The line editor shows only the inputs the mode needs.

Keeping the mode to a single resolved value mattered more than it looks. Every later surface, from the cart line to the refund dialog and the reports, asks the same question, "what does this product need?", and gets the same answer.

My first version was a standalone selection page. Tapping a tracked product opened a full screen titled "Select Batch & Serial Numbers", with its own quantity stepper, a scan field that turned serials into chips, a list of batch cards sorted by expiry, a "+" to add a batch, and an "Add to Cart" button. I built it against sample data at the end of July 2026 and removed it two days later.

Selection moved into the line editor, the screen that already opens when a cashier edits a line's unit, rate or discount.

I didn't write down my reasons at the time. Reading the prototype against what shipped, these are the ones I can reconstruct:

• Two quantities. The page had its own stepper. The line had a quantity too. Two sources for one number is how a line ends up with three phones and two serials.
• The line editor already owned price. Rate, unit, discount and the VAT-inclusive handling already lived there. A batch's selling price had to land in that same logic, not in a copy of it.
• One place to come back to. If a line was ever incomplete later, I would need to send the cashier somewhere to fix it. That place should be the editor they already know, not a second page.
• Fewer ways to add. "Add to Cart" on a separate page was a second way to put an item in the cart, with its own rules.

What survived were the parts that were about the counter, not the page: scan-first serial chips, the duplicate and limit messages (same wording), batches sorted by expiry, the amber warning under 120 days, and the fields of the new-batch dialog.

The rule I built the rest around is in the title: a tracked item cannot enter the cart incomplete.

When a cashier taps or scans a tracked product, it does not go into the cart. The line editor opens with a pending line. The cashier scans serials or picks a batch there. Save puts it in the cart as its own line. Cancel leaves nothing behind.

The alternative was to add first and nag later: put the item in the cart and mark it as missing something. I chose not to. A half-filled line in a shared cart can be paid for, printed, or forgotten. Holding it outside the cart means the cart only ever contains lines that can be sold.

When are two lines the same line?

The old cart merged any two lines with the same product and unit. I changed what "the same" means. Two lines merge only if they share product, unit and batch, and neither carries serial numbers. A serialised line is always its own line, because each unit is a different thing.

This was the most consequential choice in the feature, and no mock-up would have shown it. It decides what the invoice says, what a return can reverse, and what the report counts.

Most of the interaction design is in two fields: Serial Numbers and Batch.

The serial field

The label carries a counter, "Serial Numbers (0/3)", in red until it reaches the quantity, then green. The field is focused when the editor opens, and the placeholder says how it works: "Scan or type, then press Enter". Enter submits, because a scanner ends every scan with Enter. After each accepted serial, the input clears and focus comes straight back, so the next scan lands in the right place.

Each serial becomes a removable chip set in a monospace font. Looking back, that was a legibility choice: serials mix letters and digits, and a fixed-width face makes 0 and O, or 1 and l, easier to tell apart when a cashier is checking a chip against a box.

The messages say what happened and what to do:

"Not valid" and "could not check" are deliberately different. A dropped connection is not evidence that a serial is wrong, and it should not read like one.

When a product needs both

For a product tracked by both, the serial field comes first. When the last serial is accepted, focus moves to the Batch select. My reasoning, in retrospect: scanning units is the repeated action and the batch is chosen once, so the repeated action should need no extra tap. The batch could have come first; this order keeps the cashier's hands on the scanner longest.

The Batch select opens on focus and lists batches earliest expiry first. Each option shows the batch number, "Expires" with the date, and the balance on the right. Under 120 days the date turns amber. Past its date the option reads "Expired" in red. The colour is never the only signal; the word is always there.

A new batch can be added from the top of the menu, with Batch No., Expiry Date and Selling Price required, and Manufacture Date and Purchase Price optional. Once saved, it is selected and its price applied.

Choosing an expired batch

Picking an expired batch does not apply it. The POS holds the choice and asks:

Batch Already Expired. This batch has already expired. Do you still want to continue?

Continue applies it. Cancel drops the held choice and the field goes back to what it showed before, so the screen never displays a batch the line doesn't have.

Expired batches are warned about, not blocked. That is how it shipped, and it is a policy rather than a law of nature. The reasons I would give for it now:

• a shop may have a legitimate reason to sell or clear stock at or near its date;
• the date on record may be wrong, and the person at the counter is the one holding the box;
• blocking the counter while a queue waits is expensive, and the cashier has no way to fix the data there.

Other products choose differently: BUSY can hide expired batches, and Odoo and ERPNext pick by expiry in inventory. A setting per organisation (warn, hide, or require a manager) with a note when someone overrides the warning is the obvious next step.

When the quantity changes later

The cart row still has a quantity stepper outside the editor. A cashier can raise a phone line from two to three after scanning two serials. The first version of the guard stopped the save with a toast. That told the cashier something was wrong but not where.

The shipped version routes. When Save or Pay is pressed, the POS finds the first line that breaks the rule, shows "Fill in the required batch/serial number details before saving the order.", and opens that line in the editor with focus in the serial field. The same guard runs on the buttons of every order type.

At payment, every serial is checked with the server once more before the invoice is created, in case stock changed while the order was open.

Returns reverse units, not numbers

A return has to say which units came back. The refund dialog lists each invoice line with what can still be returned: the quantity sold minus what was returned before. Lines with nothing left are hidden. For a serialised line, the cashier ticks the specific serials; each one is checked with the server as it is ticked. The counter stays red until the ticked serials equal the return quantity, a remark is required, and only the ticked serials are sent back. A returned item is not for sale again unless it is restocked.

surfaces designed

8surfaces designed

tracking modes from two switches

4tracking modes from two switches

states designed for the serial field

13states designed for the serial field

measured outcome

Nonemeasured outcome

The POS side was released in a tagged release in September 2026. Along with the sale and return flow, it included:

• one Batch / Serial Number page in Inventory, with a tab for each (two separate pages were merged into one in late August), and a detail drawer per batch or serial with its dates, prices, status and recent transactions;
• serial statuses Available, Not Available and Oversold;
• batch and serial numbers under the product name on invoices, credit notes and sales orders;
• a Product Batch Report that answers "what expires in the next N days?", grouped by product or warehouse, and a Product Serial No Report filtered by status;
• report permissions that disappear when the organisation switch is off.

Because I designed these flows in the browser and built the POS frontend myself, the POS behaviour on this page is the behaviour in the release. The accounting screens were built by the senior frontend engineer from my designs; I haven't reviewed them closely enough to say how closely they match.

Feedback

Good feedback.Reported to me by the CEO

That is the whole of the feedback I can cite. It is informal, and I don't know which businesses it came from.

What is not measured

Measured outcome: none. There are no adoption numbers, no count of businesses with tracking switched on, no checkout-time data, no error rates and no usability test. If I could instrument it, I would look at:

1. how often a tracked line is sent back by the repair route, per order type;
2. time from tapping a tracked product to saving its line;
3. serial check failures by reason: duplicate, refused, network;
4. how often cashiers continue past the expired-batch warning versus cancel.

I also designed the launch promo artwork, on the Figma page "Batch and Serial No".

Line identity is a domain decision, not a code detail. Deciding when two cart lines are "the same" shaped the invoice, the return and the report. It was invisible in every mock-up and it was the choice that mattered most.

Don't let incomplete things into shared state. Holding a tracked item outside the cart until it was complete removed a whole class of half-filled lines, instead of adding warnings to catch them.

Put enforcement where the fix is. A toast that says "something is missing" hands the problem back to the cashier. Opening the exact line, with focus in the right field, solves it. The same thinking applies to the expiry warning: warn at the moment of choice, where the person holding the box can decide.