Changing button alpha value v button text colour to indicate current button status

Question

I'm working on an old iOS app which requires updating. This app requires users to make selections from various screens. For example, the user needs to make two choices on the main screen before proceeding. In all cases the choice is made by tapping a button to choose their selection. By default (upon launch), the first choice looks like this:

At present, when the user selects a topic, the app changes how the other buttons appear by halving their alpha values. See below for example:

My concern with this approach is that it isn't obvious to the user they can still change their selection by choosing another topic (i.e. tapping another button), because to me the other buttons now have a 'greyed out non-selectable' look to them. This concerns me as whatever approach is taken will be adopted throughout the app, so the issue will be repeated.

However, others argue that my concern isn't valid because users will quickly discover they can change their selections and will know that's how the app works.

Now, assuming my concern is valid, I see two ways of addressing this:

• change the text colour of the selected button, for example from white to yellow and leaving the alpha values of all buttons unchanged, so that all buttons still appear identical except for the text colour of the chosen button, or
• change the alpha value of only the selected button, rather than all of the unselected buttons, so that it's the one that has the 'greyed out non-selectable' look to it

In summary, my question is:

- How valid is my concern?

- Assuming it is valid, what would be the preferred option to address is it?

Please don't feel limited to my two solutions - happy to consider others as well.

Answer 1

I think that your concern is completely valid, especially if this is a user's introduction to the app. As Steve Krug points out, not making the user think is a fundamental part of User Experience design.

Letting the user learn through trial and error can be okay, but not when it goes against what they traditionally already know. You're using an existing design pattern that means something else. That is, disabling other options after one is selected is a very common way to show that selections are mutually exclusive, which is not the case at all in this situation.

A much better way of doing this, in my opinion, is to stick with what is used in many other apps and web apps, and that is to show that the chosen category is selected.

Think about it, what you basically have is a checklist, and the way that you show that something is selected in a checklist is to put a check next to it. There are many different ways that you could do this in your app - a border around the button when it is selected, an actual check on the button when it it chosen, you could change it's position on the screen.

This pattern also let's the user know that they can change their selection. If you show something is selected, it's much easier to recognise that it can be unselected. If you disable everything else, the user is still not 100% certain that what they chose is selected, just that everything else doesn't look like it can be chosen.

There are a ton of reasons why this is a strange way to do it, and another would be that on the first screen the user sees that if a button is 100% alpha, then it can be clicked. In the second screen you are saying that now buttons that are lower in alpha can be clicked - like why would you change the look and behaviour that you have just shown the user.

Mate, I hope this helps to back you up, the current design pattern is not great at all. Opt for changing the selected item in a 'checklist' rather than all the other items.

Answer 2

I agree that those buttons look like they're not able to accept any user interaction when their alpha values are lowered. I'd suggest not changing the alpha values at all. Instead, scale up the button that is selected, and scale down the other buttons.

For example:

Or, as suggested by @BrettEast, implement some kind of checking system.

For example: