Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

191–200 of 732 posts

Re: Lessons from 14 years at Google

#191

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 everythi…

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 qu…

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.

Re: Lessons from 14 years at Google

#192

Earlier quoted context omitted.

which company's product has great UX? I'm always seeing people hating on things without showcasing examples of what they think is exemplary

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.

How's that? VLC, GIMP, Ubuntu search and settings. Terrible. Great products, awedul UX.

Re: Lessons from 14 years at Google

#193

Earlier quoted context omitted.

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.

why would a great UX be tied to the source being open or not?

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)

Re: Lessons from 14 years at Google

#194
post #54

seems the real lesson would be to not spend 14 years at google

I'm sure he made a killing though

It isn't just that he made a killing — Osmani helped conceive a broader vision of blogging as a fusion of human in the center writing and AI agents.

Re: Lessons from 14 years at Google

#195

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 everythi…

> 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,…

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

Re: Lessons from 14 years at Google

#196
post #18

I am going to file this line > If you win every debate, you’re probably accumulating silent resistance.

Sun Tsu said you have to either give your opponent an out or completely destroy them. I’ve always said that you can only skin a sheep once but can shear them over and over. Or to be more blunt, it’s better to be effective than right.

It’s about keeping the bigger/long term goals in mind. That means relationships and being an asshole.

Re: Lessons from 14 years at Google

#197
post #168

Earlier quoted context omitted.

> 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,…

Almost nobody else in engineering did this. What you described is the job of a product manager. Are there no PMs at Google?

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?

Re: Lessons from 14 years at Google

#198

> At scale, even your bugs have users. First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turnin…

Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.

Re: Lessons from 14 years at Google

#199

Earlier quoted context omitted.

Yeah but what do you want to do about it? The engineers I see making these mistakes day-to-day are not going to connect the dots if I just point them to the seminal writings. Heck, half of their complaints are of the same form as yours: if only the majority of [engineers, colleagues, stakeholders] were aware of [A, B, C principles] then we could avoid repeating [X, Y, Z failures]. Yeah it's exhausting, life is exhaus…

Well for starters I literally organized our company and all engineering around Conway‘s law and it’s working great That’s like the absolute bare minimum you can do, it’s trivially easy and solves a good half of these “problems.”

How big is your company?

Re: Lessons from 14 years at Google

#200

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 everythi…

> 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,…

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.

Post reply on HN