The product and organization pages were assembled part by part and never arranged #20

New Issue

2026-09-21T07:18:07Z

cgalo5758 commented

2026-09-21 07:18:07 +00:00

The question

The product page and the organization page each gather everything known about one record on one URL. Their parts are now uniform: the same header, the same section boxes, the same record tables and forms. The arrangement is not, and was never designed. What earns a section of its own, what belongs on a child page, and where a form lives were each decided in the round that added them, and the product page reads as disorganized because of it. The organization page has the same shape and the same problem.

What depends on the answer

Which surfaces are rebuilt in the same round, since the answer applies to every page built the same way. Surveyed candidates, each with its own smell: the entitlement-set page repeats the product page's shape exactly, so whatever is decided applies to it; the org-types page is the one card-grid surface in the operator panel, with forms inside cards and a preview shown as an inline alert, where every sibling uses a table and a detail page; the billing hub is a wrapper over four sibling views behind pills, with a detail page only invoices have, a summary that also appears on the organization page, and a header that never names the view being shown; the grants page is a read-only ledger whose content overlaps the organization page's grant history and whose actions were removed, so whether it still earns a place in the rail has not been asked; the domains page is the densest one, with three disclosure sections, two tables and inline flows, and nobody has designed its reading order; the member pages predate every convention of the recent sweeps; and the integration pages grew from two eras. The people directory, the setup checklist and the validation page are not flagged.

Options known so far

One round that settles an arrangement rule and applies it to the two pages, with the surveyed surfaces following in order.
A rule per surface, decided where each is next worked on, accepting that they diverge in the meantime.

The member pages' entitlement section and the choice between tabs and pills are each their own entry, since both can be answered before the arrangement is.

Decided when

The design system states what earns a section, what moves to a child page and where a form lives on a record page, and the product and organization pages are rebuilt to it.

Migrated from status/issues.md at b7a0e15

## The question The product page and the organization page each gather everything known about one record on one URL. Their parts are now uniform: the same header, the same section boxes, the same record tables and forms. The arrangement is not, and was never designed. What earns a section of its own, what belongs on a child page, and where a form lives were each decided in the round that added them, and the product page reads as disorganized because of it. The organization page has the same shape and the same problem. ## What depends on the answer Which surfaces are rebuilt in the same round, since the answer applies to every page built the same way. Surveyed candidates, each with its own smell: the entitlement-set page repeats the product page's shape exactly, so whatever is decided applies to it; the org-types page is the one card-grid surface in the operator panel, with forms inside cards and a preview shown as an inline alert, where every sibling uses a table and a detail page; the billing hub is a wrapper over four sibling views behind pills, with a detail page only invoices have, a summary that also appears on the organization page, and a header that never names the view being shown; the grants page is a read-only ledger whose content overlaps the organization page's grant history and whose actions were removed, so whether it still earns a place in the rail has not been asked; the domains page is the densest one, with three disclosure sections, two tables and inline flows, and nobody has designed its reading order; the member pages predate every convention of the recent sweeps; and the integration pages grew from two eras. The people directory, the setup checklist and the validation page are not flagged. ## Options known so far - One round that settles an arrangement rule and applies it to the two pages, with the surveyed surfaces following in order. - A rule per surface, decided where each is next worked on, accepting that they diverge in the meantime. The member pages' entitlement section and the choice between tabs and pills are each their own entry, since both can be answered before the arrangement is. ## Decided when The design system states what earns a section, what moves to a child page and where a form lives on a record page, and the product and organization pages are rebuilt to it. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/operator-ui labels 2026-09-21 07:18:07 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#20