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
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