How to Support a Technical Recommendation with Evidence

A shopping-cart quantity control feels slow. A developer proposes an optimistic update: change the visible quantity immediately, then reconcile it when the server responds. The proposal is plausible. It may make the interaction feel faster. But is it the right change?

Perhaps the browser is slow to paint any feedback. Perhaps the server takes time to recalculate totals. Perhaps the user simply has no indication that an update is underway. And perhaps the server sometimes rejects quantities or returns new prices, making an optimistic total difficult to communicate honestly.

All four possibilities could produce a similar complaint. They do not support the same recommendation.

My experience working with established e-commerce frontends has made me interested in this difference between a solution that sounds technically reasonable and one that has been justified for the system in front of us. The cart example is hypothetical, not a client implementation, production incident, or measured result. The method is the point: how should an engineer make a recommendation that other people can inspect, challenge, and act on?

A technical recommendation contains more than one claim

“We should use optimistic updates because the cart is slow” compresses several distinct claims into one sentence. It assumes that the delay is material to users, that waiting for server confirmation causes it, that immediate speculative state will improve the experience, and that the new failure-handling complexity is acceptable.

A demonstration of a slow interaction establishes only part of that argument. Even a convincing performance trace does not, on its own, establish whether optimistic state is a better investment than faster rendering, clearer pending feedback, or a service-side improvement.

I find it useful to separate four questions: What behavior have we observed? What explanations fit that observation? What alternatives could improve it? And what would we accept as evidence that the selected change worked without causing more consequential problems?

These questions are related, but each requires its own reasoning. The recommendation becomes stronger when a reviewer can see where evidence ends and judgment begins.

Measure the outcome people care about, not only the available metric

For the hypothetical cart, “make quantity changes faster” is still ambiguous. A shopper may care about seeing that a click was registered immediately, knowing when a change is saved, or trusting that the displayed total is correct. Those outcomes need different checks.

Interaction to Next Paint (INP) measures responsiveness through the browser’s next paint after a user interaction. As web.dev explains, it is not designed to measure all the later effects of asynchronous operations such as a network response and subsequent updates. A good INP result would not prove that the cart’s revised quantity was accepted or that its total was correct.

For this decision, I would examine at least two separate intervals: the time from user action to visible acknowledgment, and the time from that action to a confirmed, consistent cart state. I would also examine whether rejections, repeated clicks, and price or availability corrections occur, because those determine the risk introduced by speculative updates.

The browser’s Performance API supports custom marks and measures, which can help separate parts of the client-side interaction. Those measurements should be paired with appropriate request and server observations. A browser timing cannot, by itself, tell us why a backend operation took time; a backend timing cannot tell us whether users understood the feedback.

Match the evidence to the claim it can actually support

A useful investigation does not collect every metric available. It seeks the smallest set of observations that can distinguish the plausible explanations and inform the decision.

This table is deliberately stricter than an issue list. It distinguishes a signal from the conclusion people may be tempted to draw from it. A single recording on one laptop can establish that a delay was reproducible in those conditions; it cannot establish its prevalence. An error log can establish a rejected update; it cannot tell us whether the customer understood the resulting screen.

Evidence also has a boundary in time and context. A result from an isolated development build may not represent a release with real network conditions, production-sized carts, and other scripts. If a recommendation depends on performance, the test conditions need to be representative enough for the decision being made.

Compare credible alternatives before advocating your preferred one

An optimistic UI is one option. It is not the default winner merely because it produces an immediate visual change. Its main trade-off is that the interface shows a temporary state before the system responsible for the cart has confirmed it.

For a quantity change, that can affect more than the number in a selector. Totals, promotions, stock limits, shipping conditions, and rapid successive updates may all depend on the server’s accepted cart. A speculative display needs a defined relationship to those confirmed values and a recovery path when the server disagrees.

React provides useOptimistic for showing temporary state while an Action is in progress. That is an implementation facility, not a decision rule. The existence of a convenient API does not tell us whether the product’s business constraints justify using it for a particular cart operation.

The options are not mutually exclusive. Immediate pending feedback may be useful even if the underlying service is later improved. An optimistic quantity selector might be appropriate while totals remain visibly pending rather than pretending they are final. The choice depends on the contract the business wants to make with the shopper and the evidence about what is actually delayed.

Make the initial recommendation conditional

Without evidence that the server wait is the main cause of the experienced delay, I would not begin by recommending a speculative cart state. My initial recommendation for this illustrative situation would be narrower: establish an immediate, accessible acknowledgment of the action; measure the path to server-confirmed state; and verify how the cart behaves when an update is rejected or superseded.

This is a recommendation to reduce uncertainty with a low-commitment improvement, not a claim that optimistic updates are wrong. If the evidence shows that rendering is blocking the first response, prioritize that rendering problem. If the dominant wait is service-side, pursue the relevant service work or evaluate a temporary optimistic display against the real failure cases.

The key is to say what would cause the recommendation to change. A proposal that cannot be revised by evidence is closer to a preference than a technical argument.

The same discipline becomes particularly important in architecture reviews: Reviewing a Technical Proposal: Questions That Expose Hidden Risk turns unresolved assumptions into questions a decision-maker can actually test.

Look for the strongest evidence against your own proposal

Suppose a team wants optimistic updates. The most useful review question may be: What result would make this approach unacceptable? A frequent pattern of server-corrected quantities could make the cart look unstable. Rapid taps could create competing pending requests. A failed update could leave a total that no longer matches the accepted cart. Those are not reasons to reject the idea automatically; they are conditions to examine before promising its benefit.

The alternative proposal also needs the same scrutiny. If a pending indicator appears instantly but the user still cannot tell whether a change was saved, the feedback improvement may not solve the actual frustration. If an API optimization improves response timing in a benchmark but the UI remains blocked by main-thread work, the visible experience may barely change.

Considering evidence that could defeat a recommendation is not a sign of weak confidence. It shows that the decision is based on observable conditions rather than attachment to a particular solution.

Verify the business behavior as well as the performance change

A technically faster interaction is not a successful improvement if the cart becomes less dependable. Verification should cover the quantity and totals that the server actually accepted, stock or limit rejections, rapid successive changes, and the behavior shown after an error or interruption.

The same applies to accessibility. Waiting, success, and error feedback should be meaningful to people using assistive technology. The W3C’s status-message guidance explains how important updates can be conveyed without unnecessarily moving focus. A visible spinner is not proof that the change of state was communicated to everyone.

After any change, compare the relevant timings under comparable conditions, but do not stop there. Repeat the complete cart task and confirm that the accepted outcome, visible state, and feedback stay consistent. Where a meaningful before-and-after user outcome can be observed, consider it; avoid inventing a conversion uplift or treating a better laboratory number as proof of business value.

Write the recommendation so someone else can challenge it

A long report is rarely necessary. For many changes, a concise decision note can preserve the evidence and reasoning. Here is how I would frame the hypothetical cart issue before the investigation is complete:

Proposed next step: Make quantity changes visibly pending as soon as the action begins, while keeping totals tied to server-confirmed cart state. Measure action-to-feedback and action-to-confirmation separately, then test rejection and rapid-change behavior. Do not commit to optimistic totals yet. Revisit that option if the evidence shows the server wait dominates the experience and the reconciliation rules can be made understandable and safe.

This note does not pretend the investigation has already produced a result. It names an action, its scope, the evidence still needed, and a condition that could change the decision. It gives the next reviewer something more useful than “this feels like the best architecture.”

For consequential choices, a short architecture decision record can preserve the alternatives, decision, and trade-offs for people who join the project later. Martin Fowler’s discussion of architecture decision records emphasizes recording the context and significant consequences, rather than treating the decision as an unexplained result. The format should fit the importance of the choice; not every small UI adjustment needs a formal record.

Evidence makes a recommendation accountable, not infallible

Engineering decisions are often made before every uncertainty can be removed. The goal is not to demand a perfect experiment for every request. It is to make the most important assumptions visible, seek evidence where it could change the choice, and avoid claiming a stronger conclusion than the observations support.

A good technical recommendation tells its audience what is wrong, why a proposed action is proportionate, which alternatives were considered, and what would make the team reconsider. It also defines how success will be recognized beyond the narrow metric that made the problem visible.

The result is not just a more persuasive proposal. It is a decision the team can revisit intelligently when the software, the evidence, or the business needs change.