Pourquoi ne sauvegardons-nous pas automatiquement les utilisateurs au lieu de les faire enregistrer manuellement?
Avec l'avènement de Apple passant à la sauvegarde automatique dans sa dernière version Lion, tout le monde devrait-il commencer à adopter la convention de la sauvegarde automatique?
Au début, c'est vraiment gênant et l'utilisateur peut sentir qu'il a moins de contrôle, mais s'il est largement adopté, cela pourrait faciliter la vie de tout le monde. Bien sûr, nous devrions toujours offrir une option de type "Enregistrer sous" ou "Créer une copie" pour leur permettre d'enregistrer manuellement une copie.
Y a-t-il des obstacles techniques/de performance importants concernant la sauvegarde automatique et sinon, devrions-nous tous commencer à adopter la technique de sauvegarde automatique?
Si nous (Windows et autres plates-formes) n'adoptons pas cette nouvelle convention, cela créera certainement un écart encore plus grand entre les utilisateurs Windows et Mac. Les personnes qui n'ont utilisé que des Mac ou qui ont grandi en les utilisant à partir de maintenant ne seront pas habituées à économiser. Les utilisateurs de Windows seront rendus fous par les Mac (certains pas tous) car ils voudront constamment économiser.
Inspiration tirée d'une réponse sur icône Enregistrer, l'icône de la disquette est-elle morte?
Dans Marketo, l'application enregistre automatiquement tout. Nous avons très peu d'actions "Enregistrer".
Cependant, effet secondaire intéressant. Dans l'éditeur de messagerie, certains utilisateurs étaient tellement paniqués qu'il n'y avait pas de bouton "Enregistrer et fermer", que nous en avons ajouté un. Il est déjà enregistré, le bouton ne fait que fermer la fenêtre, mais il a fait disparaître les plaintes. Nous avons des commentaires généreux disant que les informations ont été enregistrées, mais cela n'avait pas assez d'importance.
C'est vraiment une question de confiance. Le système m'a-t-il entendu? Suis-je sûr que je suis sûr?
De manière générale, notre service commercial considère qu'il s'agit d'un avantage majeur dans la conclusion de contrats.
Bien que les objections techniques soient en grande partie obsolètes, je pense qu'il y a toujours une objection basée sur l'UX à l'enregistrement automatique. D'autres réponses ont fait allusion à la relation entre le contrôle de version et l'enregistrement automatique. @sova en parle comme alternatives, mais je pense que ce sont des compléments essentiels. Sans versioning (ou au moins persistante, annulation traditionnelle), la sauvegarde automatique a un inconvénient potentiel important.
Dans un modèle d'interaction basé sur un document, toutes les modifications apportées à un document sont temporaires jusqu'à ce que le document soit enregistré. La possibilité de fermer sans enregistrer offre une capacité d'annulation granulaire, car l'utilisateur peut toujours revenir à la dernière version enregistrée. Cette forme d'annulation a une utilisation très médiocre par rapport à une annulation/restauration même de style CTRL-Z/-Y, mais elle offre toujours aux utilisateurs un filet de sécurité "bouton de panique". L'enregistrement automatique retire cette option aux utilisateurs. Sans un remplacement convaincant, cela peut sans doute être une perte nette de sécurité des données.
Google Docs et la nouvelle fonctionnalité de version d'OS X Lion fournissent une forme alternative et plus puissante d'annulation/restauration basée sur une chronologie, plutôt que la pile d'historique de commandes traditionnelle. Les deux systèmes ancrent les versions à la chronologie et permettent à l'utilisateur de faire passer l'ancien état dans le présent en tout ou en partie. C'est bien mieux que le retour en version unique fourni par un modèle de document de sauvegarde manuelle. Cela supprime les inconvénients potentiels de l'enregistrement automatique.
En combinaison, l'enregistrement automatique et l'historique des versions basé sur la chronologie fournissent une excellente expérience utilisateur. L'enregistrement automatique sans versioning est une bénédiction mitigée.
Addendum
@ andrew-neely me rappelle un autre cas important. De nombreuses transactions commerciales ont une transition importante entre la saisie et l'exécution des données. Le modèle de document est inapproprié dans ces situations et une autre métaphore doit être utilisée. Cependant, il est toujours possible de se protéger contre la perte de données.
Par exemple, un système peut être conçu pour restaurer l'état de l'interface utilisateur lors du redémarrage après un crash ou une panne de courant. L'utilisateur peut alors choisir d'annuler ou de poursuivre la transaction sans répéter la saisie des données. Le stockage de l'état de l'interface utilisateur est une forme d'enregistrement automatique, mais cela serait transparent pour l'utilisateur.
Un mécanisme d'historique basé sur la chronologie est également un peu moins approprié pour les interactions d'édition actives dans cette situation. L'annulation/restauration plus traditionnelle peut être mieux adaptée à un UX avec de courtes interactions transactionnelles. La courte durée signifie que la gestion d'une pile de commandes sera moins lourde, et la nature transactionnelle signifie que revenir en arrière après un point de transition peut ne pas être possible dans tous les cas.
La gestion des versions dans un système transactionnel serait toujours possible, mais elle prendrait un caractère différent. Au lieu d'afficher l'état complet de la transaction à chaque point lors de la modification, il peut se concentrer uniquement sur les modifications persistantes et les présenter comme une séquence de transitions d'état dans un journal d'audit. Une transaction n'est pas tant un artefact en soi qu'un symbole d'un processus en cours. Un journal des transitions reflète mieux cette nature de workflow actif.
C'est en partie historique - lorsque sauvegarder signifiait renvoyer des données au serveur, c'était une opération coûteuse, et quand cela signifiait écraser ce que vous aviez déjà sans la possibilité de le restaurer, il devait être sous le contrôle de l'utilisateur.
Cependant, maintenant avec des données enregistrées localement ou avec des connexions à large bande passante, il n'y a pas de surcharge dans la sauvegarde. Le contrôle de version vous offre des fonctionnalités de restauration.
Google a déjà enregistré automatiquement dans Google Docs, et maintenant avec Apple se déplaçant de cette façon, il y aura une tendance générale à enregistrer automatiquement partout. Si c'est à suffisamment d'endroits, les gens commenceront à l'exiger.
Je soupçonne que Microsoft l'intégrera avec la prochaine version d'Office - après tout, OneNote enregistre déjà automatiquement, et Word, etc. enregistre déjà automatiquement, mais uniquement dans un fichier temporaire. Le faire enregistrer dans le document réel est la prochaine étape logique.
Un domaine où cela peut prendre plus de temps est celui des applications de bases de données où les enregistrements doivent être complets pour être valides. Les sauvegardes partielles sont possibles, mais ce n'est pas aussi simple que quelque chose comme un traitement de texte ou même une application de feuille de calcul.
Il faut du temps pour que des choses comme celle-ci se frayent un chemin jusqu'à chaque application.
J'ai deux problèmes avec l'enregistrement automatique.
Tout d'abord, modification par inadvertance (erreurs): Si un utilisateur affiche un document à afficher et fait une erreur, la sauvegarde automatique écraserait la bonne copie avec les données invalides et obligerait l'utilisateur à prendre des informations supplémentaires. actions pour annuler l'erreur.
Nous avons un système de saisie de données qui a été conçu avec sauvegarde automatique, et je ne peux pas vous dire combien de fois les enregistrements sont endommagés parce que le focus d'entrée de quelqu'un était dans la mauvaise fenêtre, et ils ont écrasé les informations. Il est vrai que le contrôle de version et la restauration peuvent atténuer ce problème, mais cela complique le système, augmente les exigences de stockage et ajoute des fonctionnalités supplémentaires que l'utilisateur doit apprendre à utiliser.
Deuxièmement, manque de contrôle: J'aime l'idée que l'utilisateur écrive volontairement des écritures. Je suis tout à fait d'accord pour l'enregistrement automatique dans un fichier temporaire et pour demander à l'utilisateur quand il est sur le point d'abandonner les modifications, mais je veux que l'utilisateur dise "Oui, je voulais le faire".
L'enregistrement automatique suppose que vous souhaitez enregistrer en premier lieu. Il y a des moments où des données sont entrées dans un programme sans intention de les conserver.
Exemple 1 Je lance parfois un traitement de texte pour vérifier l'orthographe d'un mot, ou rechercher un synonyme pour un éditeur qui manque de telles fonctionnalités. Je ne veux pas conserver cette information.
Exemple 2 J'utilise souvent le bloc-notes pour stocker des informations temporaires que je ne souhaite pas conserver plus de quelques instants. L'enregistrement automatique me forcerait à nettoyer un désordre de ces fichiers sans raison valable.
Exemple Si je documente un problème avec un de mes subordonnés, je préfère le taper car mon écriture n'est pas très nette . Si j'utilise un traitement de texte, notre section RH ne veut que du papier et ne veut pas que j'enregistre le document n'importe où. Si j'enregistre le document, alors tout l'ordinateur (ou réseau) est ouvert à la découverte en cas de réclamation.
Exemple 4 Souvent, lors de la copie de données formatées d'une source à une autre, je copie les données dans le bloc-notes pour supprimer tout formatage , copiez-le à nouveau pour le coller dans le document cible. Je ne veux pas que ces informations soient enregistrées.
Alan Cooper et ses amis ont beaucoup à dire au sujet de toujours économiser, autorisant toujours l'annulation lorsque cela est possible/possible. Si vous ne l'avez pas déjà lu, vous devriez absolument vérifier About Face .
La première chose à dire lors de l'examen du meilleur scénario d'interaction avec l'utilisateur est que le logiciel doit toujours être enregistré automatiquement. Même ici, sur SE, mon brouillon est automatiquement enregistré lorsque je tape.
La deuxième chose à noter est la rétroaction non modale donnée. L'utilisateur doit pouvoir voir que tout ce sur quoi il travaille a bien été enregistré. Les documents Google le font mieux que n'importe quelle interface que j'ai jamais vue.
Troisièmement, la fonction "Enregistrer maintenant". Si je dois faire quelque chose, je ne veux pas attendre que le document clignote et que je viens de m'enregistrer, je veux savoir qu'il a été enregistré avant de continuer. Quelle que soit la météo, le logiciel sera certainement enregistré si je m'éloigne vers quelque chose d'autre ou s'il est fermé, je veux que le sentiment "Je sais que cela est enregistré".
Quatrièmement, au-delà de Enregistrer une copie, il devrait y avoir une fonctionnalité de renommage. Si vous avez un document Word ouvert et que vous voulez lui donner un autre nom, vous devez fermer le document, aller dans le fichier et le renommer. Cette fonctionnalité devrait être fournie là où je peux y accéder facilement.
Et enfin, vous devez toujours conserver la pile d'annulation entre les sessions afin que je puisse annuler à jamais même si je ferme le programme/navigateur, puis l'ouvre de nouveau dans trois mois et réalise que quelque chose que je ne voulais pas a été enregistré.
Je pense que les utilisateurs sont de plus en plus à l'aise avec la sauvegarde automatique et j'ai certainement été personnellement soulagé lorsqu'un programme se bloque et je sais que je n'ai rien perdu car toute la sauvegarde a été prise en charge pour moi. Donc, pour résumer, lisez la section À propos de Face à ce sujet et consultez Google Docs.
Tout le monde en parle d'un point de vue documentaire. Votre question indique "tout le monde devrait-il commencer à adopter la convention de sauvegarde automatique?" Je dois convenir avec les autres que si vous ne proposez pas de version, c'est inutile. Pour moi, en tant que photographe, la sauvegarde automatique seule serait la pire caractéristique qui ait jamais existé. Nous passons parfois des heures à "détruire" une image dans Photoshop pour découvrir que nous avons fait trop, tout mettre au rebut et recommencer.
Cela vaut pour tous les domaines créatifs auxquels je peux penser. Lorsque vous créez, vous expérimentez souvent et vous devez avoir la possibilité de revenir rapidement à l'original si vous réalisez que vous n'aimez pas ce que vous avez fait.
Et cela vaut également pour un éditeur de texte. Un écrivain qui supprime un paragraphe entier pour le réécrire doit avoir la possibilité d'y revenir s'il préférait l'ancienne version.
Donc, si vous voulez mettre une norme sur la sauvegarde automatique, vous devez également en mettre une sur la gestion des versions, ou cela créera plus de problèmes qu'elle n'en résoudra.
Je ne pense pas que cela ait été mentionné par quiconque, mais un cas où vous ne devez PAS implémenter la fonctionnalité d'enregistrement automatique est lorsque vous travaillez avec des fichiers ouverts à partir d'une clé USB. Bien que peu connus, les lecteurs USB ont un nombre très limité de cycles de lecture-écriture, parfois aussi bas que 3000-5000 (voir Wikipedia: lecteur flash USB) ). Si votre application enregistre souvent, disons toutes les secondes, elle détruirait essentiellement l'appareil de l'utilisateur en une heure environ.
J'ai créé de nombreuses applications Web et lorsque ce problème survient, je suis confronté à un ou plusieurs des problèmes suivants:
La construction prend plus de temps. Parfois, vous devez créer un modèle "Draft" en plus du modèle normal.
Il peut être difficile de rendre la sauvegarde automatique détectable; il n'est pas très utile d'enregistrer automatiquement pour un utilisateur et de lui demander simplement comment enregistrer ses modifications.
Quand les modifications vont-elles où dans l'application? Par exemple, considérons un carnet d'adresses versionné, où les versions antérieures d'une entrée d'adresse sont conservées pour voir les changements au fil du temps. Dans quelle mesure un changement doit-il être enregistré automatiquement et traité comme l'un de ces changements? Faut-il prendre plusieurs tranches au fil du temps et les regrouper en un seul changement plus important?
Qu'en est-il des autres systèmes qui utilisent ces données en parallèle - quand devraient-ils prendre ces changements? Par exemple, s'il existe un système qui utilise ce carnet d'adresses pour informer les utilisateurs des événements système - quand doivent-ils prendre en compte les modifications de l'utilisateur - que faire si l'utilisateur a une faute de frappe ou fait une pause au milieu de la saisie d'une adresse e-mail - si les systèmes qui utilisent ce obtenir cette entrée partielle et ne pas envoyer en conséquence?
Selon la façon dont l'application est utilisée, elle peut être nocive pour l'utilisateur, ou très difficile à construire d'une manière qui ne soit pas nuisible. Par exemple, si votre application modifie des documents de longueur arbitraire et qu'un utilisateur modifie un document de 100 pages sur un téléphone portable bloqué sur 2G, la façon la plus évidente d'implémenter l'enregistrement automatique va briser leur connexion. Il existe des approches de différenciation beaucoup plus complexes, mais celles-ci pourraient marteler leur faible processeur.
L'enregistrement automatique est certainement une fonctionnalité intéressante, mais cela peut souvent être une décision de conception difficile, et parfois un problème système difficile.
Le contrôle des versions est certainement la clé tant que la présentation des versions (horodatées) est claire pour l'utilisateur final. La question est donc de savoir à quel point il serait utile d'enregistrer chaque micro-modification en tant qu'historique de document. Eh bien, cela dépend si vous regardez les changements dans une session ou en dehors d'une session. La présentation de l'histoire devrait donc en tenir compte.
Fait intéressant, nous faisons cela depuis des années, mais cela a été masqué comme une expérience différente. Autrement dit, annuler vs enregistrer.
Lorsque vous regardez dans une session, l'utilisateur voudra probablement revenir en arrière à un niveau micro - c'est-à-dire chaque changement détaillé. Cela revient exactement à utiliser l'annulation avec l'historique d'annulation. La différence ici est qu'avec la sauvegarde automatique, la session est la période complète pendant laquelle le document a été ouvert. Avec l'annulation, la session est définie comme la période écoulée depuis la dernière sauvegarde. Tant qu'un utilisateur peut voir les modifications qu'il a apportées au cours de la session, il doit pouvoir annuler les modifications au moment voulu.
Lorsqu'il regarde en dehors de la session, l'utilisateur réfléchira très probablement en termes de périodes dans le temps et reviendra à une époque où il éditait le document et pas nécessairement à un point de changement détaillé spécifique. Il s'agit certainement de voir les choses à un niveau plus macro et devrait être présenté comme tel. Il est intéressant de noter qu'avec le concept de sauvegarde automatique, nous serons désormais en mesure de fournir une "nouvelle" fonctionnalité qui permet à l'utilisateur d'explorer un changement spécifique dans la session précédente s'il le souhaite.
Et en ce qui concerne l'applicabilité à la base de données par rapport au document: ce sont différents - il existe un concept de chronologie de "publication" qui doit être examiné. Lorsque vous envisagez la mise à jour du contenu d'un enregistrement de base de données, vous devez pouvoir les enregistrer automatiquement. Cependant, les enregistrements sont des ressources partagées et vous avez également besoin du concept de publication. Publier permet également à d'autres personnes de lire et de modifier ces enregistrements. Un bon exemple est un CMS où quelqu'un peut avoir à créer un nouvel article mais ne pas permettre que les modifications soient visibles immédiatement. Dites quand ils vont déjeuner ou se réunir à mi-chemin du montage. Ces modifications ne doivent être consultées par personne tant que l'utilisateur ne les a pas "publiées" (ou validées) sur le système, prêtes à être consultées par d'autres.
Pourquoi un système hybride n'est-il pas plus courant? c'est-à-dire que le document principal n'est enregistré que lors des sauvegardes utilisateur, mais une arborescence parallèle est conservée pour les modifications non enregistrées. Même après la fermeture du programme si l'utilisateur oublie de sauvegarder (ou dit que le programme plante, etc.), l'arborescence parallèle offre toujours une chance de revenir en arrière et de récupérer.
Avec un stockage si bon marché, le coût de l'enregistrement des modifications (en particulier de manière incrémentielle) est incroyablement bon marché. Je déteste particulièrement les logiciels qui renoncent à l'option Annuler après tout Enreg.
Un exemple de programme qui fait ce droit est Vim (l'éditeur).
PS. Un argument contre la sauvegarde automatique est sur les OS qui permettent à plusieurs applications/utilisateurs d'ouvrir le même fichier simultanément. Certains utilisateurs peuvent simplement visualiser et les modifications peuvent être accidentelles.
Mac n'a qu'une 15% de part de marché aux USA . Parmi ces 15%, seule une petite partie a OS X Lion, où la sauvegarde automatique a été introduite. Il y a donc très peu de gens qui seront à l'aise avec la sauvegarde automatique. Que l'enregistrement automatique soit une bonne fonctionnalité ou non, ce n'est pas une fonctionnalité populaire. La plupart des utilisateurs non-Lion trouveront cela étrange. L'omniprésence d'une fonctionnalité est tout ce qui compte dans la conception de l'interface utilisateur. Les choses qui peuvent avoir une bonne intention, mais qui sont inattendues, peuvent dérouter les utilisateurs.
Pour ma part, j'ai utilisé Windows toute ma vie. J'ai utilisé Mac à l'occasion, et je n'ai pas été à l'aise avec la sauvegarde automatique de Mac dans d'autres cas. Vous savez comment lorsque vous configurez les préférences sur n'importe quel programme, il n'y a pas de bouton d'enregistrement sur Mac? Je me demande toujours si mes modifications seront effacées lorsque je ferme cette fenêtre de préférences. Sur Microsoft Windows, cependant, les fenêtres de préférences ont généralement une application et sauvegarde bouton. Cela indique clairement si mes modifications seront enregistrées ou effacées lorsque j'appuie sur [~ # ~] x [~ # ~] ou annuler .
Encore une fois, je ne conteste pas la vertu de la sauvegarde automatique. Je souligne simplement que c'est avant-gardiste et peut-être pas prêt pour les interfaces utilisateur grand public. Aza Raskin , le principal concepteur d'interface utilisateur de Firefox, a déclaré que la seule raison pour laquelle les utilisateurs trouvent l'iPhone intuitif est que Apple a dépensé des millions en publicité. Presque tout le monde a vu des publicités de personnes utilisant l'iPhone. Maintenant, je ne vois pas Apple faire le même Push marketing pour la sauvegarde automatique de Lion. Ils n'ont publié que des didacticiels vidéo sur leur site Web, dont seul un petit nombre À moins que Apple fasse plus de marketing et que plus d'entreprises arnaquent Lion comme la façon dont presque toutes les compagnies de téléphone portable ont arraché l'iPhone, je ne vois pas cette fonctionnalité d'enregistrement automatique se propager.
À mon avis, le contrôle de version est une chose merveilleuse. Ce serait formidable d'avoir une arborescence de versions plus accessible à l'utilisateur final pour les fichiers que vous avez enregistrés.
Vous savez comment les boutons Annuler/Rétablir ne font qu’un pas en avant et en arrière? Si vous appuyez sur Annuler, puis changez quelque chose, vous ne pouvez pas revenir au "Redo" d'origine - c'est un gros défaut, et si vous parcourez la moitié de la chaîne de transactions et changez quelque chose, vous perdez effectivement la moitié de vos modifications!
La sauvegarde automatique est une excellente philosophie, mais la meilleure alternative, imo, est la sauvegarde en temps réel + un excellent contrôle de version.
Les développeurs devraient-ils commencer à incorporer la sauvegarde automatique dans tout ce qu'ils font jusqu'à ce que le contrôle de version stable basé sur le système d'exploitation (voyage dans le temps du disque dur) soit la norme? Absolument.
En bref, "cohérence et normes"/convention est une heuristique puissante. Et la perte de données est un puissant facteur de motivation.
La "sauvegarde manuelle" n'était pas le seul choix UX. Le Psion 5 était un appareil physique intéressant, mais l'UX de son logiciel était peut-être plus remarquable car il a choisi de prendre un chemin indépendant vers les interfaces utilisateur courantes de l'époque.
L'une des conventions de Psion était une sauvegarde automatique, avec un "retour à la dernière [version ouverte/sauvegarde explicite]" dans le cas où l'on devrait rejeter les modifications. Parce qu'il s'agissait d'un appareil autonome, il pourrait imposer ce nouveau paradigme. Les utilisateurs pouvant accepter comme périphérique étaient uniques et cette sauvegarde par défaut était une forme logique de fonctionnement. Au moins par rapport à la perte accidentelle de vos modifications.
Il s'agissait d'une amélioration logique par rapport aux processeurs Word de bureau courants de l'époque, à savoir 199). Lorsque la capacité de mémoire a amélioré le stockage sur plusieurs versions, c'est une amélioration logique de ce modèle "sauvegarde par défaut + retour".
Il est donc clair que tous les ingénieurs UX ne pensaient pas que la convention par défaut de l'époque était sage. Alors pourquoi "sauvegarde manuelle" a-t-elle duré 15 ans et plus? Convention et cohérence. C'est ce qui rend les utilisateurs nerveux face aux changements de comportement. Et les utilisateurs apprécient également leur temps, ils veulent donc être sûrs que les modifications sont enregistrées.
Qu'est ce qui a changé? De toute évidence, la gamme Psion et le logiciel Symbian OS qu'elle a engendré n'étaient pas suffisants pour influencer la convention par rapport au poids des applications Windows et Mac OS et des guides de conception de système d'exploitation associés à l'époque. Ce qui est nouveau, c'est AJAX applications. Ils avaient eu un canevas raisonnablement vierge dans les applications Web, et différentes contraintes (par exemple une connectivité peu fiable). En particulier, GMail a ouvert la voie. Notamment, cela avait quelques variantes de Interface utilisateur pour leur fonctionnalité d'enregistrement automatique.
Une fois qu'un nombre suffisant de personnes se sentiront à l'aise avec une nouvelle convention, le courant dominant pourra se rallier.
Je pense Ne donnez pas la priorité à l'efficacité sur les attentes du groupe Nielsen Norman articule beaucoup de problèmes avec la sauvegarde automatique, et un moyen d'atténuer certains des problèmes UX avec:
Les fonctionnalités destinées à accroître l'efficacité des utilisateurs en réduisant les étapes peuvent finir par nuire aux utilisateurs si elles ne sont pas conformes aux modèles mentaux existants et aux attentes basées sur les expériences passées.
Que manque-t-il à ce formulaire par ailleurs assez standard? Il n'y a pas de bouton Enregistrer! Comment appliquons-nous nos modifications afin qu'elles soient enregistrées dans le système? Les lecteurs avertis en informatique peuvent se rendre compte que le formulaire enregistre probablement toutes les modifications pendant qu'elles sont effectuées [...]. Cependant, la plupart des utilisateurs ne sont pas aussi avertis [...]. C'est un excellent exemple de la façon dont même le plus petit écart par rapport à une norme peut provoquer de la confusion et augmenter la charge cognitive.
En supprimant le bouton Enregistrer, les concepteurs ont sorti les utilisateurs du mode pilote automatique, car la tâche ne peut plus être effectuée conformément au plan. [...] les utilisateurs rencontrant ce formulaire doivent maintenant passer du temps à regarder autour de la page pour le bouton Enregistrer omis et relier cette nouvelle situation à toute autre expérience passée similaire afin de déterminer quelle action entreprendre ensuite. La réduction du nombre d'étapes ne se traduit pas par une réduction du coût d'interaction, car les utilisateurs doivent consacrer un effort cognitif à trouver une nouvelle procédure pour faire face à ce modèle moins courant.
[...] les utilisateurs veulent se sentir en contrôle. Le sentiment de contrôle ne peut se produire que lorsque le [...] système [...] indique clairement à l'utilisateur quel est l'état du système et comment manipuler l'interface pour changer cet état. Les utilisateurs doivent être constamment informés de l'état actuel du système [...]. Pour les utilisateurs, voir c'est croire: un retour visuel doit être affiché pour chaque processus entrepris par un système. Chaque action, de l'exposition du contenu caché à la communication de la progression pendant une attente, doit être clairement affichée afin que l'utilisateur comprenne ce qui se passe.
Supprimer le bouton Enregistrer réduit le contrôle des utilisateurs sur l'interface. Soudain, le site Web est une entité autonome qui décide de lui-même comment et quand faire les choses. Pour redonner le contrôle à l'utilisateur, le système doit montrer qu'il n'agit pas de son propre chef, mais qu'il répond simplement aux actions que l'utilisateur a initiées. Dans l'exemple NextDoor, plutôt que d'enregistrer automatiquement uniquement en arrière-plan, un retour visuel doit être affiché sur la page pour communiquer à l'utilisateur que les nouveaux paramètres ont été enregistrés lors de leur sélection.