QA and design review are different passes
Asking one person to check both correctness and craft gets you neither. The two passes look for different things and should not share a queue.
A common setup: the designer reviews the build, files whatever they notice, and QA does the same against the ticket. Both lists land in the same column, and within a month the developers cannot tell a broken flow from a four pixel gap.
The two passes are both worth having. Merging them is what causes the damage.
They ask different questions
QA asks whether the thing does what it promised. Design review asks whether it feels like the product. A button that saves the wrong record and a button with the wrong corner radius are both defects, and treating them as one queue means the second one competes with the first for a developer's morning.
Correctness has a right answer. Craft has an opinion, and it is somebody's job to hold it.
Run them in order
Design review after QA, not before, and never at the same time.
A build with a broken save flow is not ready to be judged on spacing, and reviewing it that way produces a list of visual notes against a screen that is about to change. Fix what is wrong first, then look at what is unpolished.
Keep them in separate lists
Two labels is enough. What matters is that a developer can open one list and see only things that are broken, and open the other and see only things that could be better.
That also fixes the argument nobody enjoys, which is whether a visual issue counts as a bug. It does not have to. It counts as a design note, it gets its own priority, and it stops being something to negotiate about at release time.
Who does which
QA runs the correctness pass, and it should be someone who did not build the feature. Design review belongs to whoever owns the design, and it does not get delegated to QA as a favour, because a tester without the design context reports what looks odd rather than what is off-system.
If your team has no designer, the pass still exists. It becomes one person's opinion, written down as notes rather than as bugs, and that is a fair trade.
Our reporting cadence covers which list lands where. The rule underneath it is the one above: a developer should never have to sort a broken flow out of a pile of spacing notes.