In all fairness, our UX/UI design studio [1] has worked with engineering teams of big companies. Be it Google engineers or others. The problem, almost always, is that the designers try to design simple UX logic - Engineers try to implement that logic - but someone higher up urges those engineers to add ABC and XYZ. All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion. And, unintentionally, remove any logic that was initially part of the design process. To design better products, there should be a better balance between designers & engineers. Adding one guy to your team to 'make this crappy looking prototype pop' isn't going to be very helpful for your users.

[1] http://fairpixels.pro

We have known for over twenty years that most problems with software come from the requirements phase.

We need to stop accepting that we are the guilty party and trying to get our house in order while the one next door is engulfed in flames.

The problem is not in how we track our time. In how we organize tasks, in how we deal with technical debt, long-term maintenance, engineering disputes. Documentation.

Our problem is in being ill-informed consumers of requirements information. In accepting it instead of sending it back to be done over and refusing to start on anything other than basic R&D until it's sorted. If people aren't told in a clear manner why what they've done is wrong how will they ever improve? And if they know we'll do it anyway, why would they bother changing?

Holy Christ, I'm like a Junior Dev and once got into an argument with the CEO of the conglomerate I work for after a town hall meeting about how agile was basically only gonna accelerate how poorly we research "the problem space" as I called it.

She replied that we weren't gonna do waterfall and that the data supported agile as the company wide prerogative.

I replied that what I was asking for wasn't necessarily waterfall, but I also had no other term to describe it, and so she shut down the conversation completely by going, "I'm sorry, but the data supports agile. This conversation is over."

It struck me at first as "What the fuck, seriously!?" but then I considered she probably wasn't the one who made that decision or pushed it, but also that I wasn't maybe being clear.

So it's helpful to hear that this a bigger issue throughout the industry from a vet Ave not just local to the company I started my career at and so have no other frame of reference

No offense, but this doesn’t read as a situation you should feel vindicated about. Engineering management is a complicated beast that the average junior dev doesn’t see all the dimensions, let alone the nuances of. Town hall meeting or not, the “CEO of a conglomerate” probably doesn’t want an admittedly inarticulate opinion on what project management style not to use, especially without a clear alternative being suggested.

I don't, and my coworkers laughed at me when I relayed that conversation to them, I feel vindicated the issue around requirements gathering, and the effect that has on development, isn't unique to my company.

The best justification I've heard for the success of approaches like Agile is that they slow the software development process down and give stakeholders a chance to adjust to changes.

If you ask a user what they want, their answer depends on how their current system has developed. Maybe there's a good idea that they hate because in the current system it would require too great a compromise. Maybe there's a terrible idea that they love, because they haven't understood the horrible corner-cases.

The real strength of the agile approach is to help the customer figure out their requirements through experimentation, instead of asking them to deduce everything from first principles. Once everybody understands the actual requirements, the actual implementation should be fairly straight-forward, engineers can comfortably make design trade-offs, etc.

Of course, there's a lot of cargo-cult Agile, and buzzword-compliant Agile, and that might be more trouble than it's worth, so it's not a guaranteed cure-all. Even good agile can be ruined if the customer or management doesn't see the value, or doesn't understand the core "refine requirements through iteration" rule. Your mileage may vary, but that core idea is still a good an important one.

Yeah that was always how it was sold to me too. But then the Dark Times came.

It still works a bit that way, but the parts you can really see are all of the metric dysfunction. And I blame Schwaber for setting this avalanche off. Of all of the Agile processes, Scrum seems to have the most surface area for attack by metric dysfunction.

I didn't think I'd end up missing Jeff de Luca so much. He banished story size estimates a long time ago, making Scrum feel like a step back to me. I've only recently heard of people rediscovering that you only have to split up stories that are 'too big' and you can still do fairly accurate estimates and projections based on the aggregate behavior of 100's of stories.

What I see missing or unstated in virtually every discussion is that time isn't the constrained resource. It's energy. There are lots of tasks I could complete in half an hour, but the strain of doing so would still mean I'd only get 2 things done that day. There are also things I can do in 4 hours that still leave me spent for the day. And plenty of managers who will try to make you question your self worth for not volunteering to do 2 of those things in one day because 4+4=8.

Think about that the next time you catch yourself on Hacker News and you scold yourself for wasting time. I'd lay even odds you're either recuperating from something you just finished, or frustrated by something (or being blocked by something) and taking a break.

Think about it when you're trying to articulate why you accepted 60 hours of work this week because they're trivial stories with a lot of wait time built in. They're trivial because they're intellectually and emotionally 'cheap' tasks. There are boring tasks that take every fiber of your attention and you will refuse to double up on those.

Because it's energy, not hours. Always has been.

And you know what else takes a ton of energy and social capital? Arguing with some fucknut about whether a story is 3 points or 4.

I love this idea. But I fear I’ll be shot for executing it. :)

I've found that ideally all product changes should be developed in close collaboration between a product owner, a UI/UX-person, and a developer. The design shouldn't be made upfront and handed to the developer, it should be made iteratively with the developer providing feedback. And the same goes for the product owner, giving input about user needs and their mental model. The developer should provide feedback about what is feasible and easy instead of just being expected to code up a design that's thrown over the wall. If you allow any of these parties to do most of their work before the others, then you'll get a local optimization that will either constrain the others to do sub-optimal solutions for their areas, or force the final result to break out of the optimum from the first area. The best result comes by having each side provide input in each iteration. Getting a team to work like this is rare though, in my experience - I guess that's part of what makes unicorns so valuable, since they'll integrate several of these roles in one person.

> All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion.

What other opinion are they supposed to "lean towards"? Their boss' opinion is the only one that actually carries any sort of authority -- you implement it whether you agree with it or not.

Haha! It is not us it is the engineering team blaming culture

> After analyzing the user engagement statistics of apps that switched from semi-hidden navigation within hamburger menus to more visible bottom navigation bars, and apps that switched from more exposed to semi-hidden navigation, Wroblewski saw a trend. “Navigation is the manifestation of what is possible in an app and when people can’t see what’s possible, they likely won’t know what they can/should do in that app,” he told me in an interview about this idea. Increasing visibility boosts usage.

They have this highly data-driven process which optimizes for usage and engagement . The problem is I don't wake up in the morning and go "gee I really want to up my engagement with google maps today". The ideal information retrieval app consists of me retrieving information and closing it. This is antithetical to Google's monetization model, and thus Google Consumer design is not for my benefit.

That said each Google Product is like a different company and they do do good work here and there. Specifically the Google Cloud Console has improved tremendously over the years (no doubt due to massive investment). Is it perfect? Hell no. But I prefer it to AWS and Azure tremendously.

Gmail and the consumer apps seem to be too data-driven to the point where the numbers are a self-fulling prophecy. Of course engagement goes up when confusion and bloat are added and users struggle to get things done.

You're right about the GCP console which is well designed (although still slower to load than AWS or Azure). Clearly they have different metrics there.

Conversely, I’ve found the GCP console extremely confusing to navigate.

> They have this highly data-driven process which optimizes for usage and engagement . The problem is I don't wake up in the morning and go "gee I really want to up my engagement with google maps today".

Might explain parts of my experience with Android ;-)

> They have this highly data-driven process which optimizes for usage and engagement. [...] The ideal information retrieval app consists of me retrieving information and closing it.

Seriously, having to hunt for the features I actually need would seem to increase usage and engagement. Is that really the metric employed?

Then when Gmail lead designer leaves Google, you get this simplified / more usable Gmail UI design by them.

https://chrome.google.com/webstore/detail/simplify-gmail/pbm...

Which looks like more layers of interaction hidden behind icons, and less text, basically the opposite of what the main article is recommending.

Not only that, but they've way over-simplified their UI in other areas where they actually sell services to the point where I can't even find basic setting menus because they've been eliminated from the main page and it takes me 10+ minutes as a highly technical user to try to find a simple thing like current billing prices or invoice records. Just awful.

The adwords management app might be one of the worst designed pieces of business software I've ever used.

Google Analytics was also full of strange decisions and unnecessary complexity.

I guess they don't get the good designers on their B2B stuff either.

If I was in charge of the gmail team my first goal would be making it faster. It always feels clunky when you need to open gmail.

> Google Analytics was also full of strange decisions and unnecessary complexity.

Presumably, Google Analytics would be big on dogfooding… which is probably a sign that analytics-driven development isn't quite as useful as it's been touted to be. It's probably got great engagement metrics though!

A sign and possibly a reason.

Was going to say the same.

Similar experience with using Google Docs. Literally cannot figure out how to go to back to the document folder. I moved to Heap Analytics because the Google Analytics experience was so confusing and nested - I'm much happier now.

This is especially funny given that the "basic HTML view" is clear and relatively clutter free. I find it superior in almost every way, yet it's posed as the lesser alternative you have to cope with if you don't have JS or a fast connection.

You're not wrong. Some of Google's products do have UX problems. But that doesn't mean that the author's thoughts on this are wrong.

Maps isn't about maps anymore, it's a location database that happens to show a map sometimes.

If you want an actual map with useful map features like showing street names then OSM is a far better product.

I don't get me started on how gmail has been filtering the content of emails. I wonder how many services have been spam blocked because google decided to hide the unsubscribe links.

While I agree about Google Maps, I'm not so sure about Gmail.

Take your example:

- Forward is in the lowest toolbar in the hierarchy, since it applies to a single e-mail.

- Archive is in the top toolbar in the hierarchy, since it applies to a whole conversation.

Does this mean there are no improvements possible? Of course not, but I think the UI choices in Gmail are mostly sensible.