Rosa

You have identified the exact failure, and it has a well-established answer: do not validate before the input could reasonably be complete.

The email field is the clearest case. Every valid address passes through a long sequence of invalid states on the way to being typed. Showing an error during that sequence is not information, the user knows they have not finished, it is just noise, and worse, it trains people to ignore the error area entirely. By the time you have a real error to show, the red text has become furniture.

The standard pattern that avoids this:

• Validate on blur, when focus leaves the field. That is the earliest moment at which "incomplete" and "wrong" are distinguishable.
• Once a field has shown an error, re-validate on every keystroke. Now live feedback is genuinely helpful, because the user is trying to fix a specific thing and wants to know the instant they have.

That asymmetry is the whole trick. Late on the first error, immediate on every correction.

The two effects you are leaning on are well documented and worth naming separately, because they are not equally defensible.

Anchoring is that people judge a price against whatever numbers are nearby. A high option shifts the whole perceived scale, so the middle plan reads as cheaper than it would alone.

The compromise effect is that when uncertain, people avoid extremes and choose the middle. Adding an option above your target plan moves that plan from being the top choice to being the sensible one.

Both are real, both are used everywhere, and neither requires deceiving anybody. The important distinction is whether the extra option is a genuine offer. A real plan that a real customer would sometimes buy is a product decision. A plan constructed so that nobody could rationally choose it, deliberately worse value at a higher price, existing only to be rejected - is a decoy, and that is where most people put the line.

The functional argument for rounding at all is well established and worth separating from the argument about which kind of rounding.

Corners are visually noisy - a sharp corner is a high-contrast point that draws attention, and an interface full of them has attention scattered across every element boundary. Rounding reduces that, which is part of why rounded interfaces feel less busy. There is also a plausible claim that rounded shapes are read as friendlier and less threatening, which shows up consistently enough in preference studies to be worth knowing.

Between the two rounding styles, though, I have never seen a difference in any measure I care about. Nobody misses a button because its corner has a curvature discontinuity.

So: rounding is defensible functionally, the choice between roundings is defensible aesthetically, and being clear about which claim you are making is what will get you through the review.

The short answer from the usability literature is that almost no icon is reliably understood without a label, and the funnel is not one of the rare exceptions.

The exceptions are a very short list, earned over decades of near-universal use: the magnifier for search, the house for home, the printer, the envelope, the trash can. Even some of those degrade, the floppy disk for save is now an abstract symbol to people who have never seen the object.

The funnel is worse than average for a specific reason: it depends on a metaphor about pouring and separating that only makes sense once you already know what filtering is. Somebody who understands the concept recognises the icon immediately, and somebody who does not gets nothing from it. That is precisely backwards from what an icon is meant to do.

Your instinct about your own recognition is exactly right and is the single most common blind spot in icon decisions.

Five is genuinely enough for this kind of question. You are not measuring a rate, you are finding out whether the problem exists, and problems this basic show up immediately.

The rule that resolves almost all of this: label the buttons with the action they perform, never with yes, no, ok or cancel.

A user in a hurry reads the buttons before the message, and often instead of it. If the buttons say "Discard changes" and "Keep editing", the dialog is comprehensible with the body text unread. If they say OK and Cancel, the body text is load-bearing and you have made a reading comprehension test out of a mis-click.

So:

• Discard changes - destructive, so give it the destructive styling and do not make it the default.
• Keep editing, the safe option, and the one focus should land on.

Note that neither button contains the word cancel, which dissolves your two-cancels problem entirely. The word is genuinely ambiguous in this context: cancel the edit, or cancel the closing? Removing it is the fix.

One more cost that only shows up in testing: hover navigation destroys the ability to explore a menu.

People habitually run the pointer across a navigation bar reading the options before choosing. Under this pattern, reading the menu means visiting every section, and by the time they have looked at the choices they are three pages away from where they started with a polluted history.

That is the behaviour I would watch for if you have any doubt. It is not subtle and it happens within the first minute of anyone using it.

It is a real problem, though not usually a severe one, and it has a clean fix that does not require abandoning your brand colour.

The issue is that status and interaction are two different channels of meaning and you are sending both down the same wire. On a busy screen the eye scans for colour first, so a green button and a green status dot compete: is that thing clickable, is it working, or both?

The fix is to stop relying on hue to distinguish them and use form instead.

• Interactive elements are shapes you can press, filled, with a border, with a label.
• Status is a small dot, a badge, a pill, always accompanied by a word.

Once a status is always "● Running" and never a bare dot, the colour is decoration on top of information rather than the information itself. The collision stops mattering because the colour was not carrying the load.

The bus-bunching parallel is what makes this click. I had assumed the controller was just naive, when actually even spacing is unstable under any simple rule.

From watching people use both: the strongest argument for browser tabs is that users already have a system for managing them.

People have habits: pinning, grouping, muting, a second window on another screen, tab search. All of that applies to your app for free if you use real tabs, and none of it applies if you draw your own. Power users in particular tend to be annoyed by in-app tabs precisely because their existing workflow stops working.

The counter-observation is that less experienced users sometimes lose track of which browser tab holds which part of your app, especially if your titles are not distinct. That is worth fixing directly: set a specific document title per section: rather than treating it as a reason to build your own tab strip.

The reasoning is that tabs are opened and closed constantly and windows are not, so the two actions have completely different frequencies.

A typical session involves opening and closing dozens of tabs. Adding a confirmation to that would mean dozens of interruptions per session to protect against an occasional mistake, and a dialog that appears that often stops being read within a day. You would train people to dismiss it reflexively, at which point it protects nothing and costs everything.

Closing a window is rarer and destroys more, so the ratio flips and a confirmation earns its place.

This is the general principle behind when to confirm anything: the cost of a confirmation is paid on every correct action, and the benefit is collected only on incorrect ones. Frequent actions should almost never confirm.