[HN Gopher] How we engineer feedback at Figma with eng crits
___________________________________________________________________
How we engineer feedback at Figma with eng crits
Author : tomduncalf
Score : 98 points
Date : 2024-03-11 16:04 UTC (6 hours ago)
(HTM) web link (www.figma.com)
(TXT) w3m dump (www.figma.com)
| morbicer wrote:
| I 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 wrote:
| These articles are usually considered an ad for recruitment
| purposes and aren't really given much budget/time beyond that
| goal.
| drooby wrote:
| Essentially.. Hey everyone! We built this tool - FigJam - and
| we use it, and it's amazing and a game changer. (Please buy
| FigJam)
| layer8 wrote:
| They seem more like a deterrent for potential recruitees. ;)
| jerf wrote:
| 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".
| rco8786 wrote:
| 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.
| madeofpalk wrote:
| Given what Figma is, I believe the phrase comes from 'design
| crit' which is more established in design circles.
| Etheryte wrote:
| Where's that corporate BS meter page someone linked to the
| other day? I bet this article would be off the charts.
| eurekin wrote:
| I'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 wrote:
| I was thinking critique, and it turns out to actually be linked
| in the article.
|
| https://www.figma.com/blog/design-critiques-at-figma/
| pants2 wrote:
| 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.
| neogodless wrote:
| 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.
| dyingkneepad wrote:
| This 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.
| yellow_lead wrote:
| Seems like they re-invented technical design reviews.
| brandall10 wrote:
| This just seems like an RFC with a touch of skeuomorphism?
| nasso_dev wrote:
| > 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 wrote:
| Why _wouldn 't_ they be exploring ways to incorporate a new
| technology into their product?
| mavamaarten wrote:
| Because incorporating new technologies into a product is not
| a goal on its own.
| jameshart wrote:
| 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.
| itishappy wrote:
| Depends 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 wrote:
| Typically you would need a reason to justify spending
| resources on things.
| raziel2p wrote:
| Agreed, that's why I'm trying to convince my team to ban
| brain storming sessions.
| notimpotent wrote:
| 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.
| throwway120385 wrote:
| 30 years ago you would have just used a shell.
| whywhywhywhy wrote:
| 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.
| emptysea wrote:
| If you think Figjam is expensive, you should see their new
| dev mode pricing -- I'm sure they're making a mint!
| darth_avocado wrote:
| 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.
| blastro wrote:
| Was 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 wrote:
| Discovery trees look interesting. Sounds like a streamlined
| story-mapping. Do you have a good resource to learn more
| please?
| f1gm3nt wrote:
| 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.
| pm90 wrote:
| This sounds like the worst version of SOC controls.
| f1gm3nt wrote:
| It's all for "PCI Compliance" lol
| Brystephor wrote:
| How is it for PCI compliance? Which of the PCI DSS
| requirements outlines this?
| f1gm3nt wrote:
| Got me, first time I've ever had to fill out something
| like this
| brianwawok wrote:
| > code reviews also take months
|
| Wow. I don't think I would have lasted even the first month
| there.
|
| Sounds not healthy.
| f1gm3nt wrote:
| It's rough, I'm looking =)
| beAbU wrote:
| 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?
|
| Everybody then gets what they want.
| f1gm3nt wrote:
| 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.
| sibeliuss wrote:
| Yikes! How is this tolerated?
| njovin wrote:
| I don't think I know a single engineer that would tolerate
| working in this environment.
| seattle_spring wrote:
| Wait, based on the article and your name, are you talking about
| Figma?
| Solvency wrote:
| why is this being downvoted? I was wondering the exact same
| thing.
| ramon156 wrote:
| Never knew you could download comments! (sorry)
| sunnybeetroot wrote:
| No chance this is Figma
| bornfreddy wrote:
| Why not? It seems plausible to me.
|
| 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.
| sunnybeetroot wrote:
| There is another post that mentions PCI compliance, but I
| don't see how all of Figma falls under needing PCI
| compliance.
| bornfreddy wrote:
| Good point!
| 65 wrote:
| > code reviews also take months
|
| Seems wildly counter-productive, as I'm guessing there will be
| a ton of merge conflicts.
| danielvaughn wrote:
| If the job market was better I'd tell you to quit. That sounds
| awful, and wildly irresponsible behavior from a CTO.
| kgeist wrote:
| >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 wrote:
| > 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.
| vidarh wrote:
| 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.
| meaydinli wrote:
| Feel free to drop your company name here with pride, because
| that feels like a breath of fresh air.
| bornfreddy wrote:
| 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.
| closeparen wrote:
| 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.
| corytheboyd wrote:
| 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 :)
| adamgordonbell wrote:
| 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.
| lumost wrote:
| 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.
| ramoneguru wrote:
| 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.
| fancyPantsZero wrote:
| Got deep into interview with this company (3rd round) and they
| ghosted me. I'm starting to feel like I dodged a bullet
| beryilma wrote:
| 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.
| madeofpalk wrote:
| 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.
| beryilma wrote:
| > 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.
| danielvaughn wrote:
| 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.
| ChrisMarshallNY wrote:
| I'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 wrote:
| The most significant thing I took from this blog was how happy I
| am that Figma is not going to be a part of Adobe.
___________________________________________________________________
(page generated 2024-03-11 23:01 UTC)