How we engineer feedback at Figma with eng crits
figma.com
figma.com
At our company, technical design reviews happen before any work on a feature begins. I thought it's the case everywhere. Why would anyone review a design/ architecture after it's already been built?
It's also never just an approval here, most devs usually have something to say, and a technical design can be completely rewritten/rethought.
Also we don't formalize it too much, it'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.
Many reasons. They might not have known it was being built, or they might disapprove of how it's turned out compared to initial presentation, or there might have been a shift in priority making the current project not a good fit.
A substantial number of them subsequently end up "inventing" these processes all over.
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.
Just trying to complement what you said, not refute it :)
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.
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.
As said elsewhere, a lot can change between initial design and release so having multiple design/technical reviews 'should' be standard. But inherent in the design/technical reviews is time, resources, and culture which many many companies lack and/or don't include into budgets/project estimates/etc and/or a culture of development practices.
A shop might have a design team and a bunch of devs with probably a single person who actually understands how things are connected. Limited time and resources precludes a thorough design/technical review process But also consider that many companies willfully avoid 'wasting' developer time, setting up meetings, etc.
Turns out figma's design culture inspired change in their engineering culture to overlap their processes in a continuous development manner.
6.5.1 is probably where the CRF form came from.
Wow. I don't think I would have lasted even the first month there.
Sounds not healthy.
Everybody then gets what they want.
Because the CTO only does the code reviews, people create the PR and the CRF. Issue is because it takes so long, the CTO wants merge conflicts resolved before it's reviewed. Problem with that is, no one remembers the context a month (or longer later).
I have A LOT of spare time so I will often help out with doing reviews but because I'm not allowed to merge or deploy code, it's more of helping junior engineers write better code.
The article came off as if the company is run by designers, not engineers. While the engineers I know generally appreciate some feedback, they don't need much of it on engineering questions. UX and design, however - bring it on! So "eng crits" sound like... learning exercises for juniors? If it works for them, that's good, but I don't see myself sending my CV over, at least not based on this article.
Seems wildly counter-productive, as I'm guessing there will be a ton of merge conflicts.
While the technique seems good the article is so full of fluff it's borderline unreadable.
I'd like to think the engineers are delivering the critical hits rather than receiving them, but alas, it seems like of the two, only "receiving" critical hits would actually constitute "feedback".
The only page I found through kagi is:
http://www.blablameter.com/index.php
Your text: 14741 characters, 2454 words
BS Index :0.27
Your text shows some indications of 'BS'-English, but is still within an acceptable range.- Engineering crits at Figma are dedicated time for engineers to get feedback on work in progress, brainstorm approaches, and unblock each other early in the design process.
- They aim to find a middle ground between design critiques and technical reviews by focusing on exploration and feedback rather than approval.
- Running crits in FigJam allows many people to provide feedback simultaneously in a collaborative way rather than taking turns.
- The format encourages parallel conversations through sticky notes rather than sequential or comment thread styles.
- Crits have become core to early, middle, and sometimes late phases of technical design work at Figma.
- Engineers are asked to prepare by creating a FigJam file summarizing their design for quick feedback.
- Feedback is led by suggestions rather than mandates to encourage many perspectives.
- Crits help focus on specific challenges by bringing in relevant experts.
- The overall process aims to accelerate work by getting feedback earlier compared to later technical reviews.
> This was the genesis of Figma’s engineering critiques, dedicated time for the engineering team to brainstorm novel approaches to technical problems, get feedback on existing work, and unblock each other.
i hate how we're not even hiding the fact that we're just looking for excuses to use AI everywhere at this point...
do Figma and FigJam really need AI to solve their problems?? can't the AI use-cases in Figma/FigJam be implemented as plugins? is it okay to not use AI in 2024?
If you're flush with cash, investigating potentially game changing technologies can be quite valuable.
Core Figma is a beautiful product but their tactics to try and milk more revenue out of us are increasingly gross or utterly un-interesting like Figjam.
The tool that surpasses Figma wont take this approach.
Insert the buzzword in your pitch deck, marketing materials, or job posts and you'll see an ROI increase.
Gotta ride the wave, especially to survive or thrive during this tech rut.
In particular, if I'm working more than 50 hours in a week - I stop being open to feedback unless that feedback is "this is how we reduce the workload.". I'll take feedback once things have settled. As is obvious, this makes the organization as a whole more rigid - but it's difficult to blame employees in this state. Since the recent tech contraction, I suspect many find themselves in similar boats.
Additionally, they’ve formalized activities that happens organically in most teams and seem convinced they’ve done something novel.
It's pure common sense. My previous company did not work that way, simply because they couldn't handle the casual nature. However, I have always worked that way, in my personal and non-profit stuff.
In fact, we're doing it right now, discussing upcoming changes to our next release of the app we've shipped.
"Common sense. So rare, it's a God damn superpower."
Here is the chatGPT summary of this one point from the interview, if you're interested:
Integrating Critique Methodologies Across Disciplines: Embrace critique methodologies from architecture, fine arts, and design to elevate software development. This multidisciplinary approach emphasizes the importance of learning from real-world examples, akin to portfolio reviews in fine arts, where developers present and review code as a form of art, focusing on elegance, maintainability, and design patterns.
Studio Class Setting for Software Design: Adopt the studio class critique format from architectural education for software development, creating an environment where developers learn to give and receive constructive feedback. This fosters a culture of continuous improvement, much like iterative design processes in the arts, refining code through feedback loops to achieve functional and aesthetic excellence.
Developing a Language for Software Architecture Critique: Construct a language and a collection of examples for nuanced software architecture discussion, inspired by how architecture and fine arts students analyze works. Incorporate critique vocabulary from the arts to articulate specific aspects of software design and development more clearly, enhancing the depth of evaluation and appreciation for software design.
Promoting Thoughtful, Effective, and Beautiful Code: This interdisciplinary critique approach promotes the development of thoughtful, effective, and beautiful code. By valuing aesthetics in code, much like in fine arts, and encouraging narrative and storytelling around design decisions, developers can achieve a deeper understanding of design decisions and trade-offs, leading to software that is not only functional but also elegant and user-centric.
Greg's approach was education-centric: having students critique each others code in classroom settings and review and read real world code.
I find the process to be very productive. Just the act of writing out a proposal (or multiple) I find very helpful for better understanding the problem and solutions.
Strongly agree. But this is not the same thing as a tech review.
> Design review is just highlighting organisation failures elsewhere.
I don't think it is an organizational failure necessarily; it is more of a power balance issue. Most (esp. junior) developers wouldn't dare ignore a VP's comments in a tech review.
Because ultimately eng management must be able to weigh in at points, so we're never going to get rid of that problem. The question is how to do it without wasting IC time.