When Figma starts designing us

Exactly this. Thank you.

We need a Blender-like design tool specifically for product design. Using HTML/CSS for rendering so it covers most web needs and that usually more than encompasses native app-layout emulation. Open source, technical, and not expected to be picked up in a day or fully understood top-to-bottom by everyone.

The reason Figma is putting us into a design box is because it doesn't have all the CSS features that actually let you create incredible experiences.

Ive really warmed up to the lowercase-a "agile" way of working in this way. Earlier in my career I just wanted design to have everything fleshed out and ready to go, that was their "job". I’ve now seen that fail multiple times.

It can be hard to communicate it to coworkers sometimes, but a lot of this would be much smoother if we all understood our jobs as making the product we ship. The design isn’t a product and nor is the repo. The designer might hold the pencil, and I might hold the brush but we’re both working on the same canvas.

These are complaints about the designer you are working with and the deliverables they're choosing to give you, are they not?

Figma isn't/shouldn't be the arbiter of what's possible in the project, that's a major point of the article.

My role as a designer is to explore options and _then_ narrow down to a sensible solution (diamond-shaped process, etc etc). My developer colleague is concerned by the second part of that process, and I should make sure to provide her with consistency and sensible use of exceptions. That doesn't change my responsibilities to the exploratory part, and I can't exclude it from my consideration when choosing and critiquing tools.

I know it’s trite to just say “you aren’t holding it right!” when it comes to JIRA, but I do think there’s a sensible tool underneath layers of self-inflicted pain. (Self = Atlassian and its users)

User stories, when they’re actually a real problem a real user would need solved, are fine. If you start there, and figuring out how to solve that problem is open to anyone on the team, and you keep the complexity to a minimum (aka, just todo/inprogress/done statuses, and you only try to solve the problem in the story) it’s totally cromulent…

…for start ups who need to ship yesterday and have money to burn.

So IMO not like, the best way to do work, but to do something as fast as possible with people motivated by the problems you’re solving, I like it.

The author wishes for a specific workflow that is neither determined nor prevented by Figma. Our tools shape us, yes, but it’s the organization and leadership that actually has the power to create the workflow the author wants, not the tool.

There’s no tool that designers can use that will force organizations to adopt this preferred workflow.

The tools shape us, undeniably, but the agency lies with us. Blaming the tool misses the true story of who has the power to make the world you want.

And as a designer who has to contend with a design system and building consistent UI … this vision of sketch→code→ iterate is beautiful but does not work at scale. Is every feature meant to be a greenfield new idea maximizing my creativity? No. That’s not the job. The job is to create consistent elegant interfaces, and reusing components and tokens and utilizing auto layout is absolutely critical to ensure this. (Okay, I did it before Figma but it took 5x as long and was very difficult to mantain!)