Is it a bad practice for a required switch to start without having any option checked?

Question

I currently have several (required) components in a form, in which I must select only one option (of the 2 that exist). The previous designer used a switch, however the first time none of the 2 is selected by default, this because the client indicated that he did not want to give priority to one, then I do not know if it is a good practice and if I should change for another component, for example a dropdown

Answer 1

There are several way to handle this, based on the constraint you describe in your reply to my comment (thx!)...

If your users must be forced to select the currency in which they want to conduct each transaction, the picker needs to be reset to an indeterminate state, with a directive label "Select currency // Seleccione moneda" at the completion of each cycle, i.e. when finishing a transaction. The effect would be that for each newly initiated transaction the currency selector is primed to a currency agnostic state (it forgets whatever currency was chosen the last time).

Consequently the user has no choice but to pick a currency each and every time. This should drastically reduce the opportunity for error, but at the cost of decision slowdown roughly proportionate to the number of choices presented - a classic example, if memory serves, of cognitive load theory.

The design of your control therefore needs to facilitate decision making depending on the number of options to pick. I'll scale this from few to many.

A Couple of Currencies

If the number of presented choices is 2 or 3 and recurrent selection is mandatory, present all choices at the surface - not in a dropdown picker - perhaps as a button row for lateral navigation, and in a neutral state each time.

| Dólares | Pesos MX | Soles |

This can be a highly compact header on the first (or only, depending on the scope of your app) transaction page, with remaining content disabled pending currency selection. It's basically a three-way toggle that always starts in a neutral state.

Half-a-Dozen-Plus Currencies

If the number of presented choices is between 6 and 9 and recurrent selection is mandatory, I would still present all choices at the surface. If this is a mobile app, make that a dedicated page with a directive on top ('Select currency: // Seleccione moneda:') and a stack of tiles with currency names below.

Lists of max 9 items are easily scanned by most human brains, and fit well onto a smartphone screen without scrolling. Even in a desktop environment, such a list is easy to consume, and items can be presented as generous click (or tap) targets.

In a mobile app you can now trade-off between error-proofing and speed.

If you lean toward error proofing, enhance the fact that this is a one-of-many choice - i.e. quasi radio button behaviour - by prefixing all currency name with a void circle (in the page's start state) that fills up when a tile is selected, which also activates a previously disabled 'Continue' button (works in English and Spanish!) at the bottom of the tile stack. This makes the currency selection a learnable, dual tap, pick-then-confirm, type action.

If you lean toward speed, have a single-tap tile selection propel your app to whatever page follows, and consider offering a 'Return // Regresar' button on that following page to allow for inadvertent (and hopefully rare) error correction.

In a desktop or tablet version you can make that list the left-hand column of a master-detail type layout: Both the currency selection and the rest of the page remain visible, and you may even alter the currency choice. This should leave your user in no doubt about the criticality of that selection each time, while making the choices easily navigable - and forgiving of errors.

Long Currency Lists

If your range of choices is longer, things get interesting. Many standardised choices like country, language, and currency selection already exist as canned, self-contained pieces of code (perhaps even as OS assets) which developers will be understandably keen to re-use. While cutting down dev cost, always a thing, that approach will require pushing a few UX extras - and an assertive stance by you, the designer - to maintain usability.

Think about allowing the user to declare favourites or most frequently used among a generic list of currencies. At the least, those should pop to the top of the (otherwise presumably alphabetical) list. Better would be to allow users to build a proprietary, down-selected, quick-pick sub-list which can then be presented by the methods I describe above. This could be done in the form of an introductory tour of the app, or as part of a user profile setup process. Better still would be a function where the app learns user behaviour and preferences and creates a quick-link list behind the scenes. The aim of all of the above is the same: To reduce decision load when needing to select among currencies on a repetitive basis.

Lastly, you may want to consider a convenience for those of your users who really only ever conduct transactions in one currency: To actually memorise one single currency and set that as a default choice. That cohort of people, if it exists, will get immensely annoyed by having to traverse a selection process that is utterly nonsensical and redundant to their needs.

As a last error-prevention measure you could locate a short confirmation phrase next to the call-to-action (if you have one) with which you complete the transaction. So - in proximity to 'Commit transaction // Confirmar transacción' you present them a reminder 'Currency selected: [US dollars] // Moneda seleccionada: [Dólares EEUU]'.

Best of success! // ¡Buen exito!

Answer 2

It depends on the use case.

If is there a default option for the situation then that should always be your switch's default state. In your case the most used currency (in your country / application) could be selected, so most users won't need to switch. Less effort for the majority, instead of everyone having to switch.

Unless there's a reason to draw attention specifically to that switch, some life-or-death option where there's a lot of responsibility involved in that choice. Or something that could cost the user a large amount of money if choosing the wrong option.