Pour les applications web
Je me tiens sur l'écran de votre utilisateur. Je sais où se trouve chaque chose, et je peux cliquer dessus.
Vos utilisateurs ne lisent pas la documentation : ils posent des questions. Aujourd'hui, ils s'adressent à votre support, ou ils partent. Installez-moi dans votre application et c'est à moi qu'ils les posent : j'ouvre le bon écran, je change d'onglet de langue, je saisis le texte — et je m'arrête, la main au-dessus d'Enregistrer, jusqu'à ce qu'ils disent oui. Je sais à quel utilisateur je parle, je ne vois que ses données, et quand quelque chose mérite son attention sur un écran, je le signale avant même qu'il s'en aperçoive.
Essayez ici
Voici un écran d'application. Demandez-moi de le remplir.
Un formulaire ordinaire, comme il pourrait y en avoir dans votre application. Je remplis les champs, je choisis la formule — et je demande avant d'appuyer sur « Enregistrer ». L'enregistrement n'envoie rien : c'est une démo.
Voir comment je travaille dans notre propre panneau — après inscription →Préparer un formulaire comme celui-ci, pour les développeurs →Ce qui se passe dans une application une fois que j'y suis installé.
- « Montre-moi les factures de mars. »
Je connais vos écrans par leur adresse, alors j'ouvre le bon — avec le filtre déjà appliqué, quand votre écran en accepte un dans son adresse.
→ - « Remplis l'adresse de livraison avec celle de mon profil. »
Je regarde l'écran, je repère les champs, j'écris dedans et je dis à l'utilisateur ce que j'ai remplacé. Onglets, listes déroulantes, cases à cocher, curseurs, listes avec un bouton « Ajouter » : je les manipule comme le ferait une personne.
→ - « Enregistre. »
Non. Pas tant qu'on ne me l'a pas dit : un clic irréversible est mis en attente et soumis à confirmation, avec les mots de l'utilisateur ou d'un simple toucher. Ou bien vous m'indiquez, une fois pour toutes, que dans votre application je peux appuyer moi-même sur Enregistrer après avoir rempli un formulaire — c'est votre décision, pas la mienne.
→ - « Pourquoi le bouton Enregistrer est-il grisé ? »
Je lis l'écran et je réponds d'après lui : quel champ est encore vide, ce que dit la note à côté. Pour cela, je ne touche à rien.
→ - « Que dois-je faire ici ? »
Avant même qu'on me le demande : quand la vérification propre à votre application repère quelque chose sur cet écran — une configuration inachevée, un import qui échoue —, je lève la main dans un coin avec une seule phrase, une seule fois, puis plus rien pendant la durée que vous avez fixée.
→
</>
Je sais avec quel utilisateur je parle, parce que vous me le dites, comme vous le diriez à votre propre API.
Votre application me transmet le jeton propre à l'utilisateur lorsqu'il se connecte, et je le joins à chaque question que je pose à votre API. Ainsi, « montre mes factures impayées » désigne ses factures à lui, et je ne détiens jamais une identité que je risquerais de confondre. Le jeton n'est jamais stocké, jamais journalisé, jamais montré au modèle.
Sur un ordinateur partagé, la déconnexion me laisse vierge : la conversation, le souvenir de la personne qui était là, tout disparaît.
</>
Ce que fait votre développeur. Une seule fois.
- La même ligne de code que sur n'importe quel site.
- Décrivez-moi vos écrans. Chaque écran tient en une courte note dans votre tableau de bord : son modèle d'adresse (/orders/{id}), son nom et son utilité. Les routes avec identifiants ne posent aucun problème ; je renseigne l'identifiant d'après ce que l'utilisateur a demandé.
- Marquez le bouton qui enregistre. Un seul attribut sur votre bouton Enregistrer, et je sais ce qu'est une « validation » sur cet écran. Marquez un champ comme privé, et je ne le lis jamais. Tout le reste, je le déduis de la page elle-même — libellés, onglets, listes déroulantes — et plus votre écran est lisible pour un lecteur d'écran, plus il l'est pour moi.
- Présentez-moi l'utilisateur. Un appel à sa connexion, un autre à sa déconnexion.
Notre propre tableau de bord est construit exactement ainsi, et vous m'y retrouverez après votre inscription : demandez-moi de changer la couleur de votre widget, et regardez.
Le balisage, pour les développeurs →À quoi ressemble votre file de support au bout d’un mois.
Moins de tickets qui ne sont que des questions.
« Où se trouve… », « comment faire pour… » : la réponse arrive à l'écran, et c'est déjà fait.
De nouveaux utilisateurs qui trouvent leur chemin.
Sans visite guidée, sans appel, dans leur langue.
La liste de ce qui déroute vos utilisateurs.
Les questions auxquelles je n’ai pas pu répondre à partir de vos écrans, regroupées : c’est aussi la liste des écrans à corriger.
Ce que je lis à l'écran, c'est vous qui le décidez
désactivé par défaut, champs marqués uniquement, ou tout.
Ce sur quoi j'appuie, c'est encore vous qui le décidez
jamais, après accord, ou j'enregistre moi-même.
Les données de vos utilisateurs
arrivent à votre API avec leurs propres identifiants, pas avec les miens. Données et contrôle →
Growth
Pour une application, c'est la formule Growth.
Les écrans, les actions sur la page, votre propre API et la main levée sont inclus dans la formule Growth : 29 $ par mois, 7 000 crédits, 3 sites. Une application avec beaucoup d'écrans et d'utilisateurs aura plutôt besoin de la formule Pro.
Offrez à vos utilisateurs quelqu'un à leurs côtés, sur l'écran.
