Getting UX right is a lot harder than people realize for several reasons:

- You have the usual BigCo problems in software with prioritization and incentives and pressure to deliver new features

- Front-end work is less mathematically complex and is generally undervalued by large companies that rely on complexity as a metric for difficulty/value

- When you use a piece of software all day for months/years, you learn the happy path to get things done and you forget all the rough edges because "it works fine for me"

- It requires a lot of detailed thinking about how other people perceive your work which is not something that software developers tend to excel at

- The user story which led to the UI/UX is not explicit to the user and the ways that users will try to use your UI are almost infinite

- Writing tests for front-end code has historically been more difficult

- There are a large variety of devices out there and testing on them all is time-consuming and painful

- Software is hard. People are hard. Combining them is harder.

- Small companies have a small surface area (people x devices x products) to cover and thus get more focused attention from their devs. Large companies have team reorgs and turnovers and many people who might have different priorities working on the same product

- Large companies know that people will still use their products even if the UX is worse because breaking out of the Apple/Google/Microsoft ecosystem requires significant tradeoffs

- Bug reports from the general public are given lower weight at big companies because of scale. When you have 10 bug reports to sort through it's not that hard to prioritize and ignore, not to mention that early adopters and small software users are more likely to be good bug reporters. When you have 10,000 bugs of which 9,000 of them are filed by people who don't know how to explain the problem: "my X doesn't Y", you become numb to new bugs unless they are show-stoppers, which many UX bugs are not.

> Front-end work is less mathematically complex

Absurd.

In general UI is more complex because of state. Primitively speaking complexity of state machine grows exponentially with every new screen, dialogue.

But people often underestimate this.

> In general UI is more complex because of state.

Not just that, but there is a lot of craft (and state) involved in handling excellent micro-interactions correctly. For example, multi-column dropdowns where you're handling the current selection, keyboard focus & navigation, live filtering, matching international characters in the filter, disabled items, direction of expansion, accessibility...

Each "tiny" feature, when done well, will improve the UX through a small micro-interaction without getting in the way. But together, handling state well becomes an exercise in very careful, thoughtful, tedious programming. Between the tedium and the corporate resistance to long-tail excellence, only a developer who really cares will be able to accomplish it.

> only a developer who really cares will be able to accomplish it

great point

Unfortunately "caring" is hard to measure and => usually overlooked and don't help you get bigger salary

I would expect that UI complexity is directly correlated with how bad the UX is.

Presumably you mean inversely correlated?

No.

Then that doesn't make any sense to me.

This has nothing to do with developers. Most developers (good ones, anyway) are aware of these kinds of issues, and would like to fix them -- they're just not given the time. Leadership prioritizes other things.

1. System (big company) doesn't encourage this

2. Being best at leetcode kind of algorithms doesn't make you the best developer, far from it

3. Investing in UX has far less and longer ROI than in marketing, there is little motivation to invest in it from the system perspective. People get used to any sh*tty ux as long as the product delivers the ultimate goal.

Engineers that get hired in FANGs are good at leetcoding, not building products.

There is a total disconnect between algo skills and actual work.

The problems you mention are not caused by this though, it's mostly layers and layers of middle managers and product people deciding what's priority in ways that ignore the users.

What do you think the incentive is for those developers to fix these issues?

Do you think fixing bugs gets you promoted?

If you’re ever wondering “why does company do X”, look at the incentives

Outcomes follow incentives and products are reflections of the organizations that created them

IMO it's because book smarts and art/design smarts are two different things that may overlap but don't have to.

When you make sure every hire can reverse a binary tree or some nonsense you end up without many people with aesthetic design chops.

Why aren't most great authors also great painters? Or even closer, why can't some great writers aren't great speakers?

Being a great dev is about understanding the underlying system, flow of data, failure modes, etc. etc.

Having a great UI is about understanding human interactions. It's not about the coding. The coding of the interfaces is fine (probably great), it's the design of the interface itself which you are frustrated with.

There are great writers who understand how to weave a story. I think of Christopher McDougall, author of Born to Run and a great writer with Outside Magazine hen I think about it. I always enjoyed his writing, but he isn't a great presenter (from what I've seen). https://www.ted.com/talks/christopher_mcdougall_are_we_born_...

"we need to add this one more feature in 2 weeks so I can get promoted" -everyone at the company

Loop this for 8 years on a single product.

In general there are three incentives at Big Tech:

* Develop a platform, framework, standard, or policy that influences (hopefully positively) how other developers work.

* Ship an end-user feature behind an A/B test that proves it has meaningful impact on KPIs.

* Make some organizational annoyance that is popping up on your management chain's radar go away (migration ticket, SLA breach, etc).

Making a UI good for the sake of being good is not one of them. No one cares that you delighted the customer. That only ever happens to the extent that people give a shit beyond their incentives, or the organization is small enough to have outdated and irrational management practices.

Developers are not responsible for UX/UI. Product designers and managers are. As someone who has been using software since the 80s, I would say awareness of UX/UI in industry has steadily risen. However, there are some dynamics that are detrimental to software quality, such as the principal-agent problem in business software (where the buyer is not the user) and the promotion-driven design problem in large companies (where the UX may take a back seat to other criteria for promotion).

Because designing software and designing user experiences are two very different skill sets and being good at one has nothing to do with being good at the other.

Badly aligned incentives (from the end user perspective at least).

More cynically: No matter how well you your ticket monkeys are payed or how good they are at solving leet code questions, all this is not necessarily correlated with the quality of your tickets.

Badly aligned incentives, for sure. I've found past a certain point, quality is not rewarded.

UX/UI design is an entirely different job than coding. In mature development places there are UX designers that design the UI layout and user interaction and developers that implement the UI and the backend.

It's because of there being too many cooks in the kitchen for front-end. It's something people can see, and it's easy for anyone to have an opinion.

1. Devs are not working in isolation. Ideally a designer is also involved at some point to decide on user interactions.

2. This is kind of obvious but devs have next to 0 training in design.

3. Devs shouldn't be the ones creating UI/UX.

4. None of your examples were built solely by devs.

I don't understand the thread. The title seems to be unrelated to the description, and the final paragraphs about 3rd party clients is again another topic.

> - Devs are not working in isolation

Bugs (e.g. the YouTube Shorts one) or performance (GitHub) are the dev's responsibility, aren't they? (correct me if I'm wrong, I have no idea how big tech companies organise internally)

> 3. Devs shouldn't be the ones creating UI/UX.

Why not? Some of the best apps I've used come from devs who do both. E.g. Christian Selig of Apollo. And bugs / performance greatly influence UX.

> The title seems to be unrelated to the description

Sorry, English isn't my mother tongue so I might have chosen a bad title. Wasn't intentional.

> and the final paragraphs about 3rd party clients is again another topic.

Let me explain: My observation is that many first party clients (frontends) are often (sometimes far) inferior to third party clients while the first party clients have the best people in the industry working on them whereas third party clients are often developed by some indie devs without any big tech in their CV.

What you are observing has nothing to do with developer skill and is is just about different problem domains and different company sizes and market sizes. Much harder making apps that work for a hundred million people and meet marketing needs than a few thousand people who are just like you.

Good UI/UX involves saying No. Making money involves saying Yes. Its hard to reconcile the two in corporate environments.

FWIW I think they try really hard and invest a lot of resources in trying to achieve it - but the Yes people only have to win once to corrupt.

Most of his specific complaints are not about "creeping featurism" though.

Just plain old software quality, like bugs in core functionality and sluggishness.

This is like asking why UX sucks at code. It's a different job.

Bigcos don’t care. Bigcos are about getting that paycheck and keep moving.

Most engineers have more mechanical (or logical) sympathy than user empathy.

This is not a bad thing, generally -- attention is a zero-sum system, and a profound awareness of human discomfort is not as important to creating systems that are good for the systems. The primary stakeholder in any engineering product is the medium in which you're working, and for software engineers, it means knowing how to work 'with the grain' of ten thousand different mechanisms.

Yet humans seemingly arrive at the threshold of this world as inscrutable, outside forces, with capricious, unreasonable demands. Why would a user prefer a PWA, made with React and ten thousand pounds of JS goop, to something nice and clean (maybe executed in django and htmx?) Why would a user prefer some annoying elaborate third-party product integration, when they could instead just simply download a .csv?

The engineers who specialize in bridging both worlds (frontenders) are themselves often less respected and esteemed by other engineers. People talk about FEEs as "just" frontend engineers -- as though knowing two complex kinds of system (the mechanism, and the user) were somehow less impressive than knowing one. (This is not an uncommon cognitive distortion; for example, ask a fluently bilingual person about this.)

Part of the problem, I think, is that 'real' engineers think of product design as a form of visual design, which they then think about as a kind of subfield of aesthetics, like feng shui or cosmetics.

This is probably because not enough engineers are exposed to _usability theory_, which is a rigorously and empirically tested body of knowledge that identifies and expresses the grammar of human-machine interaction. If I could have one wish granted, it would be to get every engineer to read at least one article out of NN/g (https://www.nngroup.com/) per month, and ideally, one per week. I wish everyone knew basic stuff like Miller's magic number (https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus...) and the profound impact it has on system design and user preference.

UX architects and frontend engineers, frankly, need more respect, and need to be listened to more frequently, by backend engineers and management alike.

They also need to be hired in larger numbers and less frequently laid off (the recent industry-wide layoff convulsion has been particularly hard on designers.) And engineers of all kinds should have more opportunities to upskill and train in usability.

For consumers, there's the old adage, "you get what you pay for." For product owners and engineers, I'd suggest a corollary: "you create what you value -- and you fail to create what you don't."

great links, thanks!

Because big tech attracts people who want to dial it in. Hence quality is shit. Some brilliance in pockets, but overall it's shit. Startups are where it is at.

>Github

wtf? I wish other things had as good UI/UX as GH has.

Git's CLI on the other hand, ugh.

I'm fine with GitHub in general, but I find browsing repositories extremely slow. And I don't remember it always being like that. See my comment here for what I mean: https://news.ycombinator.com/item?id=39403789

Hahahahaha. Engineering manager at a FAANG here, churning out collective crap that is far worse than what myself or any individual member of my team would come up with. Here's the dynamic:

Executive sets strategic priorities. Executive may be a user of the product, but their experience (and the things they care about) are usually very different from the average user, simply by virtue of being a millionaire. They're probably way more time-constrained and way less money-constrained than the average user. They care much less what other people think of them. They probably have multiple devices. They're using it in their home or on-the-go, and don't need to worry about things like sharing space with other people. Smart executives realize this and try not to micro-manage product (although they will often give nudges), but this just means that their directives are in super general form like "We need to prioritize these 3 themes" or "We should be competing with these 3 companies."

Directors interpret the executives' strategy. They interpret it through the lens of how it will get them more headcount, more budget and greater responsibility. This is how they get to be executives, after all. So inevitably, problems are overcomplicated to make them seem difficult. Small but high-impact features are deprioritized until the experience is broken enough that fixing it becomes a high-priority task worthy of headcount. If your org manages to keep a project humming along perfectly so that users love it and nobody ever complains, it must not be that hard, so why should they give you headcount? For that matter, why do they even bother employing you when nothing's broken? They should just lay you and your whole department off and return the money to shareholders.

So say you have a problem area that has become broken enough that it's worth staffing up a team to fix it. First step is usually a UX Designer ideating on the problem area to come up with mocks. The UXD's initial design is usually pretty good. There are often some issues because the UXD is not a user and so may miss some of the finer subtleties of using the product, but the UXD usually at least tries to empathize with users and anticipate problems. And since it comes from a single person's mind, the design is at least cohesive.

The bigger problem is the UXD can't code. This results in 3 issues. #1 - the UXD often has no idea what is technologically feasible, and what will take a research team 5 years. #2 - the UXD needs an engineering team to actually build the product, which requires staffing, which needs to go back up to management. #3 - the UXD's work product is mocks, and this is how they communicate with the rest of the org. These are rarely interactive, and so they often have glitches when it comes to specifying exactly what results from every combination of actions a user can take. They are usually of fixed size and language, which means that they don't specify what happens on larger or smaller screen sizes, or when your text is gigantic (like German) or tiny (like Chinese), or when you're writing right-to-left (like Arabic). They almost never use real data, which means that constraints arising from missing or incomplete data don't show up in the mocks.

Because of #2, the UXD needs org buy-in for their designs to actually become reality. This usually comes in the form of a product manager championing their feature and making a business case for it. The PMs work closely with executive leadership to accomplish business goals. But that means that business goals need to override certain aspects of the design. Maybe the UXD made the design nice and clean with plenty of whitespace and bold content-forward images. But you still need to sell ads, and data shows that density is one of the highest predictors of click-through rate, and bold organic content that draws attention away from the ads will negatively impact revenue. Maybe there are legal restrictions on what you need to put on the page, which when adhered to break the UXD's clean layout. Maybe you need to pop up a cookie warning to keep the EU/California happy, or have a consent screen for some feature that few users really care about.

So then the business-bastardized mocks make it to the engineering team. Now they discover the design is impossible to implement. Probably the UXD underspecified what would happen with some edge case in the data, and then handling the edge case breaks all their assumptions in the design. Probably the engineer is really good - world-class, even - and so they can heroically put in a fix to make the UXD's design work by special-casing all the cases they forgot, in the process leaving technical landmines for the next team to stumble on. Except then they get blocked by the not-cleaned-up landmines from the last project that did this. They write the feature, and run an A/B test on it (all the big companies do this, so they can understand the impact and any potential regressions) - and find the metrics are all worse. By now the feature is late, so they're looking for quick fixes that will reverse the metrics regressions and let the feature launch. Any sort of initial consistency to the design goes out the window now, and you're looking for anything that you can implement that will get metrics up and fix the showstoppers, because otherwise you don't get anything launched. So little bugs are overlooked, the designer's careful interactions (to the extent the designer was careful about them) get overlooked, key principles of the original design are reverted - all just to get to the point where the feature is launchable and doesn't regress any metrics.

Eventually something that resembles maybe 30-50% of the original designer's intent launches, and everything else in the design is relegated to fast follows. If you're very lucky, you will actually do the fast follows, and the product may end up halfway decent. But remember the director's incentive: only solve big problems that will get you more headcount, more responsibility, and a promotion to VP. So inevitably the team gets moved off this area and goes on to mess up the next major issue area.

So to answer your question: yes, tech companies would probably benefit from supporting third-party clients. That's why many of them do during their growth phases, when they're trying to capture market share rather than dollars. But the individual executives that run tech companies do not benefit from supporting third party clients. They cannot be controlled, and are a threat to the executive's responsibility and headcount. Potentially they're a threat to company itself, if a client uses its brand and mindshare to build a competing platform. At the point where companies usually shut down their app ecosystems, they're not trying to win over users; they're trying to extract money from them.

If there's another meta-point to extract from this, it's the importance of communication and incentives. The small developer wins because he can make all the tradeoffs between UX, engineering difficulty, adoption, and revenue in his head. Big companies lose because only certain aspects of these, generally the ones centered around mocks and metrics, can be communicated precisely. Everything else drops off in importance because it can't survive the hops between different job functions.

Thanks for your insightful reply!

> they're not trying to win over users; they're trying to extract money from them.

Fair enough. But was there ever an attempt to extract money and/or data from the users through third-party apps? For example by forcing third-party to serve ads?

I'm actually questioning if it's in the long-term monetary interest of big tech to force users into subpar experiences. My guess is that current big tech apps don't even serve their purpose of maximizing profits & data extraction optimally. I'd expect a talented indie dev to be able to provide a better UX & monetizing users at the same time.

I mean if we want to go the evil route, we might even incentivize 3rd party devs. Let everyone build a Twitter or Reddit client, but they must serve ads and might get a fixed or percentage share. If someone can build an app where users actually like and click on the served ads, great.

Of course it's not in the long-term monetary interest of big tech to force users into subpar experiences. Nobody cares about the long-term at a public company, because you can just sell your stocks as long as doom is at least a quarter away. In many cases the subpar user experiences are in service of short-term monetary interests, which the stock market (and by extension, your management chain) very much cares about. It also probably doesn't matter all that much, as the only thing that matters in business is transactions, and relatively few users are going to quit using Reddit because the client sucks compared to the third-party options.

The "here, run ads in your third-party app and we'll give you a cut" business model has been tried, and is actually pretty successful. Try for example AdSense or an Android F2P game or AdMob. The difference is that the app itself is usually branded separately from the ad network, so users know they are using the 3rd party app and not the main service. I think that's the main concern for say a 3rd-party Twitter or Reddit client - at some point a critical mass of users start to think of say RIF as "Reddit", what's stopping them from redirecting their client at a new service and cutting off the real Reddit backend? This was basically how Imgur started, as "Image hosting for Reddit" and then they became a site in their own right.

UX isn't often a high priority, either among management or among devs (who often prefer backend or algorithmic stuff to UI tweaking).

But more often than not, you also have purposeful dark patterns and enshittification, usually for user data collection, advertisement, increasing addiction & interaction, funneling recommendations, making unsubs harder, etc. That's almost certainly the reason the consumer apps you mentioned (AppleTV, Reddit, and YouTube) have such shitty experiences. You're not really their customer, you're just a product who happens to pay them money too, and it's more profitable for them to control your journey and push you towards the most profitable avenues for them (via recommendations) than to really maximize your enjoyment of the platform.

AppleTV is especially bad in this regard, being a content aggregator among different channels & content networks, so they're incenventived to pay-for-play their recommendations and pit publishers against each other for your eyeballs, while simultaneously charging you to view those shitty recommendations. They get to profit from both sides!

For Github, are you sure it's even a frontend thing? Seems like a lot of the complexity in their app is backend, especially when you ask it to a dynamic diff between two random commits or whatever. I see similar latencies just using Git commits against a repo in the cloud. Meanwhile, something like using VScode running in Github is reasonably performant.

-------------

Side note: In my personal experience, a lot of smaller "boutique" apps from smaller companies and lone wolves have a much higher focus on UX, often because their business models revolves around it, attracting users through a superior experience instead of forcing the product on users by selling to management.

There is still a small but vibrant market for macOS desktop apps, for example, many of which have decent enough UX, like the bundled ones in Setapp (https://setapp.com/apps).

That's what you get when you the user are the primary customer, which is almost never the case in most consumer-facing big FAANG services. IMO it's why Dropbox used to be so much nicer than Skydrive (or whatever it's called now, the bundled Microsoft service); they started as a user-facing service before pivoting to enterprise (original YC app: https://www.ycombinator.com/apply/dropbox).

I find Discourse (the forum software) to be much nicer to use than Reddit or Google Groups, too, because they sell ONLY a UI and not advertising.

For Git stuff, there are many nice paid Git clients out there. For Github in particular, there's also some third-party integrations (like in Jetbrains IDEs) that can help make reviews/comments more seamless, though I still sometimes prefer Github's official UI.

At a certain scale, winning over users' hearts is no longer the prime driver of profit, and that's when companies start enshittifiying, especially if they're VC or publically owned and need to scale :( Small bootstrap businesses usually stay nicer for longer.

> For Github, are you sure it's even a frontend thing?

Well where do we draw the line here? I'm not even talking about diffs etc.: Just browsing through a repo and looking at single files is noticeable slow. As an end user I don't really care if it's the network request latency or because inefficient DOM rendering, it's not a great UX. For example loading this site here: https://github.com/GoogleCloudPlatform/gsutil/blob/master/te... took 1.26 seconds. And it's like that for any file or folder. Gitlab seems to have a similar initial load time however only once, after that it's faster.

> Well where do we draw the line here?

Yeah, that's a fair point! To the user it doesn't matter.

And to further prove your point, if you access the raw file at https://raw.githubusercontent.com/GoogleCloudPlatform/gsutil..., it only takes 25ms, even uncached. It's half a kB.

Add the Github UI, it's suddenly 1.2 MB... that's 2000x bigger, lol. And even with the UI already loaded, it still takes nearly 500ms to navigate from one file to another. It IS slow, isn't it?

Thanks for clarifying what you meant.

See https://en.wikipedia.org/wiki/Enshittification

Can you say more about how Enshittification specifically results in bad UI? Just dropping a wikipedia link isn't particularly helpful as an explanation.

You're making the big mistake of thinking it's about the quality of devs. No, it is the attitude of management.

All of the companies that you mention are near-monopolies in their field so they don't need to make good products; they make obscenely high profits so they can afford to pay high salaries and thus attract some good devs, it's not like the good devs themselves are a competitive advantage.

You see this in the lifecycle of communication products like Zoom. Early on they have an obssessive interest in the onboarding process and keep statistics about how many people fall out of the funnel because of this problem or that problem. At that phase good UI and good execution is a matter of life or death. Once the product is mature people are still going to keep having Zoom meetings even if some participants have trouble. It's really a lot of work to keep track of every quirk of every device and operating system update so at some point they'll quit doing it.

And that's it. Those applications are produced by large organizations that have a large number of priorities, including profit. The user has little voice. See also

https://pravse.medium.com/the-maze-is-in-the-mouse-980c57cfd...

'Enshittification' is a term that describes a very specific process seen in online services. It should not be applied to every ordinary "big company does not prioritize product quality" situation.