zlacker

>>emilsj+(OP)
As a developer, the "one big bulletin board" visual model that Figma promotes is one of the worst steps backwards in UX I have ever had to deal with. I am constantly zooming in and out and scrolling around trying to find anything. I hate it so much.

>>bgribb+9V
We use figma quite extensively as a reference for our current project. The disgners constantly move stuff around, so the links to them, in tasks, break and point to nothing. Which is a major pain in the ass indeed.

So yeah, 100% agree that the "big bulletin approach" is a negative.

>>Akrony+Ze1
I've completely reneged on linking to figma in individual tasks.

I take screenshots of the state of figma at the time we all agreed that "this is it" (or close enough to what we'll implement). Sure I'll leave a link in the epic to the figma "bulletin board" for that feature so that people can find it and look around. But that's it. We're also never gonna implement exactly what's shown in figma (or said screenshots) either because it would take forever to get the designers to actually adjust everything to look like it does in product.

They can never seem to get the look to match what our standard UI library looks like. Which is a shame because every new developer always tries to match what the design shows instead of sticking with the standard library. Honestly, the best thing would be if figma wasn't used at all and the designers just used black and white lines and boxes and focus on good UX instead of pixel perfect UI designs.

>>tharku+sm1
For us, figma has the final say in looks. So, it's actually a benefit that the designers can change it afterwards, as it is refined. They still have no incentives to keep the links up to date, though.

>>Akrony+Qm1
Being able to change things as design is still in flow is great, agreed. Once something is agreed upon the ability to change things without notice is really bad, especially if you're expected to follow the design as it has "final say". You go an implement something on Monday based on designs and show it to stakeholders on Tuesday. They compare with the figma board and flogg you because it looks nothing like it. Ugh! (yes that's also a process failure but absent better processes I make my own process that doesn't get me flogged ;) )

>>tharku+Un1
That sounds like an opportunity to improve on collaboration (i.e. people talking, notifying each other) as well as trust ("compare with the figma board and flogg you because it looks nothing like it")

For instance, if something is agreed upon and a designer changes it afterwards, they could simply give you a heads up that they intend to do so with context so the two of you can discuss.

People > process.

>>andsoi+mz1
They could. They don't. It may not even be their fault. They don't know. They just change things. They live in their world. You tell them, they are sympathetic, apologize, vow to do better next time. They're in their world. They do it again.

The flogging still happens. Is that broken? Yes! Does it still happen in too many companies? Yes! Is there an easy fix where you "trust but verify"? Yes! (as in, sure I trust they will notify me next time, which even if they actually do may be too late. So we made the process "figma is the 'working theory' and what we actually build will sorta look like that". Not every stakeholder may understand that but we sure will tell them when the flogging is about to start. (I say flogging, but in reality it's a gradient of course and while in some companies it will resemble an actual flogging quite closely in others it's more like what you describe. Not all countries and companies are as chill as some others ;))

>>tharku+IE1
> They live in their world.

That's why I really like working in true cross-functional teams. A Product Manager, a Product Designer and a handful of engineers. Do standups and all ceremonies together.

Ideally this "product team" is also empowered to solve a problem instead of tasked to build a feature.