Premier tutoriel de lancement - Captures d'écran empilées ou bulles superposées?
Lorsque l'utilisateur lance pour la première fois notre application mobile, nous aimerions qu'il passe par quelques étapes expliquant les principales fonctionnalités/contrôles de l'interface.
Je vois deux possibilités:
- une série de captures d'écran empilées avec du texte, comme Gmail l'a fait pour la nouvelle version de Gmail il y a quelques mois
- une série de bulles superposées qui montrent directement les commandes.
Je crois en l'option # 2 car je pense qu'elle conserve beaucoup plus l'attention de l'utilisateur. Mais d'autres dans l'industrie plaideraient pour l'option # 1.
Que pensez-vous de cela et quelle version pensez-vous qui fonctionne le mieux?
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
J'irais avec quelque chose dans le sens de l'option 2 mais un peu plus axé sur l'utilisateur, la raison étant:
Les connaissances en contexte devraient être plus faciles à conserver que les connaissances initiales.
Il ajoute également une couche d'interaction , plutôt que de simplement cliquer sur
Nexts, demander à l'utilisateur de faire les interactions. A un impact plus profond - lisez un manuel de mathématiques par rapport aux exemples.
Mailbox a une procédure similaire.
- Liste d'autres procédures pas à pas.
Dan1111 a eu la gentillesse de le souligner: peu importe l'approche que vous adoptez, ayez toujours une fonctionnalité de saut en place pour permettre aux utilisateurs d'ignorer la procédure pas à pas .
En fonction de votre situation, option # 1 sera légèrement difficile à attirer l'attention des utilisateurs novices. De plus, ils perdront sûrement leur temps à comprendre le didacticiel lui-même.
Au contraire option # 2 sera toujours plus utile car l'utilisateur n'a pas besoin de beaucoup d'efforts pour comprendre ce qui se passe exactement. Ainsi, dans ce cas, l'utilisateur sera plus confiant d'utiliser le système car il interagit avec le système dans le didacticiel lui-même.
Les utilisateurs experts trouveront toujours une façon ou une autre d'utiliser l'application. Ce sera toujours mieux pour que les novices/débutants restent concentrés lors de la conception du système.
Le 2e est meilleur, je pense. Non seulement à cause de l'attention des utilisateurs, mais aussi parce que les utilisateurs commencent également à savoir où se trouvent chacune des fonctions. Ils pourront le rappeler plus tard.
Un autre endroit utile pour les petites aides informatives est les listes/espaces vides. Celles-ci sont plus délicates sur mobile - en plus de cela, ce n'est pas vraiment un guide pour la première fois, mais un guide jusqu'à la première utilisation d'une fonction. C'est un aspect de l'utilité des espaces vides (un peu plus sur ce sujet: http://tympanus.net/codrops/2013/01/09/designing-for-the-empty-states/ )
Sidenote: J'ai vu beaucoup de cartes d'intégration qui ne sont là qu'à des fins de marketing. Je n'aime pas ceux - qui veulent acheter quelque chose sans même l'essayer :) Un autre problème commun avec les cartes est que même les utilisateurs qui pensent qu'ils sont intéressés les parcourent et les oublient presque immédiatement. L'excitation d'essayer une nouvelle application réduira l'apprentissage.
Je préfère # 2 mais j'ignore généralement les tutoriels. La plupart du temps, ils soulignent l'évidence, par exemple l'icône d'engrenage correspond aux paramètres. Ou pire, marketing ordinaire. Cela me rend généralement furieux.
Les bulles ne devraient donc introduire qu'une nouvelle fonctionnalité. De plus, la création d'une application utilisable réduit de toute façon ce besoin de tutoriel.
Point # 2 en outre, nous ne devons afficher que les éléments de la page d'accueil dès le départ et une fois que l'utilisateur a commencé à utiliser cette fonctionnalité, de manière appropriée, nous devons afficher plus de détails liés à ces fonctionnalités une fois qu'il a atterri sur cette page, plutôt que d'afficher tous les détails à l'avance dans la page d'accueil .
Supposons qu'une application comporte 2 éléments sur la page d'accueil et une icône de paramètres en haut. Nous pouvons afficher des paramètres et deux autres icônes. Mais après que l'utilisateur a commencé à l'utiliser et lorsqu'il passe à la fonctionnalité A, lors du lancement pour la première fois, nous devons donner une superposition.
Un gros avantage de option 2 est que vous vous n'avez pas besoin de lire le texte pour savoir de quel tutoriel parle. C'est plus visuel et vous voyez exactement où se trouvent les commandes. Cela semble plus engageant. L'application iPhone Path a fait quelque chose de similaire. Je suis d'accord avec le commentaire de @rk selon lequel il est bon d'ajouter une option de saut, car les utilisateurs ne veulent souvent pas suivre de didacticiels.