zlacker

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+(OP)
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+o
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+(OP)
And I thought it was just my design colleagues who did this :/

>>tharku+s1
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+Uc
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+A3
Next week on HackerNews:

Figma, considered harmful.

>>tharku+(OP)
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+gi
> 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.

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

>>tharku+(OP)
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+Po
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+gi
> 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.

>>andrub+sL4
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.