Ask HN: Why do some the best devs create some of the worst UX/UI?

- 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.

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.

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.

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

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

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_...

Loop this for 8 years on a single product.

* 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.

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.

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.

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.

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."

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

Git's CLI on the other hand, ugh.

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.

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.