Blockdaemon : protocole ETH

Le contexte

Blockdaemon est une plateforme d’infrastructure blockchain de premier plan dans le Web3, qui permet aux entreprises de déployer et d’itérer rapidement des applications blockchain innovantes. Elle retire la complexité de la blockchain grâce à une configuration simple, à un monitoring qui garantit la haute disponibilité et à une sécurité de niveau institutionnel.

Un protocole, c’est l’ensemble des standards qui régissent un réseau blockchain : validation des transactions, consensus, communication réseau, stockage des données. Les nœuds sont les appareils qui maintiennent l’intégrité de ce réseau. Le staking, c’est quand des détenteurs de crypto immobilisent de la cryptomonnaie pour participer à la validation et au consensus. Les pages Protocols de Blockdaemon étaient l’endroit où les acheteurs grands comptes allaient comprendre lesquels étaient pris en charge, et comment. J’ai travaillé sur la phase 1 d’ETH Protocol : repositionnement et notoriété.

Le problème

Mi-2022, Ethereum était de loin le protocole le plus populaire chez les clients grands comptes de Blockdaemon, et sa page était celle qu’ils lisaient avant de contacter les commerciaux. Elle était aussi périmée.

La plupart des pages de protocole l’étaient. Le design et le contenu ne reflétaient plus les dernières offres, et la page ETH en particulier ne disait rien des API récemment lancées, dont la NFT API. Elle était longue, lourde en texte, pauvre en visuels. Le résultat, c’était un déficit de notoriété. Les clients grands comptes ignoraient ce qui avait été livré, et moins de leads qualifiés arrivaient jusqu’aux commerciaux.

Les objectifs : redessiner la page pour refléter les dernières API et offres tout en améliorant son attrait visuel et en réduisant l’encombrement ; créer de la notoriété auprès des clients grands comptes sur les nouvelles offres ; et, en réussissant ces deux points, augmenter le nombre de leads grands comptes qualifiés.

Mon rôle

J’ai mené ça de bout en bout, et la distinction entre ce que j’ai dessiné et ce que j’ai mis en production compte ici.

Ce que j’ai conçu : le plan de recherche et huit entretiens ; l’analyse concurrentielle ; le persona et le parcours utilisateur ; les sections hero, fonctionnalités, CTA et confiance, contact et FAQ de la page de protocole ; une page NFT API dédiée ; la refonte complète de la newsletter ; et un nouveau système de couvertures de blog.

Ce que j’ai construit et livré : la page de protocole en tant que gabarit plutôt qu’en tant que page. J’avais rédigé un guide de style MVP quelques mois plus tôt pour corriger les incohérences qui se glissaient dans nos designs, et ce projet est l’endroit où je l’ai mis au travail comme système de composants : une page gabarit avec des emplacements définis pour les chiffres, les offres et le texte propres à chaque protocole, pour que le motif tienne pendant que chaque page reste personnalisable. J’ai aussi produit les visuels 3D à partir desquels la newsletter et les couvertures ont été construites, et écrit les règles et les gabarits de couverture de blog que l’équipe a utilisés ensuite. L’ingénierie a repris le gabarit et y a basculé les pages de protocole restantes.

L’approche

Huit entretiens. Cinq en interne (deux product managers, deux chargés de marketing, la responsable marketing) sur ce qui allait sortir, ce qui existait déjà, et le niveau réel de connaissance technique Web3 du public. Trois avec des commerciaux : ce dont les clients grands comptes ont besoin d’une API blockchain, quels indicateurs ils privilégient pour évaluer un protocole, ce qui rend le choix d’un fournisseur difficile, et quels e-mails, quels decks et quels one-pagers avaient donné de bons résultats. Ces conversations ont fini sur une carte d’affinités.

L’analyse concurrentielle a fait remonter quatre choses qu’une page de protocole devait porter : une liste de fonctionnalités et une section de détails appuyées par des visuels forts ; des chiffres comme les récompenses de staking et les récompenses additionnelles ; une section articles de blog pour installer la confiance ; et une section docs pour que les clients puissent parcourir la documentation technique avant une décision d’achat.

Alex, le persona, et un parcours retraçant la façon dont Alex choisit un fournisseur ont aligné produit et marketing. La question est devenue : comment mettre en scène la page ETH Protocol pour augmenter la notoriété et attirer les décideurs de niveau direction, et générer des leads qualifiés ?

La construction

J’ai conçu le gabarit sur le protocole Polkadot d’abord, comme substitut délibéré. Si le système se pliait à un protocole pour lequel il n’avait pas été dessiné, il se plierait pour les autres.

L’ancien hero entassait des chiffres qui encombraient la page et qui n’étaient pas ceux sur lesquels les clients évaluaient, et son texte ne couvrait pas les dernières offres. Sur deux options, la seconde mettait bien mieux les chiffres en valeur : description du protocole à gauche, chiffres à droite, dans le sens naturel de lecture. J’ai ensuite calmé la typographie des chiffres pour que la hiérarchie ne bascule pas.

La section fonctionnalités était du texte dense avec un seul visuel de soutien, et il y manquait des offres clés dont le staking et la NFT API. Une option partait riche en images avec toutes les offres en avant ; l’autre utilisait des cartes à icônes réparties en onglets. La première l’a emporté parce qu’elle racontait une histoire cohérente : des offres classées par ordre de priorité pour le client cible, de bons visuels de soutien, des boutons tertiaires vers les docs. En dessous venaient les CTA pour staker de l’ETH ou lancer un nœud, la section blog et les logos des clients actuels, puis le contact et la FAQ.

La newsletter, c’était du texte avec un logo au-dessus. J’ai construit des assets 3D pour l’image d’en-tête, et ces assets ont fini par accélérer la production de design bien au-delà de l’e-mail : couvertures de blog, miniatures YouTube, supports d’événements. Les couvertures de blog étaient incohérentes en design comme en format, surtout du texte brut sur blanc, trop peu soignées pour retenir l’attention dans un fil social ; elles ont reçu un nouveau système visuel avec des règles et des gabarits derrière.

Le résultat

Toutes les pages de protocole ont été refondues sur le nouveau gabarit, la newsletter redessinée est partie, et les articles de blog récents ont été rafraîchis avec les nouvelles couvertures. L’engagement et la conversion ont été suivis de près ; ces chiffres sont confidentiels et ne sont pas publiés ici.

Ce à quoi servait ce travail se dit plus simplement : faire en sorte que les clients cibles puissent saisir facilement les offres principales, comparer les fournisseurs et se renseigner sur les services en confiance, avec la newsletter et les articles de blog pour installer la crédibilité autour. Les règles pour les visuels 3D produites par le projet ont gardé le langage visuel cohérent pour l’équipe design ensuite.

Ce que je ferais autrement

Aucune partie de la recherche n’a touché un vrai client grand compte. Les commerciaux étaient un bon substitut, et un substitut honnête, mais ça reste de la seconde main. J’insisterais pour avoir deux ou trois conversations avec de vrais acheteurs avant de figer un jeu de chiffres.

L’analyse concurrentielle plaçait une section docs dans les quatre premières exigences, et le gabarit est parti avec des liens tertiaires vers les docs plutôt qu’un véritable point d’entrée. Le bon choix pour deux mois, le mauvais pour l’année suivante.

Et le gabarit est sorti avant qu’une spécification de composants soit écrite. Le déploiement par l’ingénierie sur les protocoles restants a marché, mais une spec l’aurait rendu plus rapide et aurait laissé moins de décisions à refaire page par page.