8 ms·
How we engineer feedback at Figma with eng crits
- morbicer 3y agoI assume crit is a short for criticism/critic. While the technique seems good the article is so full of fluff it's borderline unreadable.
- nuz 3y agoThese articles are usually considered an ad for recruitment purposes and aren't really given much budget/time beyond that goal.
- jerf 3y agoI 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".
- rco8786 3y agoYea 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.
- madeofpalk 3y agoGiven what Figma is, I believe the phrase comes from 'design crit' which is more established in design circles.
- Etheryte 3y agoWhere's that corporate BS meter page someone linked to the other day? I bet this article would be off the charts.
- eurekin 3y agoI'd love to see that link! The only page I found through kagi is: http://www.blablameter.com/index.php but seems broken, because returns: 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.
- _puk 3y agoI was thinking critique, and it turns out to actually be linked in the article. https://www.figma.com/blog/design-critiques-at-figma/ https://www.figma.com/blog/design-critiques-at-figma/
- pants2 3y agoHere'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.
- neogodless 3y agoProbably 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.
- pimlottc 3y agoIt'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.
- dyingkneepad 3y agoThis is one of those links where my first thought is that it's gonna be something Rickroll-style with some image saying "figma balls" somehow.
- brandall10 3y agoThis just seems like an RFC with a touch of skeuomorphism?
- yellow_lead 3y agoSeems like they re-invented technical design reviews.
- trentnix 3y agoThat was my thought as well. Additionally, they’ve formalized activities that happens organically in most teams and seem convinced they’ve done something novel.
- nasso_dev 3y ago> 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?
- solfox 3y agoWhy wouldn't they be exploring ways to incorporate a new technology into their product?
- mavamaarten 3y agoBecause incorporating new technologies into a product is not a goal on its own.
- jameshart 3y agoTrue. 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.
- itishappy 3y agoDepends if you have a budget line for R&D. If you're flush with cash, investigating potentially game changing technologies can be quite valuable.
- unclad5968 3y agoTypically you would need a reason to justify spending resources on things.
- raziel2p 3y agoAgreed, that's why I'm trying to convince my team to ban brain storming sessions.
- darth_avocado 3y agoCrits 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.
- blastro 3y agoWas excited to learn something here and did not. Seems like a very normal technical review process. My team uses discovery trees for the same goal.
- morbicer 3y agoDiscovery trees look interesting. Sounds like a streamlined story-mapping. Do you have a good resource to learn more please?
- f1gm3nt 3y agoStill 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.
- pm90 3y agoThis sounds like the worst version of SOC controls.
- f1gm3nt 3y agoIt's all for "PCI Compliance" lol
- Brystephor 3y agoHow is it for PCI compliance? Which of the PCI DSS requirements outlines this?
- sibeliuss 3y agoYikes! How is this tolerated?
- 3y ago
- kgeist 3y ago>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.
- photonbucket 3y ago> 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.
- kjs3 3y agoOr 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.
- SilasX 3y agoA special case of, "I got all the glory for doing the easy part, you get to take the hard part."
- vidarh 3y agoA 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.
- adamgordonbell 3y agoI'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.
- lumost 3y agoOne 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.
- ramoneguru 3y agoI 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.
- fancyPantsZero 3y agoGot deep into interview with this company (3rd round) and they ghosted me. I’m starting to feel like I dodged a bullet
- beryilma 3y agoDesign 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.
- madeofpalk 3y agoSounds 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.
- beryilma 3y ago> Just the act of writing out a proposal... 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.
- deleted 3y ago[deleted]
- danielvaughn 3y agoThe 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.
- ChrisMarshallNY 3y agoI'm a bit sad that this is considered "unusual." 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."
- xbar 3y agoThe most significant thing I took from this blog was how happy I am that Figma is not going to be a part of Adobe.
- deleted 3y ago[deleted]
- Santos57 3y ago[dead]