@Adoubleagent I'm not following?
X needs to be implemented for Y reason.
Y is the criteria, and may have requirements/constraints.
The request should contain what/why/how it should (and shouldn't look).
This permits testing as the work is done, for compliance.
>>>

@Adoubleagent >>>
This applies whether it's implementing a code change
(such as inserting hreflang),
or a design change
(such as altering fonts/contrast),
or adding a new widget
(such as a product-finder feature with multiple selects).
These should be conceived, designed and created ...
>>>

@Adoubleagent >>>
...
a) from a specific set of requirements
b) with an understanding of the use-case
c) knowledge/experience of the interactions etc.
If a "widget" is made to spec,
and there are issues with it's functionality and/or usage,
then someone (or several), somewhere screwed up

@Adoubleagent >>>
Either the spec was poor/inferior/lacking,
and/or
those creating it lacked the experience/understanding of what was being requested,
and/or
people weren't testing as they went along.
Processes like dry/empty walk throughs and prototyping are to avoid later errors.
>>>

@Adoubleagent >>>
QAs etc. are there to make sure the specs were met
(the specs being based on standards, and the EWTs/Proto's).
Pairing/Grouping ...
... during ideation - great (seldom done).
... during drafting - fine (should be done).
... for production - shouldn't be needed.