> It's very difficult to create good UX by design because evaluating the system by imagination is much harder than with an implementation.

This is precisely why it’s a tragedy that the roles in software development have become so compartmentalized. It wasn’t that long ago that the same person designing an interface was also responsible for developing it. Or that design and development were one and the same, part of the same process.

These days, many “UX designers”, “UI designers”, and “product designers” have never written a line of code. Some even have an allergic response to the very idea of coding. That’s fine, but naturally it means there’s a wide gap in understanding between design and implementation. This leads to the UI equivalent of the dreaded Architecture Astronaut[1]—so disconnected from the reality of how software works and is built that they design absurd interfaces that look great in Figma but fail miserably when put into practice.

In my experience, the closer you are to the implementation—and by this I mean the more involved you are in the actual coding—the tighter the feedback loop on the quality of the user experience. It affords the sanding and polishing required for a great UI with a great experience. Some of the very best interfaces that I’ve seen and used, both in terms of quality user experience and visual design, were designed and built by those rare engineers that happen to have outstanding intuition and taste for great design. The worst UIs I’ve used are from designers that don’t code handed over to engineers with no design taste.

[1] https://en.wikipedia.org/wiki/Architecture_astronaut

This is a really great comment.

To me, "UX" still feels like a relatively new term. In its modern incarnation it's not what I do, although by intent it's actually my career speciality. As a category now, it feels like a poor compromise between true design and true code/userflow. I believe the existing tools try to bridge a gap that has existed since the earliest days of web development between the designers and the code monkeys.

I'm fortunate as a solo coder to have a very tight feedback loop with my own graphic design, but I wouldn't have it any other way. I started writing code making text-based games as a kid in the 80s, then became obsessed with graphic design, went to art school, worked as a designer at a traditional ad agency which had no coders... and because of my code competency became the go-to person for making web. And later apps. So I still currently art direct designers and also write the majority of code for clients. This lets me understand the flow first and then unify the design in ways that aren't prefab or obvious, but ensure user safety and flow in a beautiful way.

I think the tools now (Figma, yes, but also the reliance on standard use cases of frameworks like React) are very limiting. They shoehorn both designers and coders into an uncomfortable middle ground that's not too different from the arguments that used to erupt between designers and the couple of devs at my ad agency in the 90s - we want it to look like THIS vs. Do you know how impossible that is? So everyone settles on a crappy solution instead of sitting down and thinking about how to make something new and better for the situation.

Honestly, Flash was so great because it allowed both sides of a team to use both sides of their brain at the same time, and cross-pollinate design with code in a way that seems hopelessly lost now, at least for normal business apps outside of game development.

There aren't so many cases where business-y or banking software needs to be beautiful, but it could at least be thought through. I look at my banks' apps and sites and slap my face at the obvious miscommunication and sheer carelessness that must have taken place between management, design, and code to produce these monstrosities.

But would I want to be on the open market, looking for new clients with my cross-disciplinary background as a "UX" person? No. What they need aren't UX people. They need art directors who can at least write some code, or (even more rare) coders who have formal design training.

> These days, many “UX designers”, “UI designers”, and “product designers” have never written a line of code.

Same for some "architects". They just draw up random system designs that don't work for THEIR environment.

> This is precisely why it’s a tragedy that the roles in software development have become so compartmentalized.

The worse part of it all is it's not the software engineer's fault either (most of the time). HR, managers and others haven't improved over time and instead are enforcing non-software values on the engineers. It's all about ticking boxes. You get classified as a Go REST API backend engineer and somehow you can't touch React because that's not your thing.

Yet everything remotely serious built with React has gotten worse and worse... and apparently the project managers who rely in it and the coders who are used to its obviously major flaws can't think their way out of the wet paper bag that it's become, and see clear to writing a component from scratch. REST, sockets, whatever; the issue isn't how you send data over the wire, push it pull it or when. The issue is: Is what you're doing appropriate for the situation? My bank has started using something like React to show live stock prices in trashy grids. Guess what: That is a horrible idea because it's always wrong in some part of the screen. Let me reload if I have to, or else engineer something actually realtime.

They use these technologies because the recent grads who know how to use them are cheap and replaceable and the assumption is that the tech is uniform enough to make the coders hot-swappable. The product is enshittified garbage, but the managers don't care.

What is it exactly about React specifically (as apposed to Vue, HTML) that makes it flawed from a design perspective? I used to design and develop with Flash (which I very much miss) and while it was amazing for things like games, digital signage, elearning, etc, there is no way I could develop in Flash the products with the kind of complexity/responsiveness/sophistication of the web apps I am building now. Designing with hot reloading and code, live, is by far the most powerful and iterative design workflow I have ever experienced. While an inexperienced front-end developer may limit their design possibilities by only reaching for existing components, a good front end developer should be able to create bespoke components that are fit for purpose and responsive with the flexibility to rearrange and iterate.

With all that said though, there is a HUGE gap that Flash left for highly bespoke and creative products that web tech doesn’t satisfy at all.

> What is it exactly about React specifically (as apposed to Vue, HTML) that makes it flawed from a design perspective?

I'd say it's not React (not parent poster). I mean React might not be the best, but it's the least of the current problems.

React is the most widely used. You're bound to attract all sorts of people. Poor code is poor code. You'd hire React developers because it is the easiest to hire. It doesn't make it good or bad.

There's nothing really fundamentally wrong with React that makes it a terrible idea that always results in poor performance. It's shoddy development practices that can make for a bad app that uses React. If you use React well though, it's not like React makes it particularly difficult to reach a good level of performance. I typically find that React makes it easier for me to make a well-performing app, but that's just me.

I don't think it's even React itself that's the root cause the performance problems, it's using the data store badly (Redux or Mobx or even the new ones like Zustand and Valtio) that either causes components to rerender too often or causes too many components to rerender.

Having been bitten by this a few times, I'm paying a lot more attention to how my team uses it in the React app we're building from scratch right now, keeping an eye of how it's used and looking for problems before they become noticeable. I am, for example, inverting one of the common practices which I found was a cause of these performance problems:

"Atomic Design" with React splits components into different types - Atom, Molecule, Organism, Section/Template, Page. Each type of component is mainly composed of the smaller ones. It's generally suggested that Atoms and Molecules should be functional style and reusable, so not connected to the data store at all. Instead, Organism and up are the ones that manipulate data and pass things down into Molecules and Atoms to render. The problem here is that any update that triggers an Organism to rerender will also rerender all the Atoms and Molecules in it, even the ones that don't actually need to update (in the class-based component days we had shouldComponentUpdate() to avoid this, nowadays we have useMemo()/React.memo - neither of which we used with any consistency because of the extra effort).

Instead, while we do have a company-wide library of Atom-like elements we're using, the Atoms and Molecules inside the app are "smart" - they take a prop or two for configuration, then use that in combination with the data store to handle the data manipulation directly. Organism-level components then don't do any data wrangling and are just laying out what Molecules go where. This means when manipulating a Molecule, only that Molecule and any others looking at the same data need to rerender. The Organism and other Molecules in the same Organism are completely unaffected, not even trying to rerender and no need for React.memo to prevent it.

(Aside, to avoid confusion in the current app I haven't introduced the Atom/Molecule/Organism naming convention, and am instead using more semantic app-specific names for organizing components)

We still have a ways to go but we've already implemented the specific part I expected to cause the most problems here, and so far it's been great, the latency is so low it doesn't feel like a React app in the way I've come to expect, and there's much less manual manipulation of the data in the components themselves.

> I don't think it's even React itself that's the root cause the performance problems, it's using the data store badly (Redux or Mobx or even the new ones like Zustand and Valtio) that either causes components to rerender too often or causes too many components to rerender.

Like I said, it's shoddy development practices. I've seen apps that use one of those mutable object libraries (not any of the ones you listed) and just pass the objects everywhere. Whole app re-render on any state update because of how all of the state is nested inside these mutable mega-variables held by the root of the component tree. I try to chip away at the innermost components and create little havens that use immutable state as they should, but it's going to take years to redo the whole app that way, especially since refactoring isn't a priority yet.

By the way, a cool trick if a component you're using does not use `React.memo` is to memoize the element, because if React sees the exact same (reference-equal) element as the last render, it will not re-render the corresponding component tree. (Element refers to the return type of JSX expressions.) Obviously, only do this if it actually doesn't need to re-render.

I think the reason UX moved into its own realm (like "UX designer") is to create the processes to get actual UX expertise.

Without deliberate UX expertise, you're on the hook for having UI implementers (software engineers) who happen to be good at UX, and that's not a great way to go about ensuring that you have good UX because you're reliant on serendipity.

And of course once UX becomes its own prong that you're trying to optimize for, the simplest thing to do is create UX positions in your company. Which is much simpler than figuring out how to hire software engineers with UX expertise or good intuitions.

Just consider how few hiring processes involve someone clicking into your github projects and evaluating them just to see what kind of code you write. That's much harder than doing a canned leetcode or canned questions interview.

This isn't just a software thing... all of corporate america has compartmentalized and while the results in churning out widgets are actually very good, the results in practically everything else are bad bad bad. Even in finance, Warren Buffett will preach that investing is not a team sport - you need all the details in one head.

Make them learn coding instead of adding yet another responsibility onto developers.

Nobody is suggesting adding this responsibility to developers, but what actually happened was that developers who can design are almost forbidden from doing so, unless they are in positions of power.

Some of us have lost our voice when it comes to design.

You just perfectly laid out why it's simultaneously difficult to find a new job in UX while getting paid well once you do find a job (if you're good).

Those who understand what good UX is and how it manifests itself, value it highly, while many (even in tech) still consider it pixel-pushing and "pretty colors".

> and adopts a pleasing color palette and set of fonts

This is an unfortunate side-effect of confusing apps with web pages. No one hired a designer to pick the fonts and colors for Windows 95, because that was up to the OS ad user.

Or you know.. talk to users and understand their needs (discovery) then design solutions based off that understanding and iterate on designs with usability testing with said users until it feels like magic to them using it the first time, smooth and seamless flows across use cases with good copy and accessibility.