[HN Gopher] Ask HN: Why do some the best devs create some of the...
___________________________________________________________________
Ask HN: Why do some the best devs create some of the worst UX/UI?
This is somewhat provoking title, but I can't get my head around
it: Amazon, Apple, Google, Microsoft et. al. claim to hire only
tech's top talent. They often still put some mediocre to terrible
frontends out there. - Apple TV+ on the web: https://tv.apple.com/
is not a great experience. I get that Apple wants to people to use
an Apple TV, iPad, iPhone to watch Apple TV+. So it might be an
intentionally sub-par experience in this case, I guess? - Official
Reddit app: I'm actually fine with the Reddit app and use it since
Apollo was killed. It's still way less polished than Apollo and
it's hard to grasp why that must be. It's not even about the ads:
For example opening threads with a video embedded is a terrible UX
(just try it out). The settings are a mess, I turned off all
activity notifications and still receive some (in-app) - and can't
figure out why. - Official Youtube app: It's quite buggy. For
example, the "use device theme settings" on my iPhone 15 does not
work (it works on my iPad though!). When browsing through shorts (I
know, I know), the audio from the previous short often remains, so
one sees the current short's video with previous short's audio
track - one needs to switch back and forth to fix that. - Github:
Not sure if it's just me, but I find browsing Github extremely
slow. I have no benchmarks, but subjectively browsing through repos
the latency seems quit high. Given how obsessed frontend devs are
with loading/rendering times (SSR, Million.js, etc.) this doesn't
appear to be right. In most cases there's also no way to
officially report bugs. On the other hand there are so many indie
devs - who would probably have a hard time getting hired by FAANG
or even an interview - who create far superior user experiences.
It's also fairly easy to report bugs and in my experience they get
fixed. My question is: Is it a lack of developer skill on the
FAANG site? Is user experience not a priority at all? I wonder:
Wouldn't tech companies actually _benefit_ from supporting third
party clients? They might even force third party clients to put ads
into their apps. Maybe even force tracking and provide tracking
SDKs? I know tech companies won 't give up on ads & collecting
data. But at the very least put a clean, polished and stable app
out there or allow talented indies to do so.
Author : vismwasm
Score : 19 points
Date : 2024-02-16 16:03 UTC (6 hours ago)
| PaulHoule wrote:
| See https://en.wikipedia.org/wiki/Enshittification
| pavel_lishin wrote:
| Can you say more about how Enshittification specifically
| results in bad UI? Just dropping a wikipedia link isn't
| particularly helpful as an explanation.
| PaulHoule wrote:
| 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...
| marshray wrote:
| '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.
| ndjshe3838 wrote:
| 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
| aristofun wrote:
| 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.
| marcellus23 wrote:
| 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.
| fabianholzer wrote:
| 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.
| okdood64 wrote:
| Badly aligned incentives, for sure. I've found past a certain
| point, quality is not rewarded.
| beachtaxidriver wrote:
| "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.
| pschuegr wrote:
| 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.
| 1attice wrote:
| 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."
| pschuegr wrote:
| great links, thanks!
| tmpz22 wrote:
| 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.
| marshray wrote:
| Most of his specific complaints are not about "creeping
| featurism" though.
|
| Just plain old software quality, like bugs in core
| functionality and sluggishness.
| silisili wrote:
| 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.
| gsuuon wrote:
| 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.
| jokethrowaway wrote:
| 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.
| ilrwbwrkhv wrote:
| 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.
| pedalpete wrote:
| 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_...
| solardev wrote:
| 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.
| vismwasm wrote:
| > 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.
| solardev wrote:
| > 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/gsut
| il..., 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.
| closeparen wrote:
| 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.
| stevage wrote:
| 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.
| nostrademons wrote:
| 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.
| kingkongjaffa wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-16 23:02 UTC)