When Figma starts designing us

I agree with the general sentiment—over-optimizing for design can both be a poor use of time and lead to less than ideal solutions.

I don't really agree that Figma is forcing designers into a box. The author feels like there's an ideal workflow—a quick sketch that gets translated into code. There's no ideal workflow. It completely depends on the delivery team.

That sketch to code flow probably works well with a small team that is used to working closely together. I've been working with most of the engineers on one of my delivery teams for five years. Frequently, I don't need designs at all! I can just write a JIRA card and because we are so used to working together many times they can pick up on the desired result.

Unfortunately, when the product org gets larger you get a lot of designers and engineers and delivery teams that don't spend a lot of time together. You need the clearest representation of those components—often documented down to the exact props that should be implemented. That is exactly how many enterprise software organizations are using Figma. Design and code components have props (for visual changes) that mirror one another.

Overall, Figma is geared pretty well to how many product orgs are delivering software.

I deeply, deeply despise the Figma-style design language that everything uses now, where there's barely any indication of what's clickable vs. what isn't and every screen is an endlessly-scrolling set of tiles and pills.

No borders, no button depth, no hyperlinks, huge swaths of blank monochrome space, menus distributed randomly, and my least favorite software design element of all time--scroll bars that aren't visible unless you're actively scrolling, but there actually are additional options on the list hidden in the borderless flat color below or above the list, so it looks like there's a static menu when in fact it's a scroll list.

I realize that I do not represent the most common user and that most people prefer as few clicked interactions with their software as possible (and also as little reading or learning as is possible), but I have vivid memories of when I could control computers and applications like I was at the command deck of a vehicle, and I greatly miss those days.

> the designer is to dream and your job is to build it

You may be thinking of an artist. A designer's job is to understand and solve user problems.

(FYI this is coming from a designer, not an engineer.)

> For example how many JavaScript programmers know what an Erlang supervisor pattern is. How can they if JavaScript doesn’t support it.

I've been running into the opposite issue. we built a project in liveview and the state management is not quite how I'd like it. pretty much everything is a callback to handle_info on a single object where you set the value to socket.assigns but no canonical way of organizing it. The pieces are all there to do some kind of stream based pipeline with an async reducer but no one has done it yet.

JS devs of course already know redux so this is a solved pattern in the js world

It is a shame, that so few designers actually know the medium they are working with well, let alone the primitives, that they are operating on top of (CSS layouts). If they did, I think we would have many less shitty website designs. Personally, I would expect someone who calls themselves a "web designer" to know HTML and CSS of course, and in a more or less up to date fashion. Well, not really would expect, but would hope. Building flying air castles in Figma is not really a work that requires high qualification, and reality catches up with those fantasies, when the web dev is told to implement them.