And the solutions are?

If theres one thing I'm absolutely sick of, it's people declaring these catch all arbitrary 'rules' that they reckon everyone needs to follow.

It's odd that in a world where by some poor designer decides to redesign facebook, they get shot down by people saying 'But what about the businesses case? What about the user research? What about the constraints from tech/compliance etc? Why do you think you know better than the entire facebook design team?

But yet, frame your invalidated, arbitrary ruleset entirely outside of a project, with no appreciation of all those things listed above, and people don't call you out on that.

You'll hear people shouting about things like dribbble, for example, with similar arguments 'Whats the point of this? it shows no context', 'this is just shiny visual design created entirely outside of any actual project reality', 'this is a nice idea, but it wouldn't work in the real world'.

Write your rules that you've created outside of any project reality and that are simply 'thoughtful UX design ideas' (ie. the same as 'Shiny visual design') that won't work in the real world and all the people who make those arguments suddenly forget how strongly they feel about context and applaud you for your thinking.

This sort of catch all 'UX thinking' is dragging design down. It creates 'lowest common denominator' design solutions that 'designers' without the ability to ask questions or think critically blindly follow. Then, all the visually inept UX types that came up with it have the audacity to suggest that 'all visual design looks the same', seemingly oblivious to the massive part they played in that by condensing design down to sticking together a load of patterns that someone else defined rules for.

The most interesting thing about this article is how Information Foraging Theory flies into the the face of a basic principle of product design. When we're designing a thing, we consider the user goals and tasks and put them into a hierarchy, both visually and structurally. The things that people don't do often get de-prioritized and often, put into overflow menus. The core tasks get put front-and-center.

But according to Information Foraging Theory, this is backwards for an information- and resource-seeking organism. Humans pick up on the scent and based on how promising it is, we continue down that path and stop when the scent doesn't grow in value. When you look at it from that perspective, you'd reverse the hierarchy; low-value stuff (e.g., gazelle tracks) come first, leading ultimately to high-value stuff (e.g., a tasty gazelle). There's a logic to this that makes sense.

But we aren't on the savannah any more. Humans are designing the experience now. We put the high-value stuff—the gazelle—up front because we know that's what you ultimately want. You want to eat not hunt. But there's the rub: we as designers have to understand a person and their goals first. I think that's what the "hard decision" talk is about. We have to understand what a person's goal is and not consider other things. You wouldn't need an overflow menu because you've focused in on what really matters. If you have to sense information in some way and track it down, we're reverting to animal instincts and the design has failed.

I'll also echo this opinion from Matt Bond:

"Frequency of use isn’t always a great measure for this kind of thing. There’s a ton of admin-like features in products that might be rarely used, but, when they are needed, you really need them to get you out of a jam. You’re right that designers don’t make enough hard calls about what is essential. I think there is a compelling counter argument to be made for making actions possible but not prominent. Unfortunately the default pattern for this is overflow menus."

Having features that are out of the way but still accessible by the user in the app's UI has saved us a ton of effort on customer support.

This used to be an Android-only pattern, but Apple's recently been doing it too, unfortunately.

But I get it. It's a convenient way of satisfying both business goals—“this feature needs to be in here“—and design goals—“I don't want to clutter the interface.”

We don't have to look far for an example of this issue on Design News.

...or how I ranted about a pretty valuable, widely understood design pattern because "search tools" and "more" are too close.

Google probably knows most people don't need to filter image results by size, and if there are a tiny percentage of ambitious users, they're probably willing to locate the filter by adding a tap or two.

Just speculating here, of course, but seems like a completely reasonable compromise short of making the interface overly complex for everyone.

Let me start by saying I understand the points, and agree with the fact that overflow menus are often sub-optimal. That we know.

But with all the other reasonable solutions and suggestions, this one I take to task:

"Force yourself and your team to make tough choices. This is really the point. Instead of pretending to make your product simpler, actually make the tough call to include or not include menu options. If something is important enough to include, show it to customers. One of the best parts of designing mobile-first is that you’re constantly forced to make tough choices about what to include and what to leave out (this is particularly true on iOS, which doesn’t have a built-in overflow menu in its toolkit). Take this as a challenge instead of a hampering constraint."

Now, I'm sure he means don't include unnecessary features in either version of the product, but his mention of mobile-first triggered me towards a very annoying reading of this mantra: when designers of the mobile version of a website make guesses about what I should be doing on my phone vs. on my laptop. (This is something I've been constantly struggling with on GitHub, but thankfully they're (1) Improving the mobile experience and (2) providing a way to see the desktop version of the website.) So, I remain unconvinced that "making tough calls" is altogether better than providing the workable albeit obscure alternative.

I'm all for thinking it through, though! And I believe this is what the author is advocating, after all, even if the article is a bit skimpy on specific solutions.