The page before CSS

Lay a billing page's obligations on the table before any styling happens: show the Pro plan, name the saved card, state the next charge, hand over invoices, allow a pause, allow deletion. The template answer is six equal cards, and it looks tidy in a mockup. It is also a page with no opinion — deleting an account and downloading a receipt sit there at identical weight, as if the user were equally likely, and equally welcome, to do either.

So before type, color, or border radius, the page needs an information argument. Plan and renewal date describe the subscription. Card and invoices belong to payment history, and pause and deletion change the account itself. One more fact sharpens everything: the saved card expires soon, which makes “Update card” the action this user probably came to perform.

Group, then rank#

The figure below walks the same content through three passes: an inventory that records everything without pretending the order is settled, then the three groups, then a ranking — the current plan as the page's loudest fact, the dominant action handed to the expiring card, deletion dropped below a boundary line.

Notice what did not happen: nothing left the inventory. Invoices stayed near the card without competing against the update button. Pause is still one click, but it no longer borrows deletion's severity, and the renewal date sits with the plan it qualifies instead of floating as a disconnected metric.

The part I like about settling this before CSS is that the grouping becomes falsifiable. If a user reads “Invoices” as part of account cancellation, the grouping failed, and no taste debate is required — just a fix. That is roughly what the W3C's cognitive-accessibility guidance asks a page to establish: clear purpose, familiar hierarchy, visible important actions, understandable boundaries. A component library cannot produce any of it from six settings records.

Hierarchy follows the likely task#

“Update card” belongs inside the payment region, right next to the evidence that makes it necessary. Its whole labeled surface should be clickable, and WCAG 2.2's target-size criterion puts a 24-by-24 CSS-pixel floor under most pointer targets. The invoices link can afford to be quiet, since downloading a receipt is optional and reversible.

Deletion runs that profile in reverse: rare, destructive, deserving of an explanation and a recovery policy. Making its button the brightest object on the page would confuse severity with priority. Distance and a section boundary keep it findable without letting it win the first glance or sit beside a routine payment control.

Only now does CSS get its turn, and it arrives with a job description instead of a blank canvas. Spacing preserves the three groups, type makes the plan and the payment problem scannable, and color may underline the expiring card as long as the words “expires soon” carry the fact on their own. At narrow widths, source order keeps subscription, payment, and account changes in that sequence.

Is the hierarchy right? I can't promise that — it is a design hypothesis, not a usability result. A product where invoice retrieval dominates should promote that link instead, and an account with no payment problem should lose the warning treatment entirely. The grouping earns its keep by making such swaps local: one region changes, and the page's argument stands.

In the final panel, “Visa ending 4242 · expires soon” sits directly above the black Update card button, and Delete account is a red text link at the bottom of Account changes, underneath all the routine work. The border radius can wait.