Stateful button color: Showing current state vs showing effect

There’s one small section on one of my levels that causes slightly more confusion than I’d like. It centers around what seems like a ubiquitous problem in the design of “toggle” buttons. Specifically, players can press a button to lock/unlock a door. For example:

Normally, this is fine. But in this particular part of the game, the player tends to be a bit stressed/distracted, and I assume the cognitive load contributes to the problem. But the issue is that the state of the button reflects what will happen to the door when it’s pressed, while the state of the door reflects, well, it’s current state of locked or unlocked.

What seems to be happening if some players will interpret the color of the button itself to be the state of the door lock, instead of being result of what will happen when pressing the lock.

This seems similar to a problem that comes up in design all the time with toggle button. “Wait, is that toggle on or off?” I’ve considered whether it would make more sense to switch the button colors around. But for me, in general, it seems extremely strange to press a “green” button to lock a door. In isolation, the colors seem reasonable. It’s only when placed side-by-side that the confusion creeps in.

Anyway, just curious if anyone has any general ideas on the topic.

Yep, I see the confusion. Such toggles are a well-known UI problem. (Although I disagree with most of the advice in the article I just linked!)

One simple solution would be to change the label from “Door Control” to “Press to Unlock”. I know, I know, users don’t read, but they do scan, and such a 3-word phrase is short enough to be scanned and absorbed. When the door is unlocked, of course, it should read “Press to Lock”. I think that would eliminate any confusion.

2 Likes

I like it, and that’s a simple change to test out. I’ll give that a try and see if people still get hung up there. Thanks.

To me locker icon describes the current state of the door.
Is clear enough I would say. Padlock is unlocked, so door is too. Or locked in contrast.
Description is a bit uneccessery, some players are not native English speakers.
But saying that, instead door control, if that bother at all, I would put locked / unlocked text.

Usually, I agree. The only time it is a problem seems to be when players are under pressure to think fast. Then they mess up. So, I think people agree this makes sense to them when they think about it, but their instincts betray when the pressure is on.

I may consider a toggle button, just for this one part, since it’s the only place this is a problem. Maybe that will help, maybe not. :slight_smile:

There is something like muscle memory effect.
If you play a game in this case, thing become automatic, without putting a though.
So player after playing some time, i.e. hours, will be train to react on icons, and doors behaviours.

You don’t even need text. No one will have time to read, if expect that fast mechanics :slight_smile:
To read, you need get close enough. Which is missing the point of icons. Purpose of the text is just for training purposes. After couple of games, it become pretty much useless, for that particular player. Unless other control panels confuse, if is affecting door, or some other device. I.e. having multiple same panels next to each other. But that game design issue, unless is meant to be puzzle.

Think about RTS games.
Each faction has dozen of unique buildings and units. They can be identified by icons. But they have also written cost, description of functions and values of properties. i.e. health, damage etc.
Now, if you play game long enough, you learn using units and buildings without thinking much. But taking right combination of units and buildings. Even better players learn key bindings. They become rapid fast, in executing command. RTS is good example here, as it is very fast peaced gameplay.

So to be honest, saying that someone can not learn and mistake about door locker meaning, it is a bit off. :slight_smile:

Well, this isn’t a case where players will do this section over and over again, and develop muscle memory, or get used to it. Nearly all of Gravia is a linear experience, where you’ll go through a section once, and never return. There are many mechanics that you learn and reexperience over and over, but sometimes there are one-off experiences. So, those need extra care in their design, since I don’t have the benefit of repetition on them.

Again, this is all really fine-tuning. It’s not a big issue, just a minor…wrinkle, that I’d like to smooth out. :slight_smile:

You could use an arrow, with the current state on the left and prospective state on the right.

A–>B

I think that’s a little clearer than the current system, but I don’t know that it would be much better in the heat of the moment. At the very least it avoids text.

1 Like

Just wonder, do you have only one, or few rare doors in whole game? Is just special door?
I would assume, you may have multiple such doors, across multiple levels. So the feature is just reused often. But if is indeed something rare to be found by player, I see why you concern about the lock mechanics.

That’s a very interesting idea, which I don’t think I’ve ever seen before. Kind of sounds like starting with a sliding toggle button, but then unambiguously adding two more buttons to clearly identify the states. I’ll look into it. Thanks for the suggestion.

There are several doors like this in the game. The only thing “special” about this one is that it’s the only one the player interacts with while they’re under a time pressure. Usually players casually walk over to a door, press the button, go through, and its fine. But in the case where the player is stressed and in a hurry, because they don’t have much time, it seems that instead of relying on observation and reasoning, they rely on instinct. And “instinct” don’t seem to work well with the entire “stateful action button” topic in general.