0

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 enter image description here

  • Could you please let us know if none can be an option? – Omkar Chogale Aug 15 at 14:27
  • It'd be good to have a better idea of how many there are in the form, and what the nature of the form is. – Ben Paddock Aug 15 at 14:34
  • @OmkarChogale No, you still have to select an option – Kely Martinez Aug 15 at 14:46
  • @BenPaddock There are several extensive forms distributed between 3 to 5 steps that will be used by financial representatives in a bank. If you ever purchased a product at a bank, you probably know the amount of information required. – Kely Martinez Aug 15 at 14:50
  • Then first design looks ok. Drop-down hides options and increase motor load – Omkar Chogale Aug 15 at 14:54
0

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!

  • Thank you very much, love everything you wrote! – Kely Martinez Aug 16 at 19:40
0

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.

  • Strongly agree, the reason why you do not want an option marked by default is that those who use the application make daily transactions very quickly and there have been many cases that having an option marked by default have not been noticed and have finished the operation realizing after the small detail that they omitted. And well, at the margins of that, it is something that the client is demanding :'( – Kely Martinez Aug 15 at 14:57
  • @KelyMartinez in this case it should be empty to force the user to consciously choose one of the currencies. I'll edit my answer to reflect that. – Luciano Aug 15 at 15:19
  • This reminds me of my own question I asked some years ago ux.stackexchange.com/questions/101684/… though I feel this one is more focused on the switch component. While it is rather common for a select list to be empty, it is not so common for a switch not to have a state. A real world switch does not have an "unknown" state either (assuming it does not have a middle option - which the digital switch also doesn't have). – User42 Aug 16 at 11:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.