<story><title>How we engineer feedback at Figma with eng crits</title><url>https://www.figma.com/blog/how-we-run-eng-crits-at-figma/</url></story><parent_chain><item><author>kgeist</author><text>&amp;gt;Most engineering teams have some sort of approval process, often called a technical review, which is usually reserved for the later stages in a project. The problem with late-stage technical reviews is that when they happen too late, like when a direction or design has already been built out, they can lead to launch-blocking feedback.&lt;p&gt;At our company, technical design reviews happen before any work on a feature begins. I thought it&amp;#x27;s the case everywhere. Why would anyone review a design&amp;#x2F; architecture after it&amp;#x27;s already been built?&lt;p&gt;It&amp;#x27;s also never just an approval here, most devs usually have something to say, and a technical design can be completely rewritten&amp;#x2F;rethought.&lt;p&gt;Also we don&amp;#x27;t formalize it too much, it&amp;#x27;s just a few folks in an informal setting discussing diagrams for 1-2 hours. In the end we decide if it looks good enough after all the tweaks, or we need another session.</text></item></parent_chain><comment><author>linkjuice4all</author><text>I used to develop apps and websites in the pharma space. It’s a heavily regulated field that requires submitting wireframes and functional specs to the FDA for compliance purposes.&lt;p&gt;This ended up creating a huge waterfall before any code was written and usually locked in the requirements - but the devs and designers had their guardrails and specifications so they could both go off on their merry way for a couple of months.&lt;p&gt;I was surprised how alien this process was when getting into start up’s but there’s obviously a middle ground of light wireframes and review before you find out all of the horrible details that weren’t covered by the individual teams.</text></comment>
<story><title>How we engineer feedback at Figma with eng crits</title><url>https://www.figma.com/blog/how-we-run-eng-crits-at-figma/</url></story><parent_chain><item><author>kgeist</author><text>&amp;gt;Most engineering teams have some sort of approval process, often called a technical review, which is usually reserved for the later stages in a project. The problem with late-stage technical reviews is that when they happen too late, like when a direction or design has already been built out, they can lead to launch-blocking feedback.&lt;p&gt;At our company, technical design reviews happen before any work on a feature begins. I thought it&amp;#x27;s the case everywhere. Why would anyone review a design&amp;#x2F; architecture after it&amp;#x27;s already been built?&lt;p&gt;It&amp;#x27;s also never just an approval here, most devs usually have something to say, and a technical design can be completely rewritten&amp;#x2F;rethought.&lt;p&gt;Also we don&amp;#x27;t formalize it too much, it&amp;#x27;s just a few folks in an informal setting discussing diagrams for 1-2 hours. In the end we decide if it looks good enough after all the tweaks, or we need another session.</text></item></parent_chain><comment><author>corytheboyd</author><text>Agree that serious review too late is very annoying for all involved. Reviewers are unhappy they have to reject, implementers are unhappy to have their work rejected, and product folk are unhappy that their feature is delayed.&lt;p&gt;There’s a happy medium, when necessary, where building a light proof of concept before engaging in design review unearths unknowns or other such things that you can’t get from a purely theoretical design session.&lt;p&gt;Just trying to complement what you said, not refute it :)</text></comment>