Si on veut vraiment bien faire les choses…

Je vous propose un petit exercice de style, visant à montrer en quoi, quand on fouille bien, l’analyse fonctionnelle pour un site n’est pas si simple que cela peut paraître.

Le sujet que je vous propose est le suivant :

« Je veux que l’internaute puisse accéder facilement à l’abonnement newsletter sur le site, qu’il soit client ou non. »

Comment gérer correctement l’abonnement à la newsletter ?

Quoi, c’est tout ?

Attendez, laissez moi avancer.

Donc, le site propose à plusieurs endroit l’option pour s’abonner à la newsletter.

Bon, mais quelle est la situation de l’internaute ?

• Il peut être identifié ou non ;
• Il peut avoir un compte ou non ;
• Il peut, s’il a un compte, être abonné à la newsletter ou non.

On pourrait traiter simplement le problème en proposant l’abonnement à la newsletter pendant le processus achat, ou pendant la création d’un compte. Mais ce n’est pas ce que veut le e-marchand, qui veut pousser l’abonnement, et le proposer à tout le monde, client ou pas.

Bon, autre solution simple : on crée une base newsletter séparée, pour inscrire les abonnements.

Bonne idée, simple effectivement, qui a un défaut majeur : on crée deux bases (newsletter et client), et cela limite la qualité du service. Exemple : on ne pourra plus proposer au client de gérer ses abonnements depuis son compte, puisque justement, l’abonnement n’est pas associé au compte…

Si on veut vraiment bien faire les choses, il ne faut pas séparer les bases, et prévoir plusieurs cas  :

1. L’abonnement est demandé, alors que le client n’est pas identifié

On peut proposer la saisie d’un email pour s’abonner.

Mais que faire si l’email correspond à un compte client ?

Le mieux est probablement de prendre la demande et l’associer dans son compte client : le client pourra gérer son abonnement depuis son espace client.

Si l’email ne correspond pas à un compte client, on peut le stocker dans une table à part. Si on jour ce client crée un compte, on pourra alors supprimer cette entrée dans cette table temporaire, et pré cocher l’abonnement.

2. Le client est identifié, et pas abonné

Euh, dans ce cas, à quoi bon demander l’adresse mail du client, puisqu’on la connait déjà ?

Bon, le client peut vouloir choisir l’adresse mail de réception des newsletters.

Si c’est ce qu’on veut proposer au client, on peut toujours proposer une adresse mail, mais on peut la pré renseigner.

3. Le client est identifié, et abonné

Dans ce cas, a quoi bon proposer au client de s’abonner ?

C’est de la place perdue. Place qu’on devrait plutôt récupérer pour proposer autre chose, plus efficace !

Conclusion

Voilà, fin de ce petit exercice de style.

Bien sûr, on évitera les usines à gaz et on privilégiera les réponses simples… Mais l’objet de ce petit billet, c’est de montrer que :

• Une demande simple (« je veux mettre en avant l’abonnement à la newsletter sur le site ») n’est pas forcément si simple que ça à traiter.
• C’est important d’analyser les différentes options, et de faire un choix cohérent.

La cohérence doit être travaillée du point de vue du client. On doit lui permettre de « faire et défaire » simplement.