The new data is inconvenient
A product name is forty characters longer. A validation message wraps to three lines. The total grows from 9.00 to 123456.78. A robust interface accommodates real content, not only the original screenshot.
Use a semantic description list or a table for amounts and labels, depending on the relationship. Keep currency/unit meaning visible. Our exercise uses fictional units, so do not add a real currency symbol without changing the contract.
Build a layout that can yield
Start with one column. Add side-by-side panels only when the content fits. A useful grid pattern is grid-template-columns: repeat(auto-fit, minmax(min(100%, 20rem), 1fr)). Set min-width: 0 on children that need to shrink and allow long names to wrap. Keep amounts aligned using font-variant-numeric: tabular-nums; this changes presentation, not stored values.
Apply these decisions to your own stylesheet, then inspect them. A CSS pattern is a hypothesis until tested with the actual content.
Define what feels slow
A 1200 ms server delay is not a slow arithmetic function. Rewriting the calculator will not fix it. A delayed loading message might instead mean you update the DOM only after awaiting the request. Repeated listeners might make one click perform several calculations.
Use the browser Performance and Network panels to distinguish waiting for data from executing JavaScript and updating layout. Start with a reproducible scenario and count meaningful events. Do not add debouncing simply because a tutorial includes it: the baseline form calculates on submit, so it does not need to delay every keystroke.
If you later add live search, debounce reduces request frequency; generation checks still protect correctness. Debouncing alone cannot stop an older in-flight response from winning.
Verification matrix
| Constraint | Evidence |
|---|---|
| Narrow viewport | Actions and totals stay visible |
| Long name | Wraps without covering the amount |
| Error after success | Old total is hidden or clearly obsolete |
| Slow API | Loading appears before completion |
| Repeated visits | One action causes one handler invocation |
Independent change
Add twenty products to the fixture and inspect the page. Then try two hundred. Decide from evidence whether filtering, pagination or another layout is necessary. Document the point where usability suffers and why. Avoid claiming that a framework or memoization automatically solves a problem you have not measured.
Your deliverable is one before/after observation tied to a specific change, plus the domain tests showing presentation work did not alter prices.