| ▲ | 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. |
|
| ▲ | mike_hearn 3 days ago | parent | next [-] |
| > 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. |
| |
| ▲ | avidiax 3 days ago | parent | next [-] | | 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. | | |
| ▲ | martinpw 3 days ago | parent | next [-] | | 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. | | |
| ▲ | palata 3 days ago | parent | next [-] | | > Engineers have a perception that most other roles are lesser Do they? I always felt I was at the bottom of the chain. "Moving up" means leaving engineering and going into management. > and if only they were allowed to be in charge things would go better. Could this be an oversimplification? Engineers understand how the product is built because they are the ones building it. And sometimes they are exposed to what other people (e.g. product people) have decided, and they know a better way. As an engineer, I am always fine if a product person listens to my saying that "doing it this way would be superior from my point of view", somehow manage to prove to me that they understood my points, but tell me that they will still go a different direction because there are other constraints. Now I have had many product people in my career who I found condescending: they would just dismiss my opinion by saying "you don't know because you don't have all the information I have, and I don't have time to convince you, so I will just go for what you see as an inferior way and leave you frustrated". Which I believe is wrong. Overall, I don't make a hierarchy of roles: if I feel like someone is in my team, I play with them. If I feel like they are an adversary, I play against them. I don't feel like I am superior to bad managers or bad product people; I just feel like they are adversaries. | |
| ▲ | wood_spirit 3 days ago | parent | prev | next [-] | | It’s oblique but this puts me in mind of an old adage I recently heard about war: Of 100 men, one should be a warrior, nine should be soldiers, and 90 shouldn't be there at all. I think this is true of software developers too: only in companies, the 90% don’t really know they shouldn’t be there and they build a whole world of systems and projects that is parallel to what the company actually needs. | | | |
| ▲ | Rapzid 3 days ago | parent | prev | next [-] | | This reads like it was written by a PM. You lacked higher level context and prioritization skills early in your career so the take away is it's best to divest agency to others? There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams. | | |
| ▲ | avidiax 3 days ago | parent | next [-] | | I think he has a point. These power structures exist for some good reasons as well. The opposite thing (engineers engaging directly with customers) can eventually lead to customer capture of your engineering org. You shouldn't have a small group of existing, noisy customers directly driving your engineering to the detriment of other existing or future customers. Microsoft had customer capture institutionally: the existing big corporate customers were all that mattered. It lead to rebooting Windows CE into Windows Mobile way too late to make a difference, for example. But it also meant that backwards compatibility and the desire to ship Windows XP forever were sacred cows. There are also nasty games that can be played by soliciting negative feedback for political advantage. Dysfunction can exist with any structure. It's probably best that there's some small amount of direct user feedback as well as the big formalized feedback systems, at least so that one is a check for the performance of the other. If the user engagement team says everything is good, but there are massive Reddit threads about how horrible the product is to work with and the engineers know it could be better, it's time for engineering to start addressing the issues alongside feedback to the user engagement teams. | |
| ▲ | majormajor 3 days ago | parent | prev [-] | | There's not enough hours in the day for everyone to do everything. > There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams. Yes, this is great for agency over implementation, because leaders do not have context to decide and dictate the What/How of implementing every single change or solution to a problem. And the implementers need to know the context to ensure they make decisions consistent with that context. But "leaders providing the context" is very different from "everyone researching the context on their own." So where are leaders getting this context from? A not-very-differentiated pile of 1000 generalist engineers-who-also-talk-to-customers-frequently-and-manage-their-own-work-streams? Or do they build a team with specialists to avoid needing the majority of people to constantly context-switch in a quest to be all of context-gatherers, work-prioritizers, market-researchers, and implementation-builders? | | |
| ▲ | andrewprock 3 days ago | parent | next [-] | | There are many leaders that use information as a tool that serves their own needs. They may have the context, but they are either too focused on their own job to share it, or actively manage dissemination so they can manipulate the organization. In my experience, this is the typical operating mode, though I do not think it is sinister or malicious - just natural. | |
| ▲ | Rapzid 3 days ago | parent | prev [-] | | Poor leaders gonna lead poorly. |
|
| |
| ▲ | mike_hearn 3 days ago | parent | prev | next [-] | | Agree that this can be an issue but to clarify, I was finding bugs or missed outages, not gathering feature requests or trying to do product dev. Think "I clicked the button and got a 500 Server Error". I don't think random devs should try and decide what features to work on by reading user forums - having PMs decide that does make sense as long as the PM is good. However, big tech PMs too often abstract the user base behind metrics and data, and can miss obvious/embarrassing bugs that don't show up in those feeds. The ground truth is still whether users are complaining. Eng can skip complaints about missing features/UI redesigns or whatever, but complaints about broken stuff in prod needs their attention. | |
| ▲ | mixmastamyk 3 days ago | parent | prev | next [-] | | An org can always go too far in the opposite direction, but this is not an excuse to never talk to the customer. The latter is much more likely, so the warning to not get “into bed” with the customer falls flat. This is a common pattern here. Alice says 0 degrees is too cold, I prefer 20C, Bob chimes in “100C is too hot, it’ll kill us.” Ok, well no one said or implied to crank it to one hundred. | |
| ▲ | liveoneggs 3 days ago | parent | prev [-] | | every customer complaint is N customers lost who don't say anything "the biggest impact" isn't knowable so a bird in hand is worth more than whatever might be in the bush | | |
| ▲ | majormajor 3 days ago | parent [-] | | If you have M customer complaints, and each one risks a differently-sized N customers... you better try to triage that vs just playing whack-a-mole with whatever comes to a random engineer first. I've never seen engineers plow through a bunch of 0-or-1-customers-would-actually-churn-over-this papercuts because it was easy and it feels good - the customer mentioned it! i fixed it! - while ignoring larger showstoppers that are major customer acquisition and retention barriers. Nothing is knowable in only the same way that plans are useless but planning is essential. |
|
| |
| ▲ | jordwest 3 days ago | parent | prev | next [-] | | > 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. | |
| ▲ | imperio59 3 days ago | parent | prev | next [-] | | 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... | |
| ▲ | azangru 3 days ago | parent | prev | next [-] | | > 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. | |
| ▲ | globalnode 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | dawnerd 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | majormajor 3 days ago | parent | prev [-] | | 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. | | |
| ▲ | andrewprock 3 days ago | parent [-] | | On the contrary, the best products are typically built by the users of the products. If you are building a product you don't use, it will be worse than if you used it. Users should be everywhere, in and out of engineering. |
|
| |
| ▲ | moffkalast 3 days ago | parent | prev | next [-] | | > 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. | |
| ▲ | beloch 3 days ago | parent | prev | next [-] | | "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. | |
| ▲ | multjoy 3 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | eviks 3 days ago | parent [-] | | > 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 |
| |
| ▲ | agumonkey 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | jedberg 3 days ago | parent | prev | next [-] | | > 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. | | |
| ▲ | mike_hearn 3 days ago | parent [-] | | 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. | | |
| ▲ | jeffbee 3 days ago | parent [-] | | I seem to recall sitting in weekly abuse team meetings where one of the metrics was the price of a google account on the black market. So at least some of these things were tracked and not just by one individual. | | |
| ▲ | mike_hearn 3 days ago | parent [-] | | Yes, I think me and the other guy I referred to started that practice ;) |
|
|
| |
| ▲ | damethos 3 days ago | parent | prev | next [-] | | Hey Mike! Alex from GR here. Good to see you around :) | |
| ▲ | abex3000 3 days ago | parent | prev | next [-] | | >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. | |
| ▲ | fooker 3 days ago | parent | prev | next [-] | | The beancounter takeover was after you left. 2014 Google and 2019 Google were completely different companies. | |
| ▲ | zelphirkalt 3 days ago | parent | prev | next [-] | | 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? | | | |
| ▲ | abustamam 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | hansmayer 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | p1esk 3 days ago | parent | prev [-] | | Almost nobody else in engineering did this. What you described is the job of a product manager. Are there no PMs at Google? | | |
| ▲ | Xorlev 3 days ago | parent | next [-] | | 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. | |
| ▲ | javawizard 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | stefan_ 3 days ago | parent | prev [-] | | 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? | | |
| ▲ | kmoser 3 days ago | parent | next [-] | | I've had the pleasant experience of having worked for PMs at several companies (not at Google) who were great at their jobs, and advocated for the devs. They also had no problem with devs talking directly with clients, and in fact they encouraged it since it was usually the fastest way to understand and solve a problem. | |
| ▲ | lovich 3 days ago | parent | prev | next [-] | | Almost every job in the US is primarily about pleasing leadership at the end of the day. If companies didn’t want that sort of incentive structure to play out then they would insulate employees from the whims of their bosses with things like contracts or golden parachutes that come out of their leaderships budget. They pretty much don’t though, so you need to please your leadership first to get through the threat of at will employment, before considering anything else. If you’re lucky what pleases your leadership is productive and if your super lucky what pleases them even pleases you. Gotta suck it up and eat shit or quit if it doesn’t though | |
| ▲ | potatoproduct 3 days ago | parent | prev [-] | | Sounds like you just got stuck with a shit PM to be honest. |
|
|
|
|
| ▲ | embedding-shape 3 days ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | kinlan 3 days ago | parent | next [-] | | 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. | | |
| ▲ | embedding-shape 2 days ago | parent [-] | | 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. |
| |
| ▲ | techsystems 3 days ago | parent | prev | next [-] | | >Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer Oh | | |
| ▲ | embedding-shape 3 days ago | parent [-] | | 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. | | |
| ▲ | alemanek 3 days ago | parent [-] | | I think it is more the point that the users for his job were external developers. The role is inherently user facing and user focused. I don’t think anyone was trying to say he wasn’t a developer just that his job wasn’t to directly develop products | | |
| ▲ | embedding-shape 3 days ago | parent [-] | | Yeah, I guess I just wanted to add that because of the way that quote was cut at the end, made me believe that the person quoting me thought Osmani "isn't a developer". |
|
|
| |
| ▲ | hansmayer 3 days ago | parent | prev | next [-] | | Ah, I see. I did notice it looked a bit too long-winded and fluffy for a developer-written text. | |
| ▲ | drewda 3 days ago | parent | prev | next [-] | | Fair point. "User" as developer rather than "user" as person clicking buttons in Gmail, Google Maps, etc, etc | | |
| ▲ | luckylion 3 days ago | parent [-] | | 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. |
| |
| ▲ | vcsuspect 3 days ago | parent | prev [-] | | [dead] |
|
|
| ▲ | dijit 3 days ago | parent | prev | next [-] |
| > 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). |
| |
| ▲ | hansmayer 3 days ago | parent | next [-] | | 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. | | |
| ▲ | datadrivenangel 3 days ago | parent | next [-] | | 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. | |
| ▲ | ghaff 3 days ago | parent | prev | next [-] | | There was also MSDN. But it was also a different world at the time. | |
| ▲ | dijit 3 days ago | parent | prev [-] | | > 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. | | |
| ▲ | hansmayer 3 days ago | parent [-] | | Fair enough, everyone delivered software in boxes and with 500 page manuals. I still maintain MS did invest a lot in the quality of their documentation and they cared about developers - otherwise the Petzold series would have never happened (or the MS Press for that matter). | | |
| ▲ | dijit 3 days ago | parent [-] | | Ah yeah, fair, the Microsoft Press had some absolute bangers. |
|
|
| |
| ▲ | hnlmorg 3 days ago | parent | prev [-] | | 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. | | |
| ▲ | dijit 3 days ago | parent [-] | | > 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. | | |
| ▲ | ipdashc 3 days ago | parent | next [-] | | Yeah that seriously whiplashed me too, I'm genuinely confused. Google Meets has always worked completely fine for me, good performance, works well on mobile, Firefox, etc. Nothing special but it works. Probably my favorite of all the meeting apps. Teams meanwhile is absolutely my least favorite, takes forever to load, won't work in Firefox, nags me to download the app, confusing UI. I don't think I've ever heard anyone say they like teams. | |
| ▲ | hnlmorg 2 days ago | parent | prev | next [-] | | Because it’s a low bitrate micky mouse toy. MS Teams might have its issues (and let’s be clear, i agree there are a great many issues) but it has most, if not all, of the Enterprise features you need from a video conferencing suite. Whereas Google Meets feels more like a cut down toy you’d give to your grandparents. It’s the same thing with Google Docs. They’re technically impress for the era they were launched, but they’re stuck in the 2010s. Doing anything outside of the basics quickly becomes far far more frustrating than using O365. Microsoft might write a lot of terrible software with some questionable design choices, but they understand enterprise uses far better than Google. Even Google Workspaces is severely limited once your business grows beyond 50 people. I guess if you only work in startups then Google might seem like an easy win. But for any business that’s more established, you just constantly run into huddles with Googles suite of software. As for GCP, I’ve been burned too many times with their support processes. 7 days to approve a GPU quota. Account managers literally trying to steal business secrets (when I worked for an AI start up and Google were stagnating in the AI space). And so on and so forth. Though I’ve not been hugely impressed with Azure either; they constantly break managed services and ballsup scalability promises and then refuse to admit it until we present them with empirical evidence. It really feels like the best cloud engineers have left Microsoft (or maybe never joined?). | |
| ▲ | kiwijamo 3 days ago | parent | prev [-] | | I've used Meet a few times for video calls and I was amazed at how poorly it worked given the amount of resources Google has at their disposal. I've never had a good video call on Meets. I've had a few Meet calls where over time the resolution and bitrate would be reduced to such a low point I couldn't even see the other person at all (just a large blocky mess). Whereas Teams (for all its flaws) normally has no major issues with the video quality. Teams isn't without its flaws and I do occassionally fall back to ZOom for larger group video calls but at the end of the day Teams video calling sort of just works fine. Not great but not terrible either. YMMV of course. | | |
| ▲ | dijit 3 days ago | parent | next [-] | | I've had the complete opposite experience. Meet has been rock solid for me whilst Teams has been an absolute nightmare. The thing is though both Meet and Teams use centralised server architectures (SFUs: Selective Forwarding Units for Google, "Transport Routers" for Teams), so your quality issues likely come down to network routing rather than the platforms themselves. The progressive quality degradation you're describing on Meet sounds like adaptive bitrate doing its job when your connection to Google's servers is struggling. The reason Teams might work better for you is probably just dumb luck with how your ISP routes to Microsoft's network versus Google's. For me in Sweden, it's the opposite ... Teams routes my media through relays in France, which adds enough latency that people constantly interrupt each other accidentally. It's maddening. Meanwhile, Meet's routing has been flawless. But even if Teams works for your particular network setup, let's not pretend it's a good piece of software. Teams is an absolute resource hog that treats my CPU like a space heater and my RAM like an all-you-can-eat buffet. The interface is cluttered rubbish, it takes ages to start up, and the only reason anyone tolerates it is because Microsoft bundled it with Office 365. Your mileage definitely varies... sounds like you've got routing that favours Microsoft's infrastructure. Lucky you, I suppose, but that doesn't make Teams any less dogwater for those of us stuck with their poorly-placed European relays. | |
| ▲ | Orphis 2 days ago | parent | prev [-] | | As someone who worked on Meet at Google, it seems that it could have been networking to the datacenters where the call is routed from, some issues with UDP comms on your network which triggered a bad fallback to WebRTC over TCP. Could also have been issues with the browser version you used. Since Teams is using the very old H264 codec and Meet is using VP8 or VP9 depending on the context, it's possible you also had some other issues with bad decoding (usually done in software, but occasionally by the hardware). Overall, it shouldn't be representative of the experience on Meet that I've seen, even from all the bug reports I've read. |
|
|
|
|
|
| ▲ | Bombthecat 3 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | Terr_ 3 days ago | parent [-] | | 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. |
|
|
| ▲ | inopinatus 3 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | nabbed 3 days ago | parent [-] | | 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". |
|
|
| ▲ | inglor 3 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | RamblingCTO 3 days ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | embedding-shape 3 days ago | parent [-] | | > 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. | | |
| ▲ | andrekandre 3 days ago | parent | next [-] | | > quantitative analytics making every choice for how it should be, seemingly without any human oversight
the root of all evil right there... | |
| ▲ | RamblingCTO 2 days ago | parent | prev [-] | | What makes me wonder even more: why is this still in place? Someone must've noticed themselves when using it |
|
|
|
| ▲ | gniv 3 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | jwr 3 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | cyberrock 3 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | bitexploder 3 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | hansmayer 3 days ago | parent [-] | | > 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? | | |
| ▲ | bitexploder 3 days ago | parent [-] | | 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. | | |
| ▲ | hansmayer 3 days ago | parent [-] | | I am not sure I follow - is he, or is he not, writing about his experiences from 14 years at Google? The title suggests he does, yet you suggest that he does not? | | |
| ▲ | bitexploder 3 days ago | parent | next [-] | | Oh, I have no doubt they are at Google. I was just trying to say that the author was not really making a commentary on UX directly. The author was trying to make the point that understanding what sort of products and problems users have is a valid long term strategy for solving meaningful problems and attaching yourself to projects, within Google, that are more likely to yield good results. And if you, yourself, are doing this within Google it benefits you directly. A lot of arguments win and die on data, so if you can make a data driven argument about how users are using a system, or what the ground reality of usage in a particular system is and can pair that with anecdotal user feedback it can take you a long way to steering your own, and your orgs work, towards things that align well with internal goals and or help reset and re-prioritize internal goals. | |
| ▲ | d0gbread 3 days ago | parent | prev [-] | | His learnings from 14 years at Google. Surely we've all learned things working for employers or with engineers that don't do a thing well. In 14 years he probably also experienced great engineers come and go and start other successful businesses they very likely did not run exactly like Google. |
|
|
|
|
|
| ▲ | Aurornis 3 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | dtech 3 days ago | parent | next [-] | | 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 | |
| ▲ | hansmayer 3 days ago | parent | prev | next [-] | | 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? | |
| ▲ | rustystump 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | Yizahi 3 days ago | parent | prev [-] | | 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. |
|
|
| ▲ | whyagaindavid 3 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | hansmayer 3 days ago | parent [-] | | > 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 ;) |
|
|
| ▲ | kmoser 3 days ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | hansmayer 3 days ago | parent [-] | | > 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. | | |
| ▲ | jve a day ago | parent [-] | | You never reasoned why the UX is there - what other use cases does it solve? perhaps that is more important question here. |
|
|
|
| ▲ | websiteapi 3 days ago | parent | prev | next [-] |
| which company's product has great UX? I'm always seeing people hating on things without showcasing examples of what they think is exemplary |
| |
| ▲ | fainpul 3 days ago | parent | next [-] | | 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 | |
| ▲ | Supermancho 3 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | TeMPOraL 3 days ago | parent [-] | | > 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. |
| |
| ▲ | hansmayer 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | ajross 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | drnick1 3 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | Terr_ 3 days ago | parent | next [-] | | 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. | |
| ▲ | websiteapi 3 days ago | parent | prev | next [-] | | why would a great UX be tied to the source being open or not? | | |
| ▲ | haunter 3 days ago | parent [-] | | Because if you don’t like the UX you just edit the source code yourself and make it better /s /s but I wish it wasn’t because a lot of FOSS evangelists have this mindset (here on HN too) | | |
| ▲ | fwip 3 days ago | parent [-] | | More seriously - open source software is resistant to enshittification. It's obviously not a panacea, but the possibility of forks (or just the user deciding not to update), combined with the difference in profit motive, tends to result in software that respects the user. (Taken holistically, the UX of software does not just mean the UI, or the moments when you are using the software. It also includes the stability of the software over time, including whether or not you are able to reject new versions whether you do not like.) | | |
| ▲ | drnick1 3 days ago | parent [-] | | This. The only real risk with open source is that a (fairly niche) project is discontinued/abandoned, and you can't find binaries anymore for it anymore (and you don't have the skills to build it yourself). But this happens to proprietary software all the time (see killedbygoogle.com). |
|
|
| |
| ▲ | dystopiandevel 3 days ago | parent | prev | next [-] | | How's that? VLC, GIMP, Ubuntu search and settings. Terrible. Great products, awedul UX. | | | |
| ▲ | whyagaindavid 3 days ago | parent | prev [-] | | Wow.. you are the one loving thunderbird. The ridiculous idea of removing menubar and if you enable that - it wastes valuable screenspace. |
| |
| ▲ | addaon 3 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | websiteapi 3 days ago | parent [-] | | 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. | | |
| ▲ | addaon 3 days ago | parent [-] | | Never really used Alpha, was talking about Mathematica. I don’t the the web is compatible with good UX, but that doesn’t mean good UX isn’t possible — it just means that the companies that are successful at UX build native applications, or physical objects, or both. |
|
| |
| ▲ | danielscrubs 3 days ago | parent | prev [-] | | I would say basically everything that has won a an Apple Design Award before 2020. Things for macOS for example. |
|
|
| ▲ | steve-atx-7600 3 days ago | parent | prev | next [-] |
| You can learn something at a company by observing it’s weaknesses as well as strengths |
|
| ▲ | lkjdsklf 3 days ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | hansmayer 3 days ago | parent [-] | | 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... | | |
| ▲ | lkjdsklf 3 days ago | parent [-] | | It’s designed for virtual keyboards rather than real ones That makes a bigger difference than screen space |
|
|
|
| ▲ | ignoramous 3 days ago | parent | prev | next [-] |
| > 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: The thing is that at scale your edge cases are still millions of people. Companies love the benefits that come from scale, like having a billion people use their service, but they never seem to be capable of handling the other parts that come with it :(
Google rakes in $100bn a quarter; that's $1bn every day. |
| |
| ▲ | hansmayer 3 days ago | parent | next [-] | | 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? | |
| ▲ | stefanfisk 3 days ago | parent | prev | next [-] | | Hell, in my experience they often don’t even help ad customers that are having issues that prevent them from buying ads. | |
| ▲ | omnifischer 3 days ago | parent | prev [-] | | 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. |
|
|
| ▲ | wdr1 3 days ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | varjag 3 days ago | parent [-] | | 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. | | |
| ▲ | wdr1 3 days ago | parent [-] | | 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. |
|
|
|
| ▲ | foobarian 3 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | shultays 3 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | sfmike 3 days ago | parent | prev | next [-] |
| I see it differently then UX at all. I find the need for better customer support 1000x more pertinent to helping users. |
|
| ▲ | Hatrix 3 days ago | parent | prev | next [-] |
| I'd like YouTube to add a button to stop showing scam ads from people outside my country. |
|
| ▲ | seanmcdirmid 3 days ago | parent | prev | next [-] |
| Is there a big tech company that actually has good UX, besides maybe Apple? |
| |
| ▲ | d0gbread 3 days ago | parent [-] | | 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. |
|
|
| ▲ | lostlogin 3 days ago | parent | prev | next [-] |
| > Every single one of their services is a pain to use Would you like to sign in to Google? |
|
| ▲ | 3 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | sans_souse 3 days ago | parent | prev | next [-] |
| To me; point #3 is the big one and it is in conflict with point #1 |
| |
| ▲ | d0gbread 3 days ago | parent [-] | | How so? Those two together is literally agile; not as I've seen it done, but as it's intended. Learn, iterate, repeat. |
|
|
| ▲ | deepsun 3 days ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | 3 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | bschmidt25012 3 days ago | parent | prev [-] |
| [dead] |
