Devrions-nous être conscients des problèmes de bande passante compte tenu des récents changements de tarification des forfaits de données?
Récemment, il a été signalé que les fournisseurs de services mobiles ont décidé de modifier les modèles de tarification de leurs plans de données (à savoir Verizon et AT&T, mais peut-être même d'autres; frais par GO des données utilisées). Personnellement, je n'ai aucun problème avec cette façon de penser - c'est le capitalisme, c'est comment ça fonctionne et c'est bien. Mais en tant que concepteur UX, je ne peux pas m'empêcher de penser pour le bien de l'utilisateur final (naturellement).
De façon réaliste, il est relativement difficile d'utiliser 2 Go de trafic pour l'utilisateur mobile moyen; J'en suis pleinement conscient. Mais qui peut dire que ce ne sera peut-être pas une réalité un jour? Ce qui pose question:
- Que se passe-t-il si votre application/site Web est considéré par ses utilisateurs comme un moyen de réduire leur allocation de données?
- Pensez-vous qu'ils continueraient à utiliser votre produit?
- Que pouvons-nous faire pour éliminer la possibilité, s'il y en a une, qu'un utilisateur pense que nous gaspillons les ressources pour lesquelles il paie?
- Cela signifie-t-il que nos produits devraient devenir encore plus simples, nécessitant des charges plus petites et des expériences plus courtes?
Je suis curieux de savoir quelles sont les pensées d'individus partageant les mêmes idées. Ce sujet retient-il l'eau, et sinon, peut-on prétendre qu'il en est ainsi?
Pour la plupart des utilisateurs, les sites Web et les applications ne consomment pas la part du lion des données - les médias le font (en particulier la vidéo en streaming). Et quand il s'agit de sites Web simples, la plupart des utilisateurs sont naïfs de toute façon. Ce qu'ils vont remarquer, cependant, c'est un site Web à chargement lent, et c'est la vraie raison pour laquelle vous devez profiler la taille de votre page.
"plus simple" est un peu un terme chargé. Je pense qu'il vaut peut-être mieux dire "pas inutilement complexe".
La réponse à cela, bien sûr, est "bien sûr". Il ne faut jamais rendre l'expérience inutilement complexe. Mais notez que la complexité de l'UX n'est pas nécessairement corrélée à la bande passante utilisée. Une interface utilisateur vraiment facile à utiliser pourrait en fait nécessiter du javascript sophistiqué, etc.
Donc, je pense qu'une meilleure question - en termes de plans de données - est de demander:
Devrions-nous être conscients des problèmes de bande passante compte tenu des récents changements de prix des forfaits de données?
La réponse est oui, mais pas seulement en raison du coût. Nous voulons toujours rendre nos sites Web et applications aussi petits que possible pour les rendre rapides et réactifs. Cela coûte moins cher à l'utilisateur final n'est que la cerise sur le gâteau.
La réponse honnête est que cela dépend.
Pouvez-vous fournir une expérience simplifiée qui servira toujours l'objectif de l'utilisateur sans utiliser trop de bande passante? Si cela est possible, fournissez à l'utilisateur la fonctionnalité pour désactiver éventuellement les fonctionnalités qui pourraient utiliser trop de bande passante tout en fournissant une interface simplifiée mais efficace qui fait toujours le travail. Par exemple. Google Courants le fait bien car par défaut, il ne télécharge pas les images des articles de presse, mais permet à l'utilisateur de définir l'option de modifier le paramètre si nécessaire.
Si votre application fournit un service qui utilisera beaucoup de bande passante (par exemple des vidéos en streaming, de la musique), prévenez que le service peut avoir besoin de beaucoup de bande passante et que les utilisateurs sont responsables de garder une trace de l'utilisation des données (je pense que Pandora le fait cette).
Cependant, si vous voulez vraiment être très prudent dans ce dernier cas, vous pouvez travailler à la conception d'une fonctionnalité qui garde une trace de l'utilisation des données et arrête le service lorsqu'une limite prédéfinie a été définie (par exemple, 3G Watchguard)