zlacker

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+(OP)
And this M.O. would seem to make zero steps toward recognizing the tedium of their platform:

"By hovering and clicking around the Figma canvas, you can find and export all the information you need"

Because "hovering" over every shape or area in a screenful of design content to prospect for hidden goodies, then exporting them one by one, is a great way for developers to acquire a complete rundown of what they need to implement.

I guess I can't speak for all developers, but I don't want to dick around with an Advent calendar that's masquerading as a design document.

Meanwhile, has Figma fixed the absurd confusion that it presents in the UI between projects and teams? It seriously confuses those two things right there on the "home" page of your account.

And finally, for those who don't want to support Adobe's software-rental nonsense, there is an open-source alternative to Figma called Penpot: https://penpot.app

>>Akrony+(OP)
I suspect, that the main problem is inconsistency in the underlying mental model, because there’s multiple individuals doing that and/or over longer periods of time.

I can typically figure out a mental model, even if designed by someone else (assuming they are somewhat consistent), pretty well and fast. — But it’s the inconsistency, that screws things up for me.

>>Akrony+(OP)
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+t7
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+R7
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 ;) )

>>Akrony+(OP)
I feel like this is the UX designers version of “gives you enough rope to hang yourself with.”

>>tharku+t7
And I thought it was just my design colleagues who did this :/

>>Akrony+(OP)
My designers take their own snapshot by cloning their work and using versions in the names of things. Older things are not to be modified with few exceptions. It makes for a good linking experience on my end, but I don't know what that kind of maintenance is like for them.

>>tharku+V8
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.

>>Akrony+(OP)
Ugh yeah when designers change things after a client signs off and in the middle of implementation. It confuses everyone and no one remembers what was actually signed off.

>>andsoi+nk
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 ;))

>>supert+3b
Next week on HackerNews:

Figma, considered harmful.

>>tharku+t7
At a previous job me and my team (UX Design) were so well meshed with the developers that I could hand them a text outline of the page structure I wanted of our design system components and they could produce it with 90% accuracy. Afterwards I would sit with them at their desk and we’d work out the last 10% together - either things I hadn’t thought of or bits they weren’t sure how to implement. It was glorious and it’s still the highlight of my professional life.

Unfortunately that’s been the exception in my personal experience, so most of the time I have to produce pixel-perfect comps that leave nothing to the imagination.

>>tharku+Jp
> 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.

We can use your language and persuasive skills to effect change. That change might be better collaboration. That change might be the person gets fired because it, together with other behavioral patterns, are judged to yield poor outcomes. Outcomes that are not good enough.

>>Akrony+(OP)
Good product engineers just go with the flow - workflows with Figma is way up there, compared to without. Those folks were probably the early adopters, and they were much happier to work with designers now.

Minor design details tend to change and even if they are missed out, they get caught at some point - cost of dev rework is generally manageable.

Another big tool for bigger product teams has been component libraries (and corresponding Figma assets). That makes it all simpler.

>>Akrony+(OP)
For this reason we use Zeplin, where designs are easily shared and versioned. For both developers and clients.

>>andsoi+3z
It sounds like flogging may be a feature, not a bug, of this system.

>>balaji+TB
This is good, yes, but it requires that the team culture does not treat minor deviation from the Figma document as a bug or a failure of the developer. That mindset isn't always present, and it's not usually up to the product engineers themselves. It requires buy-in from the designers, product people, and managers.

>>tharku+t7
Yep, this is a problem that people have been working on in the Mechanical Drafting world for well over a hundred years.

I'm also surprised we don't see the utilization of some GD&T style language to specify design intent. (https://www.gdandtbasics.com/gdt-symbols/)

For the problem of:

"I have a design I would like produced. Please make it like this please."

I couldn't imagine giving a machinist or welder a drawing containing no annotations. (This would be something an intern does once and the shop calls them up to tell ask them questions about what they actually need for 45min. Probably sending them back to rework it)

Pulling from the mechanical world:

  * make 3d models (equivalent to HTML/CSS components)
  * put 3d models into an assembly (HTML components together on the page)
  * make variations of the assembly to show range of motion (variations on user activity)
  * make "drawings" that contain components that are broken down to the smallest practical level (this would map to: modal, tables)
    ** in software these are usually managed similarly to Spreadsheet tabs
    ** this would contain a reference to the 3d parts + dimensional annotations. This means updating the assembly/part geometry automatically updates the drawing
  * anytime significant changes are made, issue new "Revisions" of those "drawings" are committed, issued, and then sent to the shop
  * 3d modeling software has change management systems so you'll automatically know if your proposed changes to a 3d part will break a drawing or assembly that depends on it

>>nkrisc+iw
This is the ideal workflow that I would like to strive towards.

Unfortunately, the product designers don't seem to want to let go of Figma. I understand that this helps them think and organise the layout so perhaps it's not really a problem.

>>tharku+Jp
> 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.

>>NTARel+Cc
This is my method, especially because it shows how design will progress, with tight deadlines this becomes harder but I still consider it a very valuable way of proving work (only a minor designer though with freelancing)

I certainly can understand stand the move fast method of quickly changing things, when I'm doing concept work this makes more sense here.

Long term though, if you actually care about your work you should be making copies or different boards to show how and when you made some decisions. Especially mayor design changes.(Granted I could just be a bad designer that just can't come up with a better workflow)

>>andrub+VS4
Figma and Sketch are fine and necessary for design tasks. We still need to quickly conceptualize and iterate on design ideas, including creating comps for research purposes.

The missing link, often, is then formalizing the design in some form that both developers and designers can use.

At the job I mentioned in my anecdote, we had a guy who lead our design system team. He had string design experience and was also a front end developer. He acted as the interface between the dec Org and the design team to create and develop a component library that was actually used in production and documented on an internal site.

Devs had real code they could use and design could focus on future products and reducing existing things.