Les utilisateurs devraient-ils pouvoir tout personnaliser ou l'équipe UX devrait-elle décider pour eux?
Je développe deux interfaces pour mon produit qui permettront aux utilisateurs de personnaliser un widget de réservation qu'ils placent sur leurs sites. L'une consiste à choisir les couleurs des éléments du widget. L'autre est de concevoir le formulaire que leurs clients rempliront.
Mon état d'esprit est que les utilisateurs préfèrent la facilité d'utilisation à la personnalisation. J'ai débattu de cela, mais certaines personnes de l'équipe disent simplement de les laisser changer ce qu'elles veulent.
Pour la sélection des couleurs, je veux proposer des thèmes prédéfinis et avoir des choix personnalisés limités.
Pour le générateur de formulaires, l'application a besoin nom et email. Je veux rendre cela immuable et même pas mobile. Je ne pense pas que le nom et l'adresse e-mail devraient être ailleurs que sur le dessus. Pour le bien de mes clients. Comme ça:
Encore une fois, il y a un débat au sein de l'équipe sur le fait qu'ils devraient pouvoir faire ce qu'ils veulent. Je ne peux pas imaginer pourquoi le nom devrait être le dernier champ du formulaire sur la liste, mais je ne suis peut-être pas assez imaginatif
Alors ... Permissivité maximale ou l'équipe UX sait le mieux?
Quelqu'un a-t-il une expérience où il en a trop offert? Ou offert des choix limités uniquement pour que les utilisateurs en veuillent plus?
Le problème de la permissivité maximale, comme vous le faites remarquer, est que les utilisateurs peuvent alors faire des choses qui sont vraiment médiocres, et qui, dans une certaine mesure, vous feront réfléchir.
En règle générale, laisser l'utilisateur personnaliser est une très bonne chose à faire, cependant, ce ne sont pas des utilisateurs, ce sont des clients. Il y a une différence, car un utilisateur fera les choses comme il le souhaite POUR EUX-MÊMES, tandis qu'un client le fera pour tous les utilisateurs. Les chances sont que leur style ne conviendra pas à tous les utilisateurs.
Fournir un ensemble de modèles qui sont globalement OK du point de vue UX devrait donner aux clients un sentiment de flexibilité, mais garantir que les utilisateurs ont quelque chose d'utilisable. Gagner, gagner, OMI.
Les formes sont une bête délicate et peuvent être dangereuses entre de mauvaises mains. Nous utilisons Google Docs au sein de notre entreprise, et la quantité de formulaires internes qui sont envoyés avec des cases à cocher où il devrait y avoir des boutons radio et vice-versa. Je serais très prudent de donner trop de contrôle à l'utilisateur non formé.
L'approche que je prendrais est de discuter avec votre équipe et les utilisateurs finaux potentiels, des types de questions auxquelles il faudrait généralement répondre. Je voudrais alors simplement répertorier un ensemble de ces questions facultatives qui peuvent être activées à l'aide d'une case à cocher booléenne. De cette façon, les libellés des étiquettes, etc. sont tous soigneusement rédigés et fabriqués par un professionnel (vous). Le choix est donné, mais ce n'est pas un libre-service.
Verrouiller les champs obligatoires est génial, et bon pour vous de le faire.
Quelques observations de votre filaire: je me rends compte que c'est probablement un travail en cours, mais comme vous avez présenté une maquette, je vais donner mon opinion honnête. Je ne suis pas fan des astérisques pour marquer un champ comme obligatoire. Ils n'ont aucune signification contextuelle ou sémantique, et sur la maquette, vous n'avez pas présenté ce que signifie l'astérisque. Je suis beaucoup plus proche de l'approche de Luke Wroblewski pour gérer cela avec un message d'introduction .
Tous les champs sont obligatoires, sauf indication contraire.
Maintenant, je sais que vous donnez aux utilisateurs la possibilité de définir si un champ est obligatoire ou non, vous pouvez donc définir une logique de sorte que si plus de champs facultatifs sont définis qu'obligatoires, le message change en conséquence. Ensuite, les champs qui sont opposés au message auront "facultatif" ou "obligatoire" entre parenthèses après l'étiquette.
Enfin, examinez attentivement si la présence des étiquettes dans les champs de texte est la meilleure approche. Si le formulaire a le potentiel d'avoir un certain nombre de champs, augmentant sa complexité, vous améliorerez probablement l'utilisabilité en plaçant les étiquettes en dehors des champs de texte. Un guide approximatif: les étiquettes en haut des champs sont pour des informations connues et une saisie rapide avec un contour des yeux linéaire, les étiquettes alignées à gauche sont pour des informations simples mais inconnues auxquelles nous devons penser, les étiquettes alignées à droite peuvent être discordantes sur le mais ils sont bons pour ralentir l'utilisateur et vraiment le faire réfléchir aux informations qu'il entre.
La réponse courte:
Votre approche est juste.
Le long:
Où vous savez ce qui est le mieux (comme mettre le nom/e-mail en haut) - ne laissez pas vos clients choisir. Si je comprends qui sont vos clients, ils sont plus susceptibles de nuire à l'expérience que de l'améliorer en changeant de domaine, soit par accident, soit en faisant de mauvais choix.
La personnalisation de l'image de marque est importante, mais encore une fois - les "webmasters" qui l'utiliseront ne sont probablement pas expérimentés avec des tons de couleur assortis. Je suis donc d'accord avec l'approche thématique. J'irais avec ~ 15 pour obtenir des teintes assorties pour votre client, y compris quelques neutres (blanc, gris, noir ...)
Offrez à vos utilisateurs une flexibilité logique.
Par exemple. laissez-les décider:
- Que ce soit pour la sélection, ils veulent des zones de liste (plus d'options visibles à la fois) ou des zones de liste déroulante (prennent moins de place)
- S'ils veulent le prénom et le nom côte à côte ou l'un sous l'autre
- Quel thème utiliser (noir sur blanc, blanc sur noir, autres ou personnalisé)
- La personnalisation est importante pour faire correspondre le thème du site d'hébergement, cependant, ne les laissez pas choisir des couleurs de premier plan avec un faible contraste par rapport à l'arrière-plan
- Rendez tous les champs obligatoires obligatoires, mais, si possible, laissez vos utilisateurs ajouter leurs propres champs et définir des champs supplémentaires comme obligatoires - ils peuvent avoir du sens pour eux
- Si vos utilisateurs ont des champs qu'ils peuvent traduire en nom et e-mail (par exemple, nom d'utilisateur, numéro de commande ou etc.), vous pouvez peut-être les laisser masquer ces champs obligatoires
En ce qui concerne les choix de couleurs: créez un nombre limité de thèmes prédéfinis mais permettez ensuite aux gens de changer les couleurs individuelles via un sélecteur de couleurs. De cette façon, vous les aiderez à choisir la couleur, tout en laissant ouvertes toutes les possibilités.
Je pense que la meilleure option dans ce cas est de fournir des maquettes de deux scénarios possibles et de les mettre en évidence pour le client tout en expliquant pourquoi vous pensez que la conception devrait tendre vers vos choix. Finalement, votre client va utiliser l'application, il devrait se sentir à l'aise avec elle et s'ils décident de suivre une certaine approche, assurez-vous de mettre en évidence les avantages et les inconvénients et laissez-les prendre la décision.
Bien sûr, vous pourriez vous retrouver avec un cas comme Myspace qui a donné aux utilisateurs la possibilité de personnaliser complètement leurs profils, ce qui a entraîné des mises en page vraiment déroutantes, mais il est intéressant de noter que c'est ce qui a permis à Myspace de rester aussi longtemps, alors donnez-leur le choix et un avertissement si ils prennent la route alternative.