Group settings by what they areGroup settings by what they are

Tigg's accounting Configuration area decides how the rest of the product behaves: VAT account mapping, what happens when cash or stock would go negative, how documents are numbered each fiscal year, which banks and payment modes appear in forms, how invoices print, and how data comes in. People rarely visit it, but a wrong setting there quietly changes every invoice, bill and report after it.

The structure that still ships has six top-level sections. One of them, Apps, holds 14 sub-pages that have little to do with each other. Inside Apps, a single General page stacks nine unrelated policy cards in one scroll: pricing rules, the inventory mode, batch and serial tracking, three balance policies and two VAT mappings. VAT rules sit next to printing templates.

Nobody designed it this way. The page was built long ago, and as more features shipped, settings were simply added on top of one another without structure. The Apps list started with 11 entries in January 2021 and had 15 by March 2025, added and renamed by many engineers over four years. Each new feature went into whichever list its engineer was already editing.

That produces three kinds of problem, and all of them are visible in the current screens:

• The label predicts nothing. "Apps" says nothing about what is inside.
• Related things are split. CRM lists live under "CRM", but CRM task types live under "Workflow". Feature switches are split between Organization and Apps › General. Opening balances and data import are separate top-level sections, although both are about loading data.
• The most consequential page gave no feedback. The General page saved every choice instantly and silently. The only way to know a change had worked was to reload.

The direction is simple to state: group settings by functionality, so that each group's name tells you what you will find in it.

The CEO's brief: group by department

In June 2026 the CEO wrote the brief. It listed everything in the old structure, named the problem, and proposed groups by business area: Company & Billing, Financial Rules, Sales & CRM Setup, Purchase & Payments Setup, Documents & Templates, Automation, Data Management, Integrations and so on.

In August 2026 I built that proposal as ten working groups inside the real product, on a development branch, so the grouping could be tried with real settings instead of on a diagram. Building it showed where it strained. Some lists belong to more than one department. Payment modes and banks are used by sales and purchases; task types are used by CRM and by everyone else. Filing each in one place hid it from half the people who need it, so three settings had to be listed in two groups.

The CEO's second proposal: group by what a setting is

The CEO then made a six-group prototype: Organization Setup, User & Permissions, Reference and List, Templates and Fields, Data Management, Integration and Automation. Its groups are defined by the kind of thing a setting is, not by who uses it. In September 2026 I rebuilt the prototype on this structure, and this is the design I am developing now.

When I sorted the 36 settings both ways, the reason for the difference was clear. A payment mode is a list whichever department uses it, so it has one natural home in "Reference and List". The department axis breaks exactly where lists are shared.

A six-group outline leaves most of the design still to do. The prototype didn't place every setting, and the old pages weren't built to be moved. This is the work I am doing now.

Placing what the outline didn't cover

• Inventory Tracking Mode and Batch & Serial Tracking go in Organization Setup. They weren't in the prototype, but they decide whether whole document types exist, so they belong with the settings that shape the organisation.
• Controls is one page with three sections: pricing rules, balance and credit controls, and VAT account mapping. This is the old General page, taken apart by concern.
• Reference and List is one flat group. There is no split by sales or purchase, and no setting is listed twice.
• Third Party Integration gathers SMS and the marketplace connection in the hub, but links out to where their settings already live instead of moving them.

Showing only what applies

Seven settings depend on the organisation: an organisation without inventory doesn't see the inventory settings, and IRD sync appears only when IRD is enabled and verified. A person sees between 28 and 35 settings. Groups that would be empty are hidden, and each group opens on its first visible setting.

Acknowledging every save

Policy choices still save as soon as you pick them, but each card now shows a small "Saved" mark for about two seconds. If the save fails, the choice snaps back and an error explains why. A toast for every radio click would be noise; a quiet mark next to the card answers the question the old page left open: did it save?

Moving the doors, not the rooms

Configuration has dozens of screens, and other parts of the product link straight into them. So the change is navigational: each setting keeps its existing screen, and I'm adding redirects from the old addresses to the new homes as I go. That is also what let the grouping be tried twice in six weeks.

These are the questions I can't settle by reasoning alone:

Validation plan (not yet run)

1. Open card sort of the 35 settings, to see whether people group them by what they are or by department. This tests the main idea directly.
2. Tree test of the old structure, the ten-group version and the six-group version, with 10 to 12 tasks such as "Stop invoices when a customer is over their credit limit", "Add a new bank" or "Change how quotation numbers restart each fiscal year". Measures: task success, first click correct, time.
3. Who: Tigg support and QA first, because they are easy to reach; then five to eight customer admins.

Status: work in progress. The six-group prototype runs inside the product on a development branch. It is not merged, not released and has not been through QA. There has been no user testing and no feedback on it yet, so there is nothing to measure. Measured outcome: none. After release, I would watch "where is setting X?" questions to support before and after, and how often old addresses are still used.

What I've learned so far

1. 01

   The axis matters more than the count

   The discussion sounds like 'ten groups or six', but the real change is from who uses a setting to what a setting is. The department axis failed exactly where lists are shared.

2. 02

   Prototype structure in the real product

   Building the brief in code surfaced things no diagram would: settings that decide whether other screens exist, lists that can't be split without a new field, and links from other screens that must keep working.