"We'll fix it in UI"

It's a running gag in the entertainment industry that people say, "We'll fix it in post." Whether it's with Auto-Tune or Photoshop, creative disciplines seem to love correcting problems after the fact. Speaking at the Game UX Summit in Toronto today, Bungie UI designer David Candland said it's also common for developers to say "we'll fix it in UI," when user interface is ideally a way of enhancing a player's experience rather than a crutch for teams to polish games in the final stretch.

Good UI is like telling a joke, Candland said. If you have to explain it, it's probably not very good. A common mistake for developers is that when something is particularly complex, they will pause the game and throw up a text-heavy tutorial dialog window. Nothing disrupts the flow of the game more than this, Candland said. He pointed to the brilliance of the level design in Super Mario Bros.' first level, how the player is given hints, clues, affordances and opportunities to learn how to play the game as they go along. It makes for uninterrupted game flow, but also makes the player feel smart about discovering how things work. But if Super Mario Bros. paused the game to explain how to attack Goombas, it tells players that the designer doesn't feel they are capable of understanding these things and is talking down to them.

In some cases, features are complex enough that they might require the paused tutorial approach, Candland said. Destiny 2 features several of them, in fact. But he believes there are many times where designers have better alternatives if they'll just think through the system and discuss it with the UI team.

Candland isn't completely opposed to tutorial boxes, but they're not always ideal, and come with their own problems, especially with players determined not to read them.

When working on the Desitny 1 UI, Candland heard about a new feature going into the game, the Vault of Glass end-of-game raid. He went to talk with the designer in charge, Luke Smith, to ask about what new UI features would be needed to pull the feature off. He was quite surprised when Smith told him, "If we're successful, we won't need any UI for this feature."

Smith wanted players to go in with no preconceived notions about what to do, but figure out the mechanics of the raid through clues, context, and affordances, coordinating with each other to accomplish the goals. When there's a failure in the experience and the fire team dies, there would be hints and clues in the stats displayed during the post-game carnage report. Candland said the act of discovery for players became nearly as rewarding an experience in the Vault of Glass raid as the loot they would receive for successfully completing it. It's a bit counter-intuitive for a UI designer to celebrate the team not needing him to create a UI, but Candland said there are lots of occasions where developers can achieve their goals without new elements.

As for when UI is the best option, it doesn't always have to be through a tutorial screen. Visual cues in animation can be one solution that doesn't interrupt the flow of play, but also happens repeatedly through the game and reminds players who need it, as opposed to a tutorial box which generally appears once and is never seen again. Candland isn't completely opposed to tutorial boxes, but they're not always ideal, and come with their own problems, especially with players determined not to read them.

During the original production of Halo, Candland and another developer were watching a playtesting subject try out the Phantom hovercraft. At first, the vehicle controls were displayed in the top left corner of the screen, but people didn't seem to read it in time. So instead they flashed it up in the middle of the screen and left it there until players followed a prompt and pressed A to make the box go away. But to their horror, one playtester refused to read the box and played through the entire level with the overlay in the middle of the screen, only to later ask the developers if there was any way to make the box go away. (Candland said they literally facepalmed at the question.) The solution they wound up shipping with was to pause the game until players pushed the button to make the box go away.

In later games, Bungie tried a countdown timer on text-heavy screens before making the option to skip the screen available. But then players became focused entirely on the countdown and still didn't read the text. Now when the developers need to convey more information to players between missions in Destiny, they give it to them in smaller chunks, and animate it onto the screen in a gradual fashion. There is still a time limit before players can skip, but the animation and manageable amount of text have led to better reading and retention.

"Any time you receive a fairly prescriptive request to just do X, you really need to find out why."

Just as developers would listen closely to playtesters but perhaps not implement their suggested fixes to problems, so too do UI designers need to be wary when developers tell them not just what the problem is, but how to fix it. For example, Candland received a bug report about the difficulty button on a pre-mission briefing screen, along with a suggestion to make it pulsing because nobody was clicking on it. Unwilling to resort to some gaudy bells and whistles that would detract from an otherwise clean design, Candland considered that the actual problem might have been where the button was placed. He moved it to a better place on the screen that he was confident would address the problem, but after implementing the fix, it didn't seem to make a difference.

Ultimately, he realized the problem was about how the button was labelled. The button described the selected mission's difficulty, but didn't take into account the player's level of play. So the same mission that was considered normal difficulty for a level 2 player would still be listed as normal difficulty to a relatively over-powered level 20 player. The answer was to switch the difficulty listing to tell the player how hard the designers thought the mission would be relative to their player level.

"Any time you receive a fairly prescriptive request to just do X, you really need to find out why," Candland said. "What are the goals this is trying to accomplish?"

Specific bug fixes aren't the only things developers ask for that UI designers should think twice about. At a larger studio, every developer likely thinks the most important new feature going into a game is the one they're working on, Candland said. That often leads to a special request from a designer who wants the feature to bubble up in a special way, possibly through a shortcut on the main menu. Sometimes it's valid, but oftentimes he said it would fit comfortably within the standard information architecture, and it can create confusion for the user if you put it in a special place apart from that. Giving a feature a special placement can also create a battle of oneupsmanship, where every new part of every new feature needs its own unique callout.

"When everything is uniquely loud, the clarity and usability of the original product are diminished," Candland said.

It's important to include feature stakeholders in discussions early on in pre-production so that everyone's on the same page about what will and won't be in the game's main interface from day one, he added. That's not always practical, especially in games with microtransactions that need to be highlighted. In that case, Candland suggested building in a specific part of the menu designed to always feature the latest, cool new thing.

The big takeaway from Candland's talk was that having an embedded UI designer on the team working on any new feature from the beginning can help head off problems before they arise. UI works best when it helps shape a positive experience for the players rather than tries to mitigate problems that arose because UI just wasn't properly considered along the way.