Comment by hansmayer
3 days ago
Not looking to dismiss the authors long tenure at a major tech company like Google, but the first point kind of stuck like a sore thumb. If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. Every single one of their services is a pain to use, with unnecessary steps, clicks - basically everything you are trying to do needs a click of sorts. Recently I was writing an e-mail and noticed I misspelled the e-mail address of the recipient, which I rarely do. So, I should just be able to click the address and edit it quickly, right? Wrong - now you have a popup menu and inside of it you have to search for "edit e-mail" option. Most of the rest of his lessons while valuable in their own right, are not something I would put under the headline of "after X years at <insert-major-tech-company>", as they do not quite seem to be that different from lessons you pick up at other companies ? I´d more interested to hear about how the culture was impacted when the bean-counters took over and started entshittifying the company for both the users and the employees too.
> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse.
There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock"
When I worked on user facing stuff (Maps, Gmail, Accounts) I regularly read the public user support forums and ticket queues looking for complaints, sometimes I even took part in user threads to get more information. What I learned was:
• Almost nobody else in engineering did this.
• I was considered weird for doing it.
• It was viewed negatively by managers and promo committees.
• An engineer talking directly to users was considered especially weird and problematic.
• The products did always have serious bugs that had escaped QA and monitoring.
In theory there were staff paid to monitor these forums, but in practice the eng managers paid little attention to them - think "user voice" reports once a quarter, that sort of thing. Partly that's because they weren't technical and often struggled to work out whether a user complaint was just noise or due to a genuine bug in the product, something often obvious to an engineer, so stuff didn't get escalated properly.
This general disconnection from the outside world was pervasive. When I joined the abuse team in 2010 I was surprised to discover that despite it having existed for many years, only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team. He gave me his logins and we quickly discovered spammers had found bugs in the accounts web servers they were using to blow past the antispam controls, without this being visible from any monitoring on our side. We learned many other useful things by doing this kind of "abuser research". But it was, again, very unusual. The team until that point had been dominated by ML-heads who just wanted to use it as a testing ground for model training.
Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer.
I think there are multiple reasons for this, but they are mostly overlapping with preserving internal power structures.
PM's don't want anecdotal user evidence that their vision of the product is incomplete.
Engineering managers don't want user feedback to undermine perception of quality and derail "impactful" work that's already planned.
Customer relations (or the support team, user study, whatever team actually should listen to the user directly) doesn't want you doing their job better than they can (with your intimate engineering and product knowledge). And they don't want you to undermine the "themes" or "sentiment" that they present to leadership.
Legal doesn't want you admitting publicly that there could be any flaw in the product.
Edit: I should add that this happens even internally for internal products. You, as a customer, are not allowed to talk to an engineer on the internal product. You have to fill a bug report or a form and wait for their PMs to review and prioritize. It does keep you from disturbing their engineers, but this kind of process only exists on products that have a history of high incoming bug rate.
Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where you do not normally get to hear from customers much. Of course once these customers had my ear, the feature requests started to flow thick and fast, and I ended up spending way too much time on their specific issues. Which is just to say that I've changed my views over time.
In retrospect, the customers I helped were ones that had the most interesting problems to me, that I knew I could solve, but they were usually not the changes that would have the biggest impact across the whole customer base. By fixing a couple of customers' specific issues, I was making their lives better for sure, and that felt good, but that time could have been used more effectively for the overall customer base. PMs, managers etc should have a wider view of product needs, and it is their job to prioritize the work having that fuller context. Much as I felt at the time that those roles added little value, that was really not true.
Of course agreed that all the points made above for PMs, managers, support having their reasons to obstruct are true in some cases, but for a well run company where those roles really do their job (and contrary to popular opinion those companies do exist), things work better if engineers do not get too involved with individual customers. I guess Google might be a good example - if you have a billion customers you probably don't want the engineers to be talking to them 1:1.
12 replies →
> Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer.
Chiming in to say I’ve experienced the same.
A coworker who became a good friend ended up on a PIP and subsequently fired for “not performing” soon after he helped build a non technical team a small tool that really helped them do their job quicker. He wasn’t doing exactly as he was told and I guess that’s considered not performing.
Coincidentally the person who pushed for him to be fired was an ex-Google middle manager.
I’ve also seen so commonly this weird stigma around engineers as if we’re considered a bit unintelligent when it comes to what users want.
Maybe there is something to higher ups having some more knowledge of the business processes and the bigger picture, but I’m not convinced that it isn’t also largely because of insecurity and power issues.
If you do something successful that your manager didn’t think of and your manager is insecure about their own abilities, good chance they’ll feel threatened.
The sad thing is it doesn't have to be this way.
I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly.
We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users.
We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports).
Everyone was a team working together towards the same goal of making these tools the best for our internal audience.
It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...
> The engineer is not supposed to engage directly with the customer.
I don't know if companies have finally stopped pretending to be "agile"; but if not, this is such a clear demonstration of how they are anything but.
Theres another thread on HN at the moment about legislation being written by industry and rubber stamped by law makers. What hit me about this discussion and that one is that there's a lot of self interest out there with very little scrutiny or auditing. It boils down to that basically. If we want to fix problems at the top there needs to be independent auditing, reporting and consequence for people that do the wrong thing. But we all know thats not going to happen so buckle up and learn to live with broken laws and broken software.
Where I work we regularly bring in engineers to talk to clients directly. Clears up a lot of confusion when there’s something technical a PM wouldn’t understand. We still like to have a filter so a client isn’t trying to get the engineer to do free work. Having engineering isolated is pretty bad IMO.
There are very good less-cynical reasons. I've also seen companies with the opposite problem, where the engineers constantly shoot down real, important feedback brought by customer support in order to preserve the superiority of engineering over support.
If you have ten engineers and even just 100 customers, you have a very high number of conversational edges. Good luck keeping things consistent and doing any sort of long-term planning if engineers are turning the output of those conversations directly into features. "Engineers talking to customers but not making any changes" would be more stable, but is still a very expensive/chaotic way to gather customer feedback.
Additionally, very few of those single engineers have a full knowledge of the roadmap and/or the ability to unilaterally decide direction based on some of the customer feedback or questions. "Will this get fixed in the next two weeks?" "Will you build X?" etc. You don't want your customers getting a bunch of inconsistent broken promises or wrong information.
The best-managed orgs I've seen have pretty heavy engineering and user experience in their product and support orgs. You need people in those roles with knowledge of both how it's built AND how it should be used, but you can't continually cram all that knowledge into every single engineer.
A startup should start with the builders talking directly to the customers. But at a some point, if successful, you're going to have too many people to talk to and need to add some intermediaries to prevent all your engineering time going to random interrupts, and centralization of planning responsibilities to ensure someone's figuring out what's actually the most important feedback, and that people are going to work on it.
1 reply →
> User obsession means spending time in support tickets
That's really funny when Google's level of customer support is known to be non-existent unless you're popular on Twitter or HN and you can scream loudly enough to reach someone in a position to do something.
"10. In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency.
The engineers who stay sane and effective zero in on their sphere of influence. You can’t control whether a reorg happens. You can control the quality of your work, how you respond, and what you learn. When faced with uncertainty, break problems into pieces and identify the specific actions available to you.
This isn’t passive acceptance but it is strategic focus. Energy spent on what you can’t change is energy stolen from what you can."
------------------------
Point 10 makes it sound like the culture at Google is to stay within your own bailiwick and not step on other people's toes. If management sets a course that is hostile to users and their interests, the "sane and effective" engineers stay in their own lane. In terms of a company providing services to users, is that really being effective?
User interests frequently cross multiple bailiwicks and bash heads with management direction. If the Google mindset is that engineers who listen to users are "weird" or not "sane"/"effective", that certainly explains a lot.
It is an almost universal fact that dealing with retail customers is something that is left to the lowest paid, lowest status workers and often outsourced and now increasingly left to LLM chatbots.
While you obviously can't have highly paid engineers tied up dealing with user support tickets, there is a lot to be said for at least some exposure to the coal face.
> While you obviously can't have highly paid engineers tied up dealing with user support tickets,
You obviously can, that's one of the more visceral way to make them aware of the pain they cause to real people with their work, which sticks better, or simply serves as a reminder there are humans on the other side. There are even examples of higher paid CEOs engaging, we can see some of that on social media
I love reading this insights in a corp structure. Especially the sociological aspect of it (like "• It was viewed negatively by managers and promo committees."). Thanks a lot.
> only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team
This revelation is utterly shocking to me. That's like anti-abuse 101. You infiltrate their networks and then track their behavior using your own monitoring to find the holes in your observability. Even in 2010 that was anti-abuse 101. Or at least I think it was, maybe my team at eBay/PayPal was just way ahead of the curve.
Well, the 101 idiom comes from US education, it's a reference to the introductory course. Part of the problem with anti-abuse work is that there's no course you can take and precious little inter-firm job hopping. Anti-abuse is a cost of business so you don't see companies competing over employees with experience like you do in some other areas like AI research. So it's all learning-by-doing and when people leave, the experience usually leaves with them.
After leaving Google the anti-abuse teams at a few other tech companies did reach out. There was absolutely no consistency at all. Companies varied hugely in how much effort and skill they applied to the problem, even within the same markets. For payment fraud there is a lot of money at stake so I'd expect eBay would have had a good team, but most products at Google didn't lose money directly if there was abuse. It just led to a general worsening of the UX in ways that were hard to summarize in metrics.
2 replies →
Hey Mike! Alex from GR here. Good to see you around :)
>What I learned was:
>• Almost nobody else in engineering did this.
>• I was considered weird for doing it.
>• It was viewed negatively by managers and promo committees.
>• An engineer talking directly to users was considered especially weird and problematic.
>• The products did always have serious bugs that had escaped QA and monitoring
Sincerely, thank you for confirming my anecdotal but long-standing observations. My go-to joke about this is that Google employees are officially banned from even visiting user forums. Because otherwise, there is no other logical explanation why there are 10+ year old threads where users are reporting the same issue over and over again, etc.
Good engineering in big tech companies (I work for one, too) has evaporated and turned into Promotion Driven Development.
In my case: write shitty code, cut corners, accumulate tech debt, ship fast, get promo, move on.
The beancounter takeover was after you left.
2014 Google and 2019 Google were completely different companies.
If an engineer talking to users is considered problematic, then it is safe to assume, that Google is about as fast away from any actually agile culture as possible. Does Google ever describe itself as such?
"data-driven agile"™
Having only ever worked for startups or consulting agencies, this is really weird to me. Across 6 different companies I almost always interfaced directly with the users of the apps I built to understand their pain points, bugs, etc. And I've always ever been an IC. I think it's a great way to build empathy for the users of your apps.
Of course, if you're a multi billion dollar conglomerate, empathy for users only exists as far as it benefits the bottom line.
Thanks for sharing your valuable insights. I am quite surprised to learn that talking to customers was frowned upon at Google (or your wider team at least). I find that the single most valuable addition to any project - complementary to actually building the product. I have a feeling a lot of the overall degradation of software quality has to do with a gradual creep in of non-technical people into development teams.
Almost nobody else in engineering did this.
What you described is the job of a product manager. Are there no PMs at Google?
There are, and often times they're stuck in a loop of presenting decks and status, writing proposals rather than doing this kind of research.
That said, interpreting user feedback is a multi-role job. PMs, UX, and Eng should be doing so. Everyone has their strengths.
One of the most interesting things I've had a chance to be a part of is watching UX studies. They take a mock (or an alpha version) and put it in front of an external volunteer and let them work through it. Usually PM, UX, and Eng are watching the stream and taking notes.
Xoogler here.
When you get to a company that's that big, the roles are much more finely specialized.
I forget the title now, but we had someone who interfaced with our team and did the whole "talk to customers" thing. Her feedback was then incorporated into our day-to-day roadmap through a complex series of people that ended with our team's product manager.
So people at Google do indeed do this, they just aren't engineers, usually aren't product managers, frequently are several layers removed from engineers, and as a consequence usually have all the problems GP described.
PM is a fake job where the majority have long learned that they can simply (1) appease leadership and (2) push down on engineering to advance their career. You will notice this does not actually involve understanding or learning about products.
It's why the GP got that confused reaction about reading user reports. Talk to someone outside big company who has no power? Why?
3 replies →
> If the Google culture was at all obsessed about helping users
It's worth noting that Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer working on a product shipped to users.
It might be useful to keep that in mind as you read through what his lessons are, because they're surely shaped by the positions he held in the company.
I was Addy's manager when he was on Developer Relations.
He moved to an engineering manager role on Chrome DevTools many years ago and has recently just moved on to a different team. I don't think it's fair at all to say he's not a developer working on a product shipped to users when he led one of our most used developer tools, as well as worked on many of our developer libraries prior to moving to the Engineering manager role.
Yeah, maybe I should have been more precise, I meant "end users like your mom" rather than "not real users". Developing for developers, in a engineering-heavy team is obviously different than the typical product-development team.
>Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer
Oh
That's not a fair reading, he's as much of a developer as anyone else. But he wasn't (AFAIK) working on user-facing products specifically.
2 replies →
Ah, I see. I did notice it looked a bit too long-winded and fluffy for a developer-written text.
Fair point. "User" as developer rather than "user" as person clicking buttons in Gmail, Google Maps, etc, etc
I think that's more "this sounds great" than "our users are developers". Google's services also aren't aimed at developers, the APIs are often very bureaucratic and not very well done (there's no way to list the available google sheets documents in the sheets api, I need the drive API and a different set of permissions? please.)
It reads exactly like what you'd expect from a "I want to be considered a thought leader" person: nothing you haven't read a hundred times but it sounds nice so you can nod along.
[dead]
> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much
Ok, I mean this sincerely.
You must never have used Microsoft tools.
They managed to get their productivity suite into schools 30 years ago to cover UX issues, even now the biggest pain of moving away is the fact that users come out of school trained on it. That also happens to be their best UX.
Azure? Teams? PowerBI? It's a total joke compared to even the most gnarly of google services (or FOSS tools, like Gerrit).
I do agree with you. Teams are a cancer and Azure UI sucks too. I do not use much MS products since essentially Win7 I have mainly used Linux as my work environment. But one thing MS used to be good at at least, was the documentation. If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support. With google its like...not even that.
With continuous delivery and access to preview and beta features, the documentation is fragmented and scattered and half of it technically is for the previous version of the product with a different name but still mostly works because microsoft can't finish modernizing most software...
And the customer support is not great until you start really paying the big bucks for it.
There was also MSDN. But it was also a different world at the time.
> If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support.
But even then, contemporaries outclassed Microsoft by a lot.
It was culture back then to provide printed user manuals, I still have some from Sun Microsystems because it was the best resource I found to learn how storage appliances should work and the technical trade-offs of them.
2 replies →
I hate Microsoft with the passion of a thousand burning stars, yet even I still think Google products have worse UX than their Microsoft counterparts.
MS Teams is definitely terrible. But I’d take that over Google Meets.
Google Docs isn’t even remotely as good as Office 365.
And Azure, for all its many faults, is still less confusing than GCP.
Thankfully I seldom have to touch either other these companies half-baked UIs.
> I’d take [teams] over Google Meets
What? Why?
Honestly your entire comment is almost exact polar opposite to how I feel.
GCP Makes total sense if you know anything about systems administration, Google docs is limited for things like custom fonts (IE; not gonna happen) but it's simple at least and I can give people a link to click and it's gonna look the same for them.
But, honestly, the Teams one is baffling. I can't think of a single thing Meet does worse than Teams.
5 replies →
It's not just Google, the UX is degrading in... Well everything. I think it's because companies are in a duopole, monopole etc position.
They only do what the numbers tell them. Nothing else and UX just does not matter anymore.
It's like those gacha which make billions. Terrible games, almost zero depth, but people spend thousands in them. Not because they are good, but because they don't have much choice ( similar game without gacha) and part the game loop is made for addiction and build around numbers.
To offer some additional causes for the degradation of UX:
1. An increasing part of industry profits started coming from entertainment (or worse, psychological exploitation) instead of selling the customer a useful tool. For example, good budgeting-software has to help the user understand and model and achieve a goal, while a "good" slot-machine may benefit from confusion and distraction and a giant pull-handle.
2. "Must work on a touchscreen that fits in a pocket" support drags certain things to a lowest common denominator.
3. UX as a switching-cost for customers has started happening more on a per-product rather than a per-OS basis. Instead of learning the Windows or Mac "way" of screens and shortcuts, individual programs--especially those dang Electron apps--make their own reinventions of the wheel.
To be fair, it reads precisely “1. The best engineers are obsessed with solving user problems”. This doesn’t say those engineers are working at Google, just that it’s something the author learned whilst they worked at Google.
“Some [of these lessons] would have saved me months of frustration”, to quote the preamble.
I was going post exactly this! He was talking about those engineers that really exemplified, from his point of view, good engineers.
And dealing with engineering managers that didn't see much use in such activity might be part of "figur[ing] out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity".
Addy's users have been developers and Google has been very responsive in the past. I was usually able to get a hold of someone from teams I needed from Chrome DevTools and they've assisted open source projects like Node.js where Google doesn't have a stake. He also has a blog, books and often attended conferences to speak to users directly when it aligned with his role. I agree about the general Google criticism but I believe it's unjustified in this particular (admittedly rare) case.
And material UI is still the worst of all UIs. Had the pleasure of rolling out a production oauth client ... jesus christ. Only worse is microsoft in UX. You don't want me to use your services, do you?
> And material UI is still the worst of all UIs
I'm not sure how that got approved either, but at least we now know what would happen if a massive corporation created a UI/UX toolkit, driven only by quantitative analytics making every choice for how it should be, seemingly without any human oversight. Really is the peak of the "data-driven decisions above all" era.
the root of all evil right there...
What makes me wonder even more: why is this still in place? Someone must've noticed themselves when using it
I have an issue with the first point as well, but differently. Having worked on a user-facing product with millions of users, the challenge was not finding user problems, but finding frequent user problems. In a sufficiently complex product there are thousands of different issues that users encounter. But it's non-trivial to know what to prioritize.
I was also surprised to read this. I have terrible problems with all Google UIs. I can never find anything and it's an exercise in frustration to get anywhere.
I think your particular Gmail issue exists because they want mobile web and touch screen web users (there are dozens of us!) to be able to tap the recipient to show the user card, like hover does for mouse users. To support your usecase (click to directly edit recipient), touch, click, and hover need to have different actions, which may upset some other users. Unless you mean double click to edit, which I would support.
I save my energy for more heinous UX changes. For example, the YouTube comment chyron has spoiled so many videos for me and is just so generally obnoxious.
There is a lot of nuance to their point. They are saying, in the long run, career wise, focusing on the actual user matters and makes your projects better.
Google UX is decent and the author was not trying to comment on UX as a thing at Google. More that, if you follow the user what you are doing can be grounded and it makes your project way more likely to succeed. I would even argue that in many cases it bucks the trend. The author even pointed out, in essence there is a graveyard of internal projects that failed to last because they seemed cool but did nothing for the user.
> Google UX is decent and the author was not trying to comment on UX as a thing at Google.
Interesting, so he was not, contrary to the blog title, writing on the basis of his 14 years of experience at Google?
Read their point 1 carefully. They are saying, when you are building something or trying to solve a problem (for internal or external users) if you follow the user obsessively you will have a far better outcome that aligns with having impact and long term success. This does imply thinking about UX, but transitively, IMO.
3 replies →
The short answer is that the UI isn’t optimized for users like you.
I haven’t worked for Google specifically, but at this scale everything gets tested and optimized. I would guess they know power users like you are frustrated, but they know you’ll figure it out anyway. So the UX is optimized for a simpler target audience and possibly even for simpler help documents, not to ensure power users can get things done as quickly as possible.
I feel like you're giving too much credit here. I don't know if it was a leak or an urban legend, but I remember the awful win 8 "flat boxes UI" being that way because it could be designed by managers in PowerPoint that way
The specific feature in question...there is nothing "power" about it. It was a non-feature for decades essentially, I dont recall ever not being able to simply change an e-mail address by moving the cursor and typing in something else. How on earth is this something tested and optimised, for whom exactly?
This is almost certainly not the case. The larger the company the more change is viewed as a negative. Yes people may hold titles to do the things you describe but none are empowered to make change.
Google UI seemingly is optimized for happy path cases. Search for the obvious word and click a relevant link on the screen which appears. Write a single response to a single email and abandon than conversation afterwards, always use new conversations for every new email. Click a recommended video thumbnail on the frontpage and then continue with autoplay. Put only short defined text type in the cells of a spreadsheet, like date/number/text etc. And so on with all of their products.
But as soon as user tries to search for something no on the first page, or reply to a 10-20+ message thread with attachments in history, or tries to use playlists or search in YT, or input a slightly more complex data in the sheet cells - then all hell breaks loose.
Just the latest Google thing I've experienced - a default system Watch Later playlist is now hidden on Android. It's gone, no traces, no way to search for it. The only remnant of it is a 2-second popup after adding a new video to Watch Later, you can press "view" and then see it. Meanwhile it is still present as a separate item on PC. I'm writing this eaxmple because that was deliberate, that was no error or regression. Someone created a Jira for that and someone resolved it.
This is definitely an edge case. Most UI/UX from Google is very consistent and just works. Otherwise they won't be in this market.
Only UI/UX issue is that most experienced users want to not adapt to change. It is like people always telling Windows 7 is the best. Don't keep reinventing.
Another one that irks me is every UI/UX dev assumes people have 2 x 4K monitors and menu items overflow.
> Only UI/UX issue is that most experienced users want to not adapt to change
Users will not only adapt, but will even champion your changes if they make sense to said users. For example the web checkout or to name a more drastic example, iPhone and fingers as user interface devices. Once you start convincing the users that the interface is great, but they are too resistant to changes/dumb/uncreative to know how use it... its a different story I´d reckon ;)
> Recently I was writing an e-mail and noticed I misspelled the e-mail address of the recipient, which I rarely do. So, I should just be able to click the address and edit it quickly, right? Wrong - now you have a popup menu and inside of it you have to search for "edit e-mail" option.
I just tested this out and I don't think that's a particularly good example of bad UI/UX. Clicking the email address brings up a menu with options for other actions, which presumably get used more often. If, instead, you right-click the email address, the option to edit it is right there (last item on the bottom, "Change email address"). I don't see this as a huge penalty given that, as you said, it's rarely used.
There's also the "X" to the right of the email address, which you can use to delete it entirely, no extra clicks required.
> I just tested this out and I don't think that's a particularly good example of bad UI/UX
Luckily for both you and me, we dont have to rely on our feelings of what is good UX or not. There are concrete UX metholodogies such as Hierarchical Task Analysis or Heuristic Evaluation. These allow us to evaluate concrete KPIs, such as number of steps and levels of navigation required for an action, in order to evaluate just how good or bad (or better said, complicated a UX design is).
Lets say we apply the HTA. Starting from the top of your navigation level when you want to execute the task, count the number of operations and various levels of navigation you have to go through with the new design, compared to just clicking and correcting the e-mail address in-place? How much time does it take you to write your e-mail in the both cases? How many times do you have to switch back and forth between the main interface and the context menu google kindly placed for us? Now, phase out of your e-mail writing window and evaluate how many various actions you can execute in the Google Workspace. Most of them are likely to have a few quirks like this. Now multiply the estimated number of actions with the number of quirks and you will slowly start to see the immense cognitive load the average user has to face in using, or shall I rather say "combating" the google products' UX.
You never reasoned why the UX is there - what other use cases does it solve? perhaps that is more important question here.
which company's product has great UX? I'm always seeing people hating on things without showcasing examples of what they think is exemplary
Nothing is perfect, but here are a few things I enjoy using:
https://www.geogebra.org/calculator
https://regex101.com/
https://gchq.github.io/CyberChef/
https://www.figma.com
https://www.affinity.studio
https://bluecinema.ch (To buy movie tickets for a certain movie chain in Switzerland. I haven't used this in many years, but at first glance it looks like I remember it. Back then, this was a very smooth experience both on desktop and mobile. Just perfectly done.)
Any spreadsheet program (it's the spreadsheet itself, which I like, not necessarily how the UI is aranged around it)
Apple's Spotlight, GNOME's similiar thing (don't know the name)
I also like Tantacrul's interface design work: https://www.youtube.com/@Tantacrul/videos
For the all the necessary complexity and race-to-the-bottom features, I am a fan of Jetbrains. I like using Uber, Twitch (wrote a plugin for it one weekend to integrate with chrome), Netflix, Discord. There are plenty of companies that manage to be enjoyable to end users and expose apis without the inscrutable abstractions and terminology I encounter using google products. It feels the same as working with Oracle.
> Netflix
Netflix? The barely functional video player accessed via excessively bloated thumbnail gallery? About the only good thing to say about this is that all the other movie streaming platforms somehow are even worse.
Its not hating - just stating the facts. Most companies unfortunately dont have a nice UX these days, because common UX practices like not making user think (i.e. overcomplicating the UIs) and not blocking users (showing annoying popups in the middle of UI workflows) somehow became a lost art. Some products are inherently easy to use like draw.io for example. I really like the UX on Stripe, in particular their onboarding process. There is also a semi-famous e-commerce company, in the furniture space. I forgot their name (something with W?), but I ordered something once, and was really impressed by how smooth and uncomplicated the process from browsing the inventory to checkout and delivery itself was.
No one's. Everyone sucks. Find a product and you'll find a population collating complaints about it. Whining about interface design is like the cheapest form of shared currency in our subculture.
Fundamentally it's a bikeshed effect. Complaining about hard features like performance is likely to get you in trouble if you aren't actually doing the leg work to measure it and/or expert enough to shout down the people who show up to argue. But UI paradigms are inherently squishy and subjective, so you get to grouse without consequences.
None. A great UX nowadays is open source software running on your own hardware.
For example, you couldn't pay me to use a "webmail" like GMail over my own IMAP server and Thunderbird.
As somebody who already does this, I wouldn't say the Thunderbird's UX is the real motivation.
I do it for autonomy and avoiding lock-in, but Thunderbird has some frustrating inconsistencies particularly in its mishmash of searching and filtering.
why would a great UX be tied to the source being open or not?
3 replies →
How's that? VLC, GIMP, Ubuntu search and settings. Terrible. Great products, awedul UX.
1 reply →
Wow.. you are the one loving thunderbird. The ridiculous idea of removing menubar and if you enable that - it wastes valuable screenspace.
Omni Group. Wolfram. Parts of Apple. Rhino3D. Parts of Breville. Prusa (on device, not on desktop). Speed Queen (dial-based). Just from applications I currently have open and devices I can see from where I'm sitting.
I mean something that has a clear Google analog/equivalent that way can compare on. I personally think Wolfram Alpha (assuming that's what you're talking about) isn't any better than Google.
1 reply →
I would say basically everything that has won a an Apple Design Award before 2020.
Things for macOS for example.
You can learn something at a company by observing it’s weaknesses as well as strengths
I think the UX issues you’re describing are less related to culture changes in companies and more just in the industry in general
UX are designed by and for people who don’t really use computers. They use mobile devices and tablets
It’s an industry wide phenomenon
You are onto something there, if you mean, the design roles being taken over by the people who are not techies - like the POs. But if you just refer to UX being designed for mobile devices - that is not an excuse for an even worse UX on the mobile. If anything I would have expected more effort put in there, given how many more issues the limited screen estate can cause...
It’s designed for virtual keyboards rather than real ones
That makes a bigger difference than screen space
> wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse
UX? Google doesn't even bother helping folks locked out of their Gmail accounts. For people who use Android (some 3bn), that's like a digital death sentence, with real-world consequences.
It is almost comical that anyone would think Google is customer-focused, but might if they were being paid handsomely to think otherwise, all the while drinking a lot of kool-aid.
https://news.ycombinator.com/item?id=36024754 The top comment there is from a Xoogler which sums it up nicely:
Google rakes in $100bn a quarter; that's $1bn every day.
That is a great point too. For a company which effectively does not have a customer service, how can they claim to be obsessing about helping users at all?
Hell, in my experience they often don’t even help ad customers that are having issues that prevent them from buying ads.
And how are they supposed to do it if users did not add proper 2FA (and backup those recovery keys)?
Even banks are struggling to authenticate folks. For a longtime in EU people with 3rd world passports cannot create accounts easily.
Google cannot connect identity of a person to email address easily. Or they need to create CS - that will authenticate passports? And hundreds of countries, stolen IDs?
Nay.
> The thing is that at scale your edge cases are still millions of people
> never seem to be capable of handling the other parts that come with it
Same thing with govts. If you go to driver license. passport or any govt office then there will one person with some strange issue.
> I wonder why Google UX always sucked so much
It depends on how you define "suck."
When Google first launched it's homepage, its emptiness (just a logo & search box) was a stark contrast to the portal pages popular, which were loaded with content.
Some thought the Google homepage "sucked" whereas other liked it. (I was in the latter.)
Likewise, the interface for Gmail. Or the interface for Google Maps. Or the interface for Chrome.
I remember when Google appeared and literally can't recall anyone who thought it sucked. There statistically have to be some people who hated it. But everyone I knew was either on dial-up or low bitrate leased line and it was impossible to dislike that design.
I remember it too!
But not everyone was on dial-up. A lot were in dorms w/ (for the time) high speed connections or workplaces with it.
Remember at the time it wasn't clear that search was going to be the dominate pattern for how people found information on the web. It seems crazy now, but in the early days of the web, the space was small enough that a directory-style approach worked pretty well. It was Yahoo's directory that made it initially popular, not its search.
And so there was a fair bit of debate on which was better -- something like a directory + search (a la Yahoo!) vs just search.
It took a bit of time before search proved if it was done really well, you didn't need a directory.
As a developer I took the writer's point to refer to "users" generically, so that even if you work on some internal tools or a backend layer, you still have users who have to use your app or consume your API and there is a lot of learning possible if you communicate and understand them better.
Probably the users he is talking about are not the end users like you and me. It is one team using the tools/software of the other team and so "users" for that other team are the members of the first team.
I see it differently then UX at all. I find the need for better customer support 1000x more pertinent to helping users.
I'd like YouTube to add a button to stop showing scam ads from people outside my country.
Is there a big tech company that actually has good UX, besides maybe Apple?
I know Apple has a reputation for good UX but I think it's carry over from a different era and it's trending down.
I bought my kid an iPad for Christmas and set up parental controls, then could not disable it without another iPad (which I don't have).
There are many forum threads concluding you just have to factory reset.
I couldn't believe how many little unintuitive things I bumped into setting it up.
> Every single one of their services is a pain to use
Would you like to sign in to Google?
To me; point #3 is the big one and it is in conflict with point #1
How so? Those two together is literally agile; not as I've seen it done, but as it's intended. Learn, iterate, repeat.
> very single one of their services is a pain to use
Uhm, no? Google Cloud Platform is way more convenient to use than AWS, the IAM is way better designed, and documentation is leagues ahead of AWS.
[dead]