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

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

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.

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.

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.