Repair supported import errors in Tigg, before postingRepair supported import errors in Tigg, before posting

A distributor sends a sheet of 42 delivery lines. Someone at the shop has to turn it into delivery notes in Tigg. With the old importer, they downloaded a template, copied the data into it, uploaded it and waited. The screen then said something like 38 records validated, 4 records have errors, and printed a list:

Row: 14 Rate must be a number

Row: 22 Warehouse not found

The only ways forward were Confirm Upload and Reupload New File. To fix row 22, you left Tigg, opened the file, found the row, guessed what "not found" meant, saved, uploaded the whole file again, and had every row checked again.

The bad part wasn't the error messages. The file was the only place anything could be fixed. So the question I worked on was where repair should happen, not how to word the errors better. My answer was a workspace inside Tigg: upload once, map your own columns with the gaps shown, then fix, filter and bulk-edit the rows in a grid before anything is posted.

This is a design-only case. I'm the only UI/UX designer at Tigg (BIC Technology). For bulk import I did the market research, ideation and interaction design, and drew every state on two Figma pages in the file "Tigg New Features":

• 🟢 Bulk Import: the final design, marked Ready for dev.
• 🔴 Bulk Import: an archive of ideas I explored and kept because they might be useful later.

Both pages were finished before the build began on 2 June 2026.

The senior frontend engineer built the whole frontend: the upload drawer, the mapping page, the editable grid, and how an import stays alive between edits. The backend team built the service behind it; the CEO owns the product; QA tests releases. Wherever this case says "the build", it means the senior frontend engineer's work, and decisions my frames didn't cover are credited to them.

1. Jun 2025Additions to the old importerAs an intern I added a few import types to the older importer: my only code in this area.
2. Before 2 Jun 2026Design: 🟢 final page and 🔴 archive
3. 2 Jun 2026Build begins (senior frontend engineer)
4. 20 Jul 2026Tagged releaseDelivery Note and Goods Received Note import.
5. 4 Aug 2026Tagged releaseInventory Adjustment import, on the same pages.
6. Sep 2026Product/Service import on UATBuilt on the same pattern. Not in a release tag yet.

The research was small and practical.

• Inside the old importer. In June 2025 I added Product Category, Account Group and opening-balance import to it. Looking back, every template I added was another fixed header contract, and every error another line in a Row: N list.
• Problem signals from QA, support and the CEO, which is how user problems mostly reach me at Tigg. Second-hand, and not logged as import tickets.
• Market research and ideation. This is where editing in a spreadsheet-like grid came from. I didn't keep a record of the products I looked at then, so I don't name them here.

I didn't run interviews or usability tests, and there was no data on import failures. The comparison below was done later, in September 2026, from public help-centre documentation, to place the design in its market. It is not what I studied at the time.

Mapping columns is standard. Repairing values inside the product is rare in accounting software; it's mostly dedicated import tools that let you edit a cell, see it re-checked and fix many rows at once.

"Bad UX" was my own summary of the old importer. Looked at closely, it had five separate causes, and each needed a different fix.

Two facts about the data shaped everything else.

1. The required fields are not fixed. Billing locations, warehouses and automatic product codes switch fields on and off per organisation. The same template can be complete for one business and incomplete for another. So the mapping page, not the template, has to say what is missing.
2. One document spans several rows. A delivery note with three items is three lines in the sheet but one document in the books. Posting has to treat the document as the unit.

Local vocabulary matters too: businesses in Nepal say "Godown" for a warehouse, and "VAT Applicable" is a required field on delivery notes.

I don't delete ideas that lose; I move them to a second page. The 🔴 Bulk Import page holds:

• a top-bar summary of total, valid and error rows, with Import, Selected and Filter actions;
• one table with a Pending, Ready and Imported lifecycle, where imported rows stay visible next to rows that aren't posted yet;
• a separate Fields Selected state and an alternative default screen;
• earlier versions of the input, dropdown and date editors, and of the filter states.

In retrospect, the lifecycle table put posted and unposted rows side by side. Posting creates real accounting transactions that can't be undone, so that mix is risky. The final page focuses on the rows that still need attention before posting.

One honest detail: a frame on the final page is labelled "Supposed to be DN GRN Screen but is Invoice screen for now". I drew the pattern over an invoice screen while designing for delivery notes. The design was a pattern first.

After upload comes the Map Fields page, with two panels. Mapped shows each Tigg field, the Excel column chosen for it and a sample of the sheet's values, so a match can be checked by content, not just by heading. Unmapped shows what's left. Both carry a count. A required field that is still unmapped is amber.

The first-time state arrives with matches suggested, so "Godown" lands on Warehouse Name without anyone typing. A column can be used only once.

Once mapping passes, the rows open in a full-width grid: the Excel like Editing frame. For the errors it supports, this replaces the trip back to Excel.

Four ideas carry the grid:

• Every cell has a type: text, number, date, or a dropdown for customer, product or warehouse. Free text is where import errors come from; a typed editor prevents an error instead of reporting it.
• Errors belong to cells. The wrong value is tinted and carries its own message (shown on hover in the build), not a line in a list at the bottom.
• Find the bad rows fast. One control counts and filters at once: Total rows, Valid, Errors. Under the headers, a filter row narrows further, including "errors in this column" (Filter, Filter Selected).
• Fix many rows once. Select rows and a bar appears: Bulk edit (8 rows): column, value, Apply (Rows Selected, Bulk Update). The bar states its scope first, and the value input takes the column's type. Auto fill empty carries one value to other rows.

When nothing is left to fix, the All Clean frame takes over: valid equals total, and posting is available. Posting asks for confirmation, because it "will create actual transactions and cannot be undone".

Here is one fictional import from a distributor's sheet: upload, a blocked Next, repair in the grid, and posting. Step through it with the buttons or the arrow keys.

I handed the 🟢 page over marked Ready for dev, with every state described in this case drawn as its own frame. The senior frontend engineer built it, starting on 2 June 2026, and QA tested it as part of the release. I have no record of specific review comments on these pages, so I don't claim any.

Several decisions in the build came from the senior frontend engineer, not from my frames. They're good decisions, and they are theirs:

• Imports survive leaving the page. Work in the grid is saved as a draft on the way out. An unfinished import comes back in Recent imports, where only sessions still in progress can be opened. My list of recent uploads frame gave the list a place; the build made the resume work.
• Edits are checked when you leave a cell, not on every keystroke. The cell's error clears as soon as you change it, and it comes back only if the new value is also wrong.
• Documents post whole. If only some rows of one delivery note are selected, posting stops and names the document: select all its rows first. Half a document in the books is worse than none.
• Clear limits at upload. Excel files only, first sheet only, under 2 MB. A column that has data but no heading is rejected with "Missing header for specific column", instead of being dropped without a word.
• An online/offline indicator in the grid, and a message if the connection drops.

The same mapping and repair pages now serve Delivery Notes, Goods Received Notes and Inventory Adjustment in tagged releases, and Product/Service import on UAT. Only the fields change.

Nothing about this importer is measured: no import count, success rate, time to import or support trend. My own summary, "before: bad UX; now better", is a judgement, not a result.

The claim is deliberately narrow. The grid removes the trip back to Excel for the errors it supports: typed values, references, required cells, repeated fixes. Some problems still start in the file. Supported errors are repaired in Tigg before posting; the Excel round trip isn't gone for everything.

First I'd measure where imports stall (started, mapped, posted), then whether a round trip still happens: the same file uploaded again within a day.

What I learned

• Give the failure its own frame. "Required still unmapped but clicked next" is the most useful frame on the page because it's the state people reach. Drawing it as a state set the logic for the whole mapping page: counts on both panels, amber before red, and a Next button that says why it won't move.
• Design the pattern, not the screen. The states were defined by what people need, not by one document's fields, so the same pages took on more document types.
• A design-only handoff needs to carry behaviour, not just looks. Frames show states well. Behaviour such as moving between cells with the keyboard, or pasting a block of values, is easy to leave implicit. "Excel-like" in the build means typed in-cell editing and bulk changes; arrow-key movement and paste aren't there yet. Next time I'd add a short interaction spec: a keyboard map, focus order, and what Enter and Tab do.