Concevoir un bon service pour les nuls (et in English)

Je sors de quelques heures assez pénibles avec le service téléphonique de l’ANTS pour l’immatriculation d’un véhicule. Je suis technophile, ce n’est pas une démarche critique, je reconnais la valeur de ce service dématérialisé par rapport au bon vieux temps des queues dans les préfectures, mais la complexité à joindre un humain, à expliciter le problème, l’absence de réponse et de marche à suivre sont un bon rappel à l’ordre pour le consultant que je suis. 

Dans la mission qui est la mienne en ce moment, l’enjeu est d’apporter une assistance technique au ministère de l’emploi marocain pour construire des parcours d’insertion économique par l’entrepreneuriat. Les idées fusent, le contexte est passionnant mais je n’ai qu’une trouille, paver l’enfer de mes bonnes intentions ! 

C’est dans ce contexte que j’ai lu avec un énorme intérêt le très fameux « Good services » de la non moins fameuse Lou Downe. Son propos est simple : « how to design services that work ». Les principes qu’elle présentent sont bêtes comme choux mais sans dénoncer personne, beaucoup de concepteurs de services feraient moins leur malin s’ils revisitaient leur « design » au prisme de ces considérations.

Petites notes de lecture, à mon usage en premier lieu et à mes collègues consultants de tout poil pour éviter quelques écueils. 

Je commence par quelques points généraux qui m’ont bien plu et les plus passionnés pourront lire la suite ou le bouquin !

  • Au-delà de son apport technique, ce livre explicite ce que je trouve « beau » dans l’entrepreneuriat. La posture indispensable pour survivre et grandir qui consiste à se demander de quoi les gens ont besoin pour leur apporter une solution adaptée.
  • Dans la droite ligne des méthodes de l’effectuation, les principes décrits ici partent de l’idée que la réussite d’un projet entrepreneurial n’est pas le fruit d’une incroyable idée mais de l’application de principes clairs, d’une approche besogneuse et systématique reposant sur des tests réguliers et organisés avec ses clients et partenaires.
  • Bien entendu, l’attention extrême portée au contexte, aux bénéficiaires/clients/usagers, me parlent ! C’est de là que vient mon intérêt (mon amour ?) pour les sociologues et les designers. 
  • L’idée que le service est là pour aider un usager à atteindre un objectif. Et que ça ne peut se faire qu’en étant ouvert sur tous les acteurs/offres qui entourent le service lui-même. De manière plus large, je porte avec Initiative France l’idée que l’entrepreneuriat vit par et pour les territoires. Des chercheurs en parlent beaucoup mieux que moi, j’en rendrai compte prochainement !
  • Je partage l’idée que ce qui passe « dedans » (la gouvernance, l’organisation de l’équipe…) se voit directement « dehors ». C’est pour ça que je préférerais toujours Biocoop à Carrefour Bio !
  • L’approche de l’inclusivité est « native » (quand on fait des muffins, il est plus simple de mettre les myrtilles au début !). Ce n’est pas un « gadget » ou une utilisation de revenus générés par d’autres activités destructrices (je caricature !). 2eme bon point pour Biocoop (chez qui je n’ai pas d’actions je tiens à le préciser).

Un bon service, donc c’est :

Un service qu’on doit pouvoir trouver facilement

Oui, ça commence par ça. Un service avec des verbes d’action, pas des noms, qui parlent aux usagers, qui nomment des choses qu’ils recherchent, pas les innovations imaginées par les producteurs des services. Allumer une lampe, ça donne de la lumière, pas des watt (tous les exemples idiots sont de moi et Lou Downe ne peut être tenue responsable de ce que j’écris dans ce post !).

Il va de soi que les acronymes, les registres techniques à l’excès sont à proscrire. Keep it simple, stupid, en quelque sorte. Ce qu’on décrit, c’est une tache, pas une technologie. Une tache qui répond à une action qu’un utilisateur veut réaliser et qui doit être nommée en cohérence avec sa familiarité avec le service proposé.

Un service qui exprime clairement son « purpose »

Lou Downe explicite la notion de purpose de manière intéressante autour d’un « what » (les fonctionnalités ») et d’un « why » (pour l’utilisateur mais aussi pour la société). C’est une des approches que j’aime bien dans ce bouquin. L’intérêt général, l’impact, sont « embarqués » dans tous les designs de services, ils ne « séparent » pas des projets/services gentils à impact et d’autres méchants sans impact.

Dès le début le service proposé doit être clair pour l’usager, il doit éviter, ou expliciter, les « allants de soi ».

Dans l’idéal, un service designé pour refléter son « purpose » n’a pas besoin de marketing, de « pitch », il s’auto-explicite. Sa forme reflète sa fonction. Ca c’est très beau ! Je vois bien l’idée, j’ai plus de mal à trouver des exemples ou à l’intégrer dans mon boulot. Mais il y a une forme de recherche de la simplicité, de l’évidence vu du côté utilisateur très stimulante. 

Il précise ce qui est attendu du bénéficiaire et ce qu’il va délivrer (temps/délais, coût…)

Traiter la question des attentes vise d’abord à éviter que des clients qui ont des attentes non alignées avec le service y recourent (et dans ce cas leur proposer des voies alternatives).

Les attentes universelles, connues de tous, n’ont pas à faire l’objet d’une communication mais doivent être nécessairement satisfaites (c’est par exemple l’attente de sécurité dans un avion, plus forte que celle d’un plateau repas). Celles plus spécifiques, particulières, sont souvent fondées sur des hypothèses, des expériences vécues avec d’autres services concurrents. 

Il aide le client à remplir un objectif

Un utilisateur définit un service parce qu’il veut atteindre. Il peut le définir différemment de la manière dont il est vu par le fournisseur de service.

C’est un principe que je trouve fondamental et souvent négligé. Penser à l’ordre des taches, à ce que l’utilisateur aura du faire avant de recourir à « notre service », pour s’assurer qu’il arrive avec le maximum de chance de remplir son objectif. Sauf exception, un service fait toujours partie d’une chaine, qui implique plusieurs organisations. L’articulation, la compréhension, l’interopérabilité entre les maillons de cette chaine sont fondamentales. Trop de programmes se concoivent comme « isolés » et sous-estiment, voire oublient de traiter leur relation avec les autres parties prenantes de l’écosystème qui entoure le bénéficiaire et viennent enrichir (ou au contraire rendre inopérant) le service proposé. Comme dirait le gouvernement UK dans ses « design principles » : « make things open : it make things better ». Et comme le dirait un bon bloody frenchy, « assures toi de la fluidité et de la continuité de services » !

Il fonctionne de manière « familière »

C’est-à-dire qu’il s’appuie sur des expériences, des « pattern » déjà acquis par l’utilisateur. 

Il ne demande pas de connaissances préalables

Pas mal d’expressions anglaises qu’il serait dommage de traduire en rende compte : « Don’t make me think », « Self evident » ou au moins « self explanatory ». 

Il est agnostique aux structures organisationelles

C’est-à-dire qu’autant que possible il n’oblige pas l’utilisateur à rentrer dans la logique/logistique du fournisseur de services. Aider l’utilisateur à atteindre son but (« getting things done ») est plus important que de savoir « qui délivre le service » ; définir ce qu’il veut atteindre comme but est plus importants que les « frontières » de notre service. S’attacher au partage des données, à la compatibilité des processus importe (« services in the internet age don’t obey organizational boundaries »).

On parle beaucoup en économie d’intégration verticale (j’achète mes fournisseurs et mes distributeurs) et horizontale (j’achète mes concurrents). Cette vision de la coopération entre fournisseurs de services donne lieu à un nouveau modèle d’intégration : l’intégration d’expériences, une fonction d’agrégateur de services.

Lou Downe tire de ce principe deux autres prolongements intéressants :

  • une structure en silo produit des services en silo ! J’y crois complètement, et ça a même un nom que j’ignorais, la loi de Conway ! Je suis à peu près convaincu que l’avenir dans le monde du « développement » sera aux agences et bureaux agiles, irréprochables dans la gestion d’équipes qui sortent de leur posture d’expert pour travailler en équipe et immergés dans leurs contextes.
  • La 1ere version de design qui sort n’est en général pas la bonne : les concepteurs de services ont besoin d’organisations agiles

Un bon service nécessite aussi peu d’étapes à franchir que possible pour être complété

Pour Lou Downe, le nombre maximum « d’étapes » est le nombre de fois où le bénéficiaire doit prendre une décision. Elle recommande également de travailler sur les « espaces » entre les étapes (le temps d’attente d’une réponse par exemple) et de donner un but, un sens à ces pauses.

C’est l’occasion de poser la question du rythme (combien d’étapes dans un parcours) mais aussi du tempo (combien de temps pour passer cette série d’étapes). Un point très critique, que j’ai eu plusieurs fois à observer en tant que praticien de l’appui à la création d’entreprise. Les délais avant les passages en comité de crédit, le temps de donner une réponse, de monter un rendez-vous… sont des indicateurs évidents de qualité mais rarement mesurés.

Il est « consistant » tout au long du parcours

C’est l’application à la chaine de délivrance du service du principe du « weak link » (une équipe de foot est aussi forte que le plus faible de ses joueurs). 

Les services sont constitués de plusieurs parties, délivrées par plusieurs acteurs. Le lien le plus faible donne la valeur du service dans son ensemble !

Et dit beaucoup mieux que moi par Ms Downs :”Every breach of consistency is a breach of trust”.

Il évite les « cul de sac » (dead end)

En tout premier lieu, il s’attache à offrir une « voie de sortie » aux usagers qui ne sont pas éligibles au service, en creusant la non éligibilité et en orientant. « No user left behind » !

Ensuite, il évite l’arrêt du service par sa complexité et l’effet de découragement.

Il est utilisable par tout le monde

Un « gros » point qui traite de l’inclusivité « native » des services. Trop souvent, les services sont conçus pour un utilisateur « idéal », de « normal » avec tous les biais imaginables dans la définition de cette  « normalité » par le créateur du service. 

Rien ne remplace l’importance de faire des recherches sur les utilisateurs pour comprendre leurs barrières spécifiques par rapport au service.

Par ailleurs, toujours ce miroir du fonctionnement des équipes sur les services conçus, il est primordial de cultiver la diversité des profils dans l’équipe (lack of diversity in your team = lack of inclusivity in your service).

Il encourage le « bon « comportement » des utilisateurs et de l’équipe

Un bon service doit être bénéfique aux utilisateurs, aux employés ET au monde (ou au moins ne pas lui faire de mal !). Cela se traduit par la fixation d’objectifs aux équipes qui ne vont pas contre le bon sens ou entraînent des effets pervers.

Il répond rapidement au changement

…Et reste consistant si l’utilisateur change (par exemple de numéro de téléphone)

Il explicite pourquoi une décision a été prise

… Et donne des voies de recours si besoin

Cela pose bien sur la difficulté de construire des services reposant sur des décisions automatisées, sans capacité d’interaction avec des humains.

« Comment la décision est prise est aussi important que la décision qui est prise » est un principe qui anime Initiative France. La construction des comités de crédit, les procédures strictes qui entourent sa composition, son déroulement, les règles du jeu sur la bienveillance et le questionnement sont au cœur du modèle.

Il doit permettre de parler avec un humain simplement à chaque fois qu’il y en a besoin !

Car le vrai différenciateur ce n’est pas que le service fonctionne ou pas. C’est ce qu’il se passe quand il ne fonctionne pas !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *