Consider a table layout as an alternative to cards
Question
The nested card approach raises a question: why was it chosen over a table? For a list of payments — dense, repetitive information — a table could be easier to scan and compare. Would be useful to understand the reasoning before committing to cards.
Cards make too few items visible at once
Suggestion
With one payment per month per project, a user with 3 projects sees roughly 3 cards at a time — even on a large screen. The layout needs to support scanning many items quickly.
Two search fields cause decision anxiety
Suggestion
Having two separate search inputs forces the user to decide where to type first. Consolidate into a single search field with a criteria selector (dropdown to pick: project name, invoice number, etc.).
Status filter order should reflect urgency
Suggestion
The current order surfaces Paid early — the status users care about least. Reorder so Overdue comes first and Paid last.
Date filter has no label
Unclear
There's a date range filter with no label. It's unclear whether it filters on invoiced date, payment due date, or something else.
Project chips don't scale for long names
Suggestion
Project names — especially German ones — can be very long. Showing 12+ as chips becomes hard to scan. An autocomplete dropdown would be easier to use when the list grows.
Project name shouldn't be the most prominent title
Suggestion
The project name repeats across every card and isn't the most useful information. The date or milestone title would be more meaningful as the lead. Key info users need: invoice date, payment due date, status, amount.
VL's own payout is missing from the nested list
Unclear
The expanded card shows individual payouts but omits the Vico Lead's own payout. Since the VL's amount is visible at the top level, it's confusing that it doesn't appear in the breakdown. Conceptually it's also an individual payout and should be in the list.
"VL payment" label is unclear and too informal
Unclear
The label VL payment is ambiguous and sounds too casual. Use a clearer, more descriptive label that specifies what this payment actually refers to.
No pagination visible
Question
It's unclear how the list behaves with 50+ payments. Pagination, infinite scroll, or load-more should be shown so reviewers can evaluate whether the approach works at scale.
"Dunning" is shown with no explanation
Unclear
The status Dunning appears in red but is unexplained. What does it mean? Is there an action required? Who is doing the dunning? If it's system-driven, the user should know; if it requires action, that should be clear.
Status filter options don't match card statuses
Data
Statuses shown in the filter (e.g. Expecting payment) don't appear on the cards, and vice versa. This makes it impossible to test the filter and indicates the prototype's status model isn't consistent.
Transfer receipt visible on an unpaid item
Data
A transfer receipt appears on a card where the payment status indicates it hasn't been paid. These states are logically contradictory — a receipt should only appear once payment is confirmed.
Credit note math is hard to follow
Unclear
Multiple amount fields — Total Gross Invoice, Gross Amount, New Invoice, Credited Amount — appear without making the relationships between them clear. It's not obvious what's being deducted from what. Credit notes appearing everywhere also isn't a typical case, making it harder to evaluate the general layout.
Partially paid state gives no explanation
Unclear
When some members are paid and others not, there's no explanation of why. As a Vico Lead: is this expected? A system issue? Is action required? If staged payouts are valid, that should be communicated.
Employee payment mapping may not reflect reality
Question
In practice, employees are paid by the Vico Lead directly — the platform payment goes to the VL, not to each team member individually. The nested payout view implies per-member payments, which may not reflect how money actually flows.