En tant que chef de produit, essayez-vous d'inciter davantage de développeurs et de clients à utiliser votre API ? Marjukka Niinioja partage des conseils pratiques issus des audits d'API réalisés par son équipe et des exemples sur la manière dont les entreprises peuvent développer leur expérience de développeur d'API et convertir les utilisateurs en clients payants.
J'ai récemment aidé une entreprise qui souhaitait améliorer son expérience de développeur. Leur objectif trimestriel était de renforcer l'adoption de leur API et de recruter de nouveaux clients sur leur marché américain d'origine.
Nous avons procédé à un audit de leur expérience de développeur d'API. Ils procèdent actuellement à toutes les modifications suggérées par mon épais rapport d'audit. Je n'en mentionne donc pas le nom. Mais supposons qu'ils soient parmi les meilleurs dans leur domaine et qu'ils s'adressent aux plus gros clients, comme LinkedIn.
Leur parcours de développeur d'API et celui de leurs concurrents se sont heurtés à de nombreux problèmes, la plupart d'entre eux étant très courants. À l'intention de tous les chefs de produits et développeurs, je souhaitais partager quelques conseils. Faisons du monde un endroit meilleur pour les consommateurs d'API.
Mais d'abord. Disons une évidence.
Tout d'abord, vous devez vraiment comprendre qui sont ou seront les utilisateurs de votre API. Quels avantages attendraient-ils de votre API ?
Si votre API fournit aux utilisateurs un service ou des données utiles, ils seront plus enclins à l'utiliser. Réfléchissez aux moyens de faire en sorte que votre API se démarque de la concurrence et réfléchissez aux besoins potentiels des clients auxquels vous pouvez répondre avec votre offre unique. Une fois que vous avez identifié les avantages de votre API, promouvez-les sur différentes plateformes numériques.
Mais avant de proposer vos API à des plateformes tierces, vous devez faire quelques recherches sur vos propres canaux et vos API.
Conservez le conception graphique de votre documentation API ou de votre portail API en phase avec votre marque tout en restant convaincant pour vos développeurs.
Les utilisateurs potentiels de votre API doivent trouver votre API. Si vous concevez un joli site avec d'excellents graphismes, il se peut qu'il ne parle toujours pas à l'âme du développeur. Les développeurs veulent que votre site ait un aspect un peu brut. Il est préférable qu'il soit plein de détails techniques. Réduisez les graphismes soignés en criant : « Vous devez d'abord parler aux commerciaux ! »
J'ai également comparé les parcours de développement de leurs concurrents dans le cadre de l'audit des API. Nous avons ignoré certains des premiers candidats car vous deviez parler au service commercial pour accéder à l'API. Vous pourriez être tenté de penser que c'était une bonne chose. Vos concurrents ne doivent pas accéder à votre API trop rapidement. N'oubliez pas, cependant, que les formulaires que je devais remplir et les messages que j'ai reçus étaient carrément rebutants. Donc, en tant que développeur, je m'en serais de toute façon éloigné.
La documentation de votre API doit être liée à votre navigation principale sur le site.
Arrêtez-vous un instant. Consultez le site Web principal de votre marque. Imaginez que vous êtes un client ou un partenaire potentiel qui pense que l'API est une fonctionnalité « plus agréable ». Ils ne recherchent peut-être pas d'API, en particulier. Il peut s'agir de chefs de projet, de chefs de produit, d'architectes ou d'hommes d'affaires. Assurez-vous donc que votre API se démarque sur les pages principales des produits et ne la masque pas en tant que dernier lien du pied de page de votre site Web.
Il existe également de nombreuses autres manières de découvrir votre API, mais c'est la solution la plus simple à résoudre.
L'utilisabilité de la documentation de votre API commence par des descriptions claires de la valeur. Cela signifie propositions de valeur pour chaque API. Il est complété en ayant conceptions d'API standard avec des exemples de travail utiles et actualisés.
Cela semble être une décision difficile, mais je suis sérieux. Si votre expérience de développeur et votre parcours client ne sont pas à la hauteur de ces indicateurs, vos prospects passeront à l'API suivante. Ou s'il s'agit de vos développeurs internes ou de votre aide engagée, ils ne seront pas motivés et vous factureront plus cher. À moins que votre API ne fasse quelque chose qu'aucune autre API ne résout, ou si votre entreprise est la meilleure dans son domaine, vous risquez de vous en tirer avec un processus plus lent. Mais ne pariez pas là-dessus.
Certaines entreprises ont résolu ce problème en proposant uniquement des exemples de code comme documentation d'API. Ils semblent penser que la plus importante est de passer à la dernière étape du processus. Mais non, ne prenez pas de raccourcis. Si les consommateurs potentiels d'API ne comprennent pas pourquoi ils devraient utiliser votre API, le code que vous leur lancerez ne les aidera pas.
Cela ne veut pas dire que proposer des exemples de code ou des SDK ne serait pas une bonne chose. Ils le sont si vous avez les ressources nécessaires pour les entretenir. Si votre dépôt GitHub indique « dernière mise à jour il y a quatre ans », vos développeurs liront « abandonné » et passeront à l'étape suivante. Aucun langage de programmation au monde n'aurait besoin de quelques mises à jour chaque année. Et votre API a probablement été mise à jour de toute façon, alors quelles sont les chances que votre SDK fonctionne encore ?
Assurez-vous qu'il existe un processus permettant de répondre aux questions et aux problèmes émanant des développeurs via le référentiel du SDK. Sachez également que vos développeurs n'ont peut-être pas la meilleure approche à adopter lorsque quelqu'un « critique » son bébé.
Le Chef de produit API est essentiel à la réussite d'un programme d'API. Quelqu'un doit également être chargé de expérience et relations avec les développeurs.
À l'heure actuelle, vous pensez probablement que fournir une API nécessite une armée de développeurs et de spécialistes de l'expérience des développeurs.
Non, mais votre API a besoin d'un API Product Manager. Et je ne parle pas d'un propriétaire de produit utilisé dans Scrum, mais d'un chef de produit, qui traite l'API comme un produit destiné aux clients. Leur travail consiste à expliquer aux ventes, au marketing, au service client et aux développeurs les problèmes que l'API résout. Comment apporte-t-il de la valeur aux clients ?
C'est également au chef de produit de l'API de s'assurer que toute la documentation et le parcours du développeur fonctionnent. Le chef de produit de l'API doit travailler en collaboration avec un responsable des relations avec les développeurs ou un responsable de communauté. Leur travail mutuel consiste à s'assurer que les problèmes et les demandes de fonctionnalités émanant de votre communauté sont hiérarchisés et reçoivent une réponse.
Ce que vous devez faire pour améliorer votre expérience de développeur d'API dépend de l'état de vos API existantes et de la documentation de l'API. Le point de départ essentiel pour Les API REST consistent à utiliser les définitions OpenAPI pour vos API. En tant que chef de produit API, vous devez insister sur ce point. Cela aidera vos développeurs d'API à automatiser les processus de documentation et à garantir une expérience standard. Il existe des outils qui aident les développeurs à y parvenir et à appliquer les règles du guide de style de conception des API.
Qu'en est-il du code, des SDK et de la documentation ? Créez votre API à l'aide de la spécification OpenAPI. Ou du moins, générez-le à partir du code. Vous êtes alors déjà à mi-chemin de la documentation et des exemples de code. Assurez-vous que votre documentation OpenAPI inclut des exemples de requêtes et de réponses. Vous pouvez ensuite utiliser des plateformes de gestion d'API ou des outils open source. Les outils peuvent générer automatiquement de la documentation et des exemples de code dans différentes langues. Cela présente également quelques autres avantages. Les utilisateurs de votre API peuvent utiliser la définition OpenAPI dans leur code et dans leurs tests automatisés. Vous pouvez également utiliser la définition OpenAPI pour simuler (= simuler) l'API avant que tout ou partie du code n'ait été écrit et pour créer des tests.
Nous avons commencé par la question de savoir comment attirer davantage d'utilisateurs d'API.
La réponse simple est que vous devez commercialiser vos API, ce qui fera l'objet d'un autre article.
La réponse délicate est que les développeurs qui trouvent et utilisent vos API seront assez heureux de les convertir en clients payants ou en partenaires précieux. Cela signifie que vous devez améliorer votre expérience de développeur d'API. Vérifiez donc que ces éléments sont en bon état ou mettez-les dans votre carnet de commandes.