Three problems with the transactions filter
1. You cannot filter for "no tag"
The tag list can only say "has this tag". There is no way to ask for the transactions that still need tagging. That is the feature we are adding.
2. The panel is crowded
One dropdown holds two toggles, a tag search, a scrolling tag list and a scrolling account list. That is a scroll area inside a scroll area in a 320px panel — the main reason it feels messy.
3. The same filters are set again every visit
Someone who always works on one slice — "not tagged, transfers hidden, ANZ Everyday" — rebuilds it from scratch each time. The third addition lets them save that set as their default, so the page opens with it. See it below ↓
How the four concepts differ
| Concept | What it is | Opens as | Applies | Main trade-off |
|---|---|---|---|---|
| A | Today's dropdown, tidied up | One tall panel, everything visible | Instantly | Still one long scroll |
| B | Same dropdown, but the groups start closed | Three short rows | Instantly | One extra click to reach a tag |
| C | A full filter window with a menu down the side | Modal over the page | On "Show N" (Cancel undoes) | Hides the list while open |
| D | No panel — one small chip per filter, in the toolbar | Nothing to open | Instantly | Chips take toolbar space |
The frames below are the live Transactions page, one per concept, with the filter already open. They are clickable — tick "Not tagged" inside a frame and watch the list, the totals and the surplus banner change. Open one full size with the link on its card.
The panel we ship today, cleaned up: one scroll area instead of two, a count beside every row, and "Not tagged" pinned at the top of Tags above a divider. A footer that stays put holds "Clear all" and "Show 23".
Good: fastest to build — it is the same component with the nesting removed. Nothing new to learn.
Bad: a user with 30 tags and 10 accounts still scrolls a long way. It does not really fix "crowded".
The panel opens as three short rows — Tags, Bank accounts, Options — and each row says what it is currently set to ("Tags · Not tagged", "Bank accounts · 2 of 6"). Only one group opens at a time, so a scroll area never sits inside another one.
Open with the Tags group expanded: see it with tags showing ↗
Good: short panel, no nested scrolling, filters still apply instantly, and the list behind it stays visible. It is a contained refactor of the same component.
Bad: one extra click to reach a tag. Someone who filters by tag all day will feel that.
A proper window: filter names down the left, their values on the right. Choices are a draft — "Cancel" puts everything back, "Show 23 transactions" commits. This is the layout that still works when we add amount, merchant, category, entity or "needs review", and on a phone it becomes a full-screen sheet.
Good: calmest layout, most space, and the only one that clearly scales to more filters. Best mobile experience.
Bad: it covers the list, and it adds an Apply step — more clicks for the common case of ticking one tag.
Only C has Entities. Entities ship in production today, but their filter sits in a separate popover in the toolbar, away from every other filter — which is why people do not find it. C is the only concept with room to bring it in, so the order down the rail is Options → Tags → Bank accounts → Entities. It is Pro gated, so the normal free user sees a locked panel that explains what it does: free ↗ · Pro ↗
There is no filter panel at all. Each filter is its own small chip in the toolbar — "Not tagged 19", "Tags", "All accounts", "Options" — and the chip label shows what is currently chosen. Nothing is buried two levels deep, and "Not tagged" is one click from the page.
Good: you can see and undo the whole filter state without opening anything. Feels the fastest on desktop.
Bad: the chips eat the toolbar, which already holds search, dates and export. Mobile needs a different layout, so we would design twice.
The "no tag" control, up close
This is the new feature itself, separate from the panel layout. Four ways to word and place it — any of them can go inside any concept above. The checkbox is the real SortMe one.
U1 · Pinned at the top of the tag list (used in A, B and C above)
Sits where people already look for tags, above a divider so it reads as a special option rather than another tag.
Note: tick it and the tags below grey out. "No tag" and "has this tag" cannot both be true, so one clears the other instead of returning an empty list.
U2 · Three-way switch
Any / Specific / Not tagged. The most explicit version — the states cannot contradict each other, and the tag list only appears when it is needed.
Showing the 19 transactions with no tag.
No tag filter applied.
Cost: an extra row of controls in a panel we are trying to shrink.
U3 · A chip in the toolbar (used in D above)
One click from the page, no menu. Frames it as a job to do rather than a data state.
Cost: a permanent toolbar slot. Only worth it if the count is usually above zero — we could hide the chip when everything is tagged.
U4 · A prompt on the list
Not a filter — a way to discover one. The button sets the filter, so it pairs with U1 or U3.
19 transactions have no tag.
Tagging them makes your reports accurate.
Cost: another banner on a page that already has one. Show it only while the count is high, and let people dismiss it.
"Save these filters as my default"
The third addition. The user sets the filters they always want, presses one control, and from then on the Transactions page opens already filtered that way. It works the same in all four concepts — only the place it sits changes.
Where it sits: in A and B it is a row above the panel footer. In C it is a card at the foot of the left rail, and the Show button is what stores it — C keeps the filters as a draft, so a separate Save button could keep a set the user then cancels. In D it is its own chip. See the C version ↗
Setting it (A and B — a row above the panel footer)
Click it with filters on and it turns into the saved state, with a way to undo. Try it:
Note: the control is dead until at least one filter is on. An empty set is not a default, it is the normal page.
Arriving with it (all four concepts)
A user who lands on a pre-filtered page must be told why, in the place they already read filters. So the Filtered-by row leads with a coral pill:
Note: remove a chip and the pill is replaced by "Back to my default". Changing a filter must never destroy the saved set — otherwise people stop trusting the feature.
The wording — this is the part to decide
Same behaviour, three ways to say it. The prototype uses S1.
S1 · "Save as my default" (used in the prototype)
Short enough for a chip. "My" makes it personal, so nobody fears they are changing it for the whole household.
- Second press: Update my default
- Already saved: Saved as your default
- Undo: Remove my default
Risk: "default" is a slightly technical word.
S2 · "Always start with these filters"
Says exactly what will happen, with no jargon. Best for a user who has never met the idea before.
- Already saved: You always start with these
- Undo: Stop starting with these
Risk: too long for concept D's chip, and the undo wording gets clumsy.
S3 · "Remember these filters"
Warmest of the three and reads well as a checkbox in concept C's modal.
- Already saved: Remembered
- Undo: Forget these
Risk: does not say for how long. "Remember" can read as "just for today".
Rules this action follows
- Saving always confirms with a toast — never a silent change.
- A saved default is always visible on the page, and always removable from it. Nobody should be stuck with a filtered list they cannot explain.
- An empty filter set cannot be saved.
- The date range is not saved — "last 7 days" means something different on every visit.
- The entity filter is not saved either. It is Pro and flag gated, so a free user's default must not depend on it.
What I would ship
- The feature you asked for: U1. "Not tagged" pinned at the top of the tag list, with a count. Small change in TransactionsFilter.tsx, plus a new flag on the transactions query in the backend — there is no untagged filter in the API today, so that work is needed whichever concept wins.
- For the crowding: B. Groups that start closed give the biggest improvement for the least risk. Filters still apply instantly, the list stays visible, and the nested scrolling is gone.
- Choose C instead if we plan to add more filters soon (amount, merchant, category, entity, needs-review). Then the window layout pays for itself and mobile gets a proper full-screen sheet. Going B now and C later means designing the panel twice.
- D is the nicest desktop feel but the worst fit for mobile, so it needs a second layout anyway. I would keep the idea in reserve.
- Saved default filters ride along with whichever concept wins, using the S1 wording ("Save as my default"). It is a small piece of UI but it needs storage: one saved filter set per user, read before the first list render. Date range and the Pro entity filter stay out of the saved set.
Rules all four follow: never a scroll area inside a scroll area · a closed group shows its current setting · applied filters appear as removable chips outside the panel · every value has a count · "Not tagged" sits above a divider, not in the list.
Concepts only — not production code. Data is hard-coded. The concept switcher inside each frame is a review tool and would be deleted before build.