I enjoyed thinking about how Figma engineers feedback with engineering critical hits.
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".
Yea agreed. I just wanted to find out what an "eng crit" was and why Figma enjoyed using them. Just couldn't get through the fluff to anything of substance in time, gave up.
Here's what Kagi Universal Summarizer has to say about it:
- 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.
Probably could've made this slightly earlier, but it's in the second paragraph:
> 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.
It's actually short for "critique" and it comes from the world of art and design. A crit is a standard practice in which artists/designers get together to share their work in progress and give each other feedback, both positive and negative. It's a big part of design school.
> We’ve been thinking a lot as a team about how to bring AI into Figma and FigJam
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?
True. But when a technical capability comes along that makes it possible to get a computer to interact with unstructured human input in ways that would have been impossible to even approach a few years ago, it’s worth having a think about how they could be used in your product.
Every tool that I use that doesn't have AI embedded just feels clunky. Any repetitive or predictive task that I have to do should have the option of being automated.
Honestly tired of being told to use AI in Figjam, tried it once, it sucked. Also tired of turning off Figjam subscriptions that keep getting activated every time one person invites everyone to a figjam document or whatever is causing it to be switched on...
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.
Very clever and sneaky how they positioned "Dev Mode", think I'm the only person on my team who realizes it's a new thing and not just what's always been there and that it also costs extra.
Crits are great when there’s enough substance to do them regularly. If you fall off the cadence or have very little every meeting, it is a huge waste of time. In our case we tried it, but now resorted to async crits where there’s a set of reviewers and a date to be reviewed by, and people do it at their own cadence. It works for us in a reasonably sized team/org, but may not work for everyone.
Still fighting with the CTO on letting people other than him do code reviews. We don't do retrospectives and code reviews also take months. I also have to fill out a change request form (CRF) that has the git hash, list of files modified, and many other useless and redundant fields that are required.
Can't you have normal peer review with the rest of the team in lower level branches? Have everything work out as "normal" with PRs and whatnot, then when you want to merge develop into master or whatever, then do the CRF and CTO review?
It's a mix of ego and people not knowing what they are doing. I had to fight my first month just to get code into BitBucket. Before that, it was a server in rackspace you pushed to as the root user.
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.
>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.
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.
> Why would anyone review a design/ architecture after it's already been built?
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.
Or in my world, "We skated around the security/risk review by claiming it is a low-risk application [no PII data, not customer facing, only a PoC, etc], but now we're doing all of those things. The auditors caught on to us and are saying we have to have a review by security. It's already in production so we're not changing a thing. You guys figure out how to make the auditors happy since we won't be held accountable.". Good times.
A lot of "agile" (in quotes because a lot of them are not meaningfully agile) shops have used "agile" as an excuse to ditch a whole lot of the upfront design and review process.
A substantial number of them subsequently end up "inventing" these processes all over.
I second that they should be proud of this, it is the way it should be done. However in my experience it is not that rare. If you work around capable engineers such process always happens by itself, IME, because they all want ideas and suggestions as early as possible. It results in a better product and more maintainable system if peers share their experience, and 1-2 hour initial meetings are great for this. As are brainstorming sessions for overcoming challenges along the way.
A lot can change between initial design and release. It's useful to consider the product as built and not only as first envisioned. Typically the design review focuses on the overall approach and placement (new services, use / non-use of existing platforms) while the launch-gating review focuses on reliability.
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.
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 :)
especially when it was by your boss the owner while they were on a plane flight. I got a few of these over the years. One was the vacation time thing. It was 80% done. Was written originally in rails in like 4 hours (flight from LA to STL). I think we spent about 4 engineer years before we worked out all of the edge cases. Thanks for all of the paid work Steve E!
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.
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.
Design review 'should' be a process that overlaps with the technical review. In other meanings, not isolated from the org. And that overlap 'should' overlap multiple times with the technical review , not just once, at the end nor just at the beginning (shift in priorities, new team new people, etc).
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.
I'm excited to see this title. I interviewed Greg Wilson recently and he had a lot to say on this topic, of taking ideas from other fields and improving our abilities to read and critique code and architectures.
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.
One tricky area of feedback culture is the question of "is the person open to feedback right now?".
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.
I liked the points about bringing something early to the group and being comfortable with a half-baked ideas (provided it didn't take 2 weeks to write a couple of paragraphs for your design). Started off with some good insights, then pushed into the whole, "use FigJam, it worked for us"... Sucks, because it was shaping up to be a pretty good article, but instead we got an ad.
Design by committee (aka, technical design reviews or whatever the hell "crits" means) is one of the most wasteful practices in software development except, probably, for very junior developers. I always see many technical managers make off-the-cuff remarks about technical designs in those meeting without really understanding what they are saying. And the poor developers feel obligated to address those "issues", which always result in poorer and over engineered solutions.
Sounds like those technical managers, and the developers who aren’t able to engage, are the wasteful ones. Design review is just highlighting organisation failures elsewhere.
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.
The eng director at my current company does a good job of mitigating this. He'll often give remarks in our technical docs, but always prefaces it with "this is a bike shedding comment but.." etc etc. Always makes it clear that we're free to ignore his input if he's missing necessary context.
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.
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."
86 comments
[ 2.8 ms ] story [ 148 ms ] threadWhile 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:
but seems broken, because returns:https://www.figma.com/blog/design-critiques-at-figma/
- 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.
Additionally, they’ve formalized activities that happens organically in most teams and seem convinced they’ve done something novel.
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.
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.
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.
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.
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.
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.
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."