Background
We've been discussing, in a few places now, potential improvements to how tickets flow between design to tech within our team, and how to handle the circumstance where, through discussion during design review, we arrive at changes that we have flagged that need to be made, either to the spec or to the code.

To help clarify this process going forward, we should draft a decision record which notes down our current thinking about how the design review process should proceed.

Tentatively, we've arrived at the below implicit reasoning:

• Developers work toward the spec that is included with the initial draft of the ticket
• If small changes are necessary, these should be made as part of the same ticket. We can include a definition of what "small changes" might mean as part of this record, but an example would be spacing differences such as 8px vs 10px
• If next steps are clear, and larger changes are required, we should spin this work out into a separate ticket
• If next steps are unclear, or bigger questions remain, we should make up a time-boxed spike ticket can help us to have the right discussions with design and choose a path forward

That said, we should look to clarify and codify these conditions in a bit more detail, and solicit discussion on them going forward.

User story
As a developer or designer contributing to Codex, I'd like to know how to handle changes and suggestions that are raised during the Design Review phase, so that we can work incrementally, continuing to evolve our library while also incorporating feedback from all sides.

Acceptance criteria

• ADR has been drafted concerning the Design Review workflow
• ADR incorporates a diagram/flowchart for easy reference