Unless the dev has the authority to make the decision, what he should really do is explain the tradeoff: “Hey marketing, I know you want this feature, but it’s gonna cause us to drop down in Google results. Is it still worth it?”
My argument was that it is a rational business decision to sometimes constrain your developers by making them use what the users will.As the upper comment said people at Google often propose. If you do not, then they get utterly out of touch. I didn’t say you have to do it all the time.
How much of this is “nudging” vs. “clearly explaining trade-offs”?
I’ve not done any rigorous research, but I’ve participated in projects that resulted in dramatic shifts towards customers choosing what the dev team thought was the “best” outcome, just by altering wording, or making “dangerous” choices harder (such as by requiring more clicks to enable).
It is a business decision. Deliver a feature faster to 99.9 percent people as opposed to later for 100 percent. Neither is right in all scenarios which makes the whole argument pointless without specific scenario. There's a slider you can move with support percentage and time efforts required to make it happen. It is about balancing trade offs. Taking one fixed stance will just make you inflexible.
Some people view things like this as lip service but in my experience it definitely helps to have a principle like this down in writing. There were many times during my career at Google (2015 to 2021) where we were at an impasse around an ambiguous situation and I successfully persuaded my co-workers to pursue a painful/unpopular option by arguing that that option most closely followed Google's #1 principle ("focus on the user and everything else will follow"). In DevRel this happens all the time: the thing that creates a better experience for end users often also creates more pain for the developer (e.g. accessibility, i18n, load performance).
I think this proves quite the opposite. As a developer, you can decide if you want to change your users' default search engine (which will probably annoy them a lot), or do anything you want. It's a platform.
It’s funny how google and other sites just can’t imagine a world where people don’t want their crap.
I’ve been in product design meetings where it seems product managers earnestly say “it’s better for users, so we’ll just prompt them until they realize it’s a good idea.” It was odd to have a conversation where they couldn’t contemplate user wishes contrary to their own.
To push back, it does seem like you care. You've created rationalizations and offer them up unprompted. I think most people would argue for allowing both settings and having the app default to the one the internal research found more preferable and more profitable. Not offering the setting is telling.
Well if it were designed as an earnest feature, it would go on the side right? I can't imagine any UX pro saying 'let's plop this right in the middle of their requested content'. So I see it as pretty cynical. Any time software says 'I know what the user wants more than they do' I tend to think that's a mistake. But I think the consequences of this sort of thing plays out over a long period of a time. Maybe past when some executive leaves for a new job.
> as opposed to the usual "we want this feature [no one asked for] to be used more so we gave it more exposure [at the expense of the UX]"
This is just how business works, you like to steer users to features that will make them spend more. Wikipedia has been able to side-step this because it's a non-profit.
"Let's face it: developers start to rely on new features the moment they're added."
"So this is a huge win for us, the developers."
There's a contradiction here, and I'm not being cute. Your argument is not the only argument to be made, and personally, as a developer, I preferred the old way.
Yep, there are negative externalities, and that always has to be weighed, but I think it was a reasonable approach to allow developers to weigh the use of cutting edge features against their own communities, needs, and goals. That calculation would change depending on how many browsers were offering a proposed recommendation and the browser proportions of your viewers. Lots of interesting stuff was posted around the web, including here, taking advantage of these things. On the other hand, there's virtually no community for whom it would be reasonable to ask to make config changes to view a site, so you you simply can't use cutting edge features. Experimental site designs will be harder to show off and we'll have less public consideration of the implications of new recommendations since there's much less joy in putting together projects that few people will see.
I certainly believe that being given the option would be a significant improvement. How you execute that appropriately is better answered by a UX expert which I'm definitely not!
> No, I'm pretty sure users want more knobs or at least filter options.
Nah, 90% either don't or wouldn't use them if they were there.
Sure, if you ask people directly if they want more options, they'll say yes, who doesn't want more choices? But that's a different thing from actually using them when they're available. The vast majority of users for a utility service like a search engine just go with the defaults.
"...but if you’re not familiar with it then enjoy the research and storytelling of Barry Schwartz who discusses how too many options can not only lead to your customers making no choice, but (counter-intuitively) resenting the choices they do make."
That's very true. And I think the best compromise/solution is to hide advanced features/choices so that one click will still produce a great result, but if someone needs more options that ability is still there.
> Or how when you X one of those panels on some topic you have no interest in and it says "Got it, message hidden" then pops back up in a few days?
And
> Clicking X means NO.
While clicking X might mean No for all circumstances to you, that doesn’t mean it a the same for everyone else.
To handle more variety, you really want at two affordances: “never” and “not now”.
Note, when a user turns a feature off (your “never” case), now whenever you change that feature all the users who turned it off will now be left behind, even if the change or improvement would be appealing to them. So now you need a way to communicate the changes (even though they said “don’t show this feature”) and a way to change that preference.
reply