Zelda and Bad User Interface Design

2025/Mar 10

I’ve been playing The Legend of Zelda: Breath of the Wild and its sequel Tears of the Kingdom lately. Both are excellent games (if perhaps an acquired taste in some ways) but there’s a common criticism to the latter which I think is emblematic of an attitude common in computer power users—one where they demand a solution to a perceived problem without considering how the proposed solution might make things worse.

In Breath, the player can wield a bow and various different kinds of arrows which each have unique effects like setting a small area on fire or exploding on impact. The player switches the kind of arrow they have equipped by holding a button on the controller and tilting a stick to select which arrow to shoot. Tears has a system with similar results but with a greatly different implementation—all arrows are plain without secondary effects, and instead the player has the ability to fuse items onto their arrows while nocked in order to gain access to those secondary effects. To fire several incendiary or explosive arrows in a row, the player needs to manually fuse new material onto each arrow before firing.

This may sound like a downgrade, but it’s not.

The first big weakness of Breath’s system is that the player needs to find arrows which are pre-enchanted with an effect. Often, certain types of arrow will be useless to you, so they will pile up in your inventory while you run out of the kinds of arrows you most frequently use. Certain arrows interact with the environment in unique ways before you even fire them, and if you’ve forgotten which were equipped you may experience unplanned setbacks. Fire arrows don’t work in rainy weather. In hot weather, bomb arrows will explode immediately after being readied, making for occasionally frustrating combat experiences.

Tears opts instead to optimize for the happy path by always defaulting to plain arrows. To fuse materials onto arrows uses a similar quick-select menu as in Breath, but because of the significant number of materials available, scrolling through the menu can be significantly time consuming. It can take over a minute to scroll from one end to the other if the player’s inventory is stuffed full of a variety of materials. Because of this, players often assert that Tears would be much easier to play if they could pre-select a list of favourite materials to use.

Of course, Tears has a better solution already implemented. One which provides much less friction for the user. Its quick selection menus can be sorted with a single button press. In the case of the materials selection menu, the player can sort by item type, item power, and by “most used”. The last category simply orders items by how many times they’ve ever been used by the player. The materials used for illuminating dark areas, the ones for igniting flammable objects, as well as bomb flowers, are all likely to stay at the top of this list for most players. This is not only because these materials are frequently used, but also because they are among the first that the player will obtain in the game as each are featured in the game’s tutorial area. The brilliance of the “most used” sorting is that because most other materials won’t be used more than a dozen times, players who want to pin something new to the top of the most used list can simply use said material a few times to pin it to the top. And so, by the properties of how the menu already works, the player’s favourite materials (i.e.: those which they favour using) are always easily accessible. Better still, because this sorting is dynamic and responds to player input, if ever some material becomes unnecessary, it will begin dropping down to lower positions in the list as other materials overtake obsolete ones in usage.

So, why do players ask for a favourites function? If the ability to use materials was subject to a favourites menu, players would need to put in the extra work to manually select their favourite materials. In the design of computer application user interfaces, the technical term for this phenomenon is “shit work”, which is when an application asks the user to do things that aren’t directly applicable to the problem they are trying to solve. As has been written elsewhere, many users state that they like to do this kind of work, but it never gets them anything they actually value. My understanding is that shit work is like any kind of work in that it’s intrinsically rewarding in some way, so doing shit work causes the user to feel like they’ve been productive even if they haven’t materially produced anything. This is an annoyance for conventional computer software, but it’s a death knell for video games where players should be engaging with core gameplay systems.

Want to know why many Nintendo games lack character customization options? It’s shit work, and Nintendo wants you to actually play the game instead of getting your avatar just right. Even for their titles which do feature character customization, initial options are intentionally limited by the developer so you’re not hemming-and-hawing over minutiæ which are simply not relevant to your gameplay experience.¹

Swinging back to Tears for a moment, an especially puzzling aspect of the common request for a favourites menu is that another of Tears' gameplay mechanics—“Autobuild”—does have a favourites menu. Programmers and designers took the time to make sure that the player could set structures they’ve built in the game world as favourites. In this case, asking players to manually set structures from their history as favourites doesn’t constitute shit work. Autobuild’s history can only contain a certain number of entries, and each individual change to any structure causes that change to be committed to history. Given the complexity of structures which can be built, having a “most used” option for sorting history also doesn’t make sense. Even Autobuild is quite careful not to overload the user with shit work, given that there’s only eight available slots for favourites.

Because they implemented a favourites system in one area, the developers likely spent a lot of time considering whether to implement it in others. Another consideration is that because this is such a common feature request, it was likely suggested by multiple members of the team during development as well. There are many very good reasons why software developers would avoid adding features to their projects, especially in a video game which revolves around creative problem-solving. To make a problem-solving game work properly, it needs to avoid inducing decision paralysis from presenting too many choices at once. I think Tears of the Kingdom does a fantastic job of this, and having really given the problem some thought I’m quite certain that any “easy fix” would have made the game a much worse, more frustrating experience.