Pourquoi les interrupteurs à bascule sont nuls (et ce qu’il faut faire à la place)

Il y a quelques semaines, j’ai été invité en tant qu’invité sur le podcast Complimentary animé par Katie Langerman et Anthony Hobday. L’un des sujets dont nous avons parlé était l’idée d’utiliser des interrupteurs à bascule (plutôt que des boutons radio et des cases à cocher).

Comme je l’ai dit dans le podcast, il y a définitivement de mauvaises raisons d’utiliser un interrupteur à bascule (ils sont cool, différents, amusants). La soi-disant bonne raison d’en utiliser un est que vous avez besoin que l’action prenne effet immédiatement.

Mais mon problème est que cela décrit le résultat. Cela n’explique pas pourquoi une action particulière doit prendre effet immédiatement en premier lieu.

Je peux penser à 3 raisons :

1. C’est plus rapide
2. Cela évite un rafraîchissement de la page
3. Cela évite le risque que les utilisateurs oublient de sauvegarder leurs modifications comme une étape séparée

Dit comme ça, vous seriez fou de ne pas utiliser un interrupteur à bascule.

Mais c’est le contraire de mon conseil.

Voici pourquoi :

Raison n°1 : Les utilisateurs peuvent ne pas comprendre si l’interrupteur est activé ou désactivé

Voici un écran de paramètres sur mon iPhone :

Remarquez comment la couleur et l’alignement sont utilisés pour indiquer si le paramètre est activé ou désactivé.

Mais si vous êtes daltonien ou ne savez pas ce que signifie l’alignement, vous êtes fichu.

Pourquoi faire réfléchir les utilisateurs quand ce n’est pas nécessaire ?

Vous pourriez mettre du texte à l’intérieur du bouton :

Mais certains utilisateurs pourraient penser qu’ils doivent appuyer sur le bouton ou déplacer le bouton à la position “activée” pour l’activer.

Enfin, vous pourriez mettre l’étiquette à l’extérieur comme ceci :

C’est mieux mais la plupart des interrupteurs à bascule ne sont pas conçus comme ça et il y a beaucoup plus d’inconvénients :

Raison n°2 : Les utilisateurs peuvent ne pas savoir comment les utiliser

Par exemple, certains utilisateurs essaient de faire glisser l’interrupteur vers la gauche ou la droite alors qu’ils devraient cliquer dessus.

Vous pourriez penser que c’est un problème mineur, mais mon approche est :

Éviter les frictions surtout quand il est facile de le faire en utilisant des modèles simples, conventionnels et accessibles (plus d’informations à ce sujet plus tard).

Raison n°3 : Le paramètre peut ne pas être enregistré

Parce que les interrupteurs à bascule doivent prendre effet immédiatement, ils doivent utiliser AJAX pour éviter le rafraîchissement de la page.

Mais si la requête est lente, il y a un risque que le système ne sauvegarde pas le changement. Cela pourrait être catastrophique ou simplement ennuyeux en fonction du cas d’utilisation.

Pour gérer cela, vous devez gérer les états d’erreur et de chargement :

Quoi qu’il en soit, c’est mauvais étant donné que la principale raison d’utiliser un interrupteur à bascule est qu’il prenne effet immédiatement.

Raison n°4 : Ils peuvent causer de l’incohérence

Ici, vous pouvez voir un écran de paramètres sur iOS :

Certains paramètres ont 2 options (et utilisent un interrupteur à bascule) et certains en ont plus de 2 (et n’en ont pas). Remarquez comment le Mode Avion est activé et le Wi-Fi est désactivé.

Mais ils ont des interactions complètement différentes.

Maintenant, j’ai généralement tendance à remettre en question “il doit être cohérent” mais si vous pouvez être cohérent, vous devriez l’être.

Raison n°5 : Ils ont besoin de JavaScript pour fonctionner

Si vous vous souciez de l’amélioration progressive (et vous devriez), votre interface utilisateur doit fonctionner lorsque JavaScript est indisponible.

Ce qui signifie que vous devez commencer par utiliser des boutons radio, des cases à cocher ou des boutons de toute façon.

Alors commencez par là et voyez comment vous vous en sortez (je prédis très bien).

“Mais les interrupteurs à bascule sont plus rapides à utiliser que les boutons radio !”

Cela peut être vrai si vous ne mesurez que l’interaction à partir du moment où l’utilisateur a décidé de cliquer.

Mais ce n’est pas vrai si vous mesurez l’interaction à partir du moment où l’utilisateur rencontre le paramètre pour la première fois.

La compréhension fait partie de l’équation.

De plus, avec les boutons radio, les utilisateurs peuvent regrouper leurs modifications en une seule fois, ce qui peut être plus rapide.

Donc encore une fois, commencez par les boutons radio et testez. Si votre formulaire est bien conçu, vous constaterez que la vitesse n’est pas un problème.

“Mais que faire si vous devez éviter un rafraîchissement de la page ?”

Le web est constitué de pages web. Lorsque vous en chargez une, la page se rafraîchit. C’est totalement cool.

Et généralement, lorsque qu’un concepteur essaie d’éviter un rafraîchissement de la page, cela crée toutes sortes de problèmes qui dégradent l’expérience utilisateur qui n’existaient pas au départ.

Mais parfois, un rafraîchissement de la page peut dégrader l’expérience utilisateur. Par exemple, disons que vous êtes dans un appel Zoom et que vous voulez activer votre micro. Rafraîchir la page signifie quitter l’appel Zoom.

Donc ici, j’utiliserais simplement un bouton basculant comme le fait Zoom :

Il a également l’avantage d’avoir une plus grande cible de tap et une étiquette claire écrite comme un verbe pour indiquer clairement ce qui va se passer.

“Mais que faire si les utilisateurs oublient de sauvegarder leurs modifications ?”

Je ne peux pas diagnostiquer celui-ci sans voir votre formulaire (n’hésitez pas à m’envoyer une capture d’écran).

Mais la réponse est probablement : gardez votre bouton de soumission à proximité.

Si vous souhaitez apprendre à concevoir des formulaires simples et accessibles sans jamais avoir à utiliser un interrupteur à bascule douteux, consultez Form Design Mastery : [Lien vers Form Design Mastery]

Apprenez à concevoir des produits numériques simples et accessibles sans le blabla

Rejoignez plus de 7000 designers, concepteurs de contenu et développeurs frontend qui reçoivent ma newsletter hebdomadaire gratuite avec des conseils de conception basés sur des preuves (en 3 minutes ou moins). Principalement sur l’UX des formulaires, mais pas toujours.

[Formulaire d’inscription]

Source de l’article