Certains projets ne peuvent pas être montrés publiquement. D’autres fois, il existe un accord pour certains supports, mais pas pour les données commerciales, les processus internes ou l’identité de toutes les personnes impliquées. Ne pas avoir d’étude de cas publique ne signifie pas qu’il faille se contenter d’adjectifs.
Nous pouvons montrer comment nous analysons une situation, quelles questions nous posons et comment une décision devient réalisation. L’essentiel est de décrire avec exactitude la nature de la démonstration et de ne pas lui attribuer des résultats qu’elle ne peut pas prouver.
Ce que nous voulons que les visiteurs puissent vérifier
« Nous avons un processus rigoureux » est difficile à évaluer sans repères. Une comparaison entre un brief incomplet et un brief clarifié peut montrer quelles informations sont nécessaires. Un exemple de rapport peut expliquer ce qui est mesuré et comment les limites des données sont abordées.
Ces supports étayent des affirmations sur notre façon de travailler. Ils ne démontrent pas automatiquement l’impact commercial d’un projet. Pour cela, il faut des informations réelles, du contexte et une interprétation solide de chaque contribution.
Avant de choisir le visuel, nous formulons la question : voulons-nous montrer la qualité d’une réalisation, notre façon de réfléchir à un problème ou le résultat d’une intervention ? Chacune appelle un autre type de preuve.
Trois formes, trois limites différentes
| Support | Ce qu’il peut montrer | Ce qu’il faut expliquer |
|---|---|---|
| Un projet réel autorisé | Le travail réalisé dans les conditions présentées | Notre rôle, les contributions des partenaires et les limites de ce qui peut être publié |
| Un exemple préparé pour la présentation | La structure d’un livrable ou d’une interaction | Ce qui relève de la démonstration et ce qui varierait dans un projet |
| Un scénario fictif indépendant | Le raisonnement appliqué à une situation inventée | Qu’il ne représente ni un client ni des résultats réels |
Un exemple peut être utile même s’il ne contient pas tous les détails d’un livrable. Mais nous devons en dire assez pour que la personne ne prenne pas un exemple simplifié pour le projet complet ou pour une offre standard.
Anonymiser, c’est plus que retirer le logo
Une capture d’écran peut contenir des noms dans des notifications, des adresses, des identifiants, des chiffres, des fragments d’échanges ou des informations dans des onglets ouverts. Parfois, la combinaison du secteur, de la période et des résultats peut rendre un projet reconnaissable même sans le nom de l’entreprise.
C’est pourquoi l’accord et la relecture portent sur le support précis qui sera publié, dans sa forme et son contexte. Nous confirmons ce qui peut apparaître, ce qui doit être retiré et qui vérifie la version finale. Nous ne supposons pas que l’accès à un projet inclut le droit d’en faire un contenu public.
Lorsque les conditions d’une présentation sûre ne sont pas réunies, nous pouvons construire une démonstration indépendante. Elle utilise des données inventées et un scénario créé pour l’explication. Nous n’essayons pas de cacher un vrai client derrière des changements cosmétiques.
Une démonstration complète, sans résultats inventés
Imaginez un atelier fictif qui reçoit des demandes par un formulaire. Dans la démonstration, une demande de test arrive dans une liste et reçoit un responsable et une étape suivante. Nous montrons ce qui se passe lorsque la personne responsable est absente.
Nous pouvons expliquer les choix : pourquoi il faut une règle d’attribution, quelles informations doivent être transmises et pourquoi l’accusé de réception ne prouve pas que la demande a été traitée. Nous pouvons montrer un cas complet, un cas incomplet et un doublon.
Que pouvons-nous affirmer ? Que la démonstration illustre un processus possible et ses vérifications. Qu’est-ce qui n’en découle pas ? Que nous avons augmenté les ventes d’un client ou que chaque entreprise a besoin du même système. Ces conclusions demandent d’autres preuves.
La mention « scénario fictif » doit être visible dans le support et dans ses déclinaisons. Si nous découpons la démonstration en courte vidéo, nous gardons le contexte nécessaire. Nous ne cachons pas l’explication sur une page que le public ne visitera peut-être jamais.
Nous montrons la décision, pas seulement l’écran final
Une page finale peut être attrayante sans révéler le problème qu’elle a résolu. Un court commentaire peut expliquer pourquoi nous avons réorganisé les informations, quelle alternative nous avons envisagée et pourquoi nous avons choisi la forme présentée.
Il n’est pas nécessaire de publier chaque document interne. Nous choisissons quelques décisions pertinentes pour le client et les relions à l’effet recherché. Par exemple, placer les conditions de livraison à côté de l’offre peut s’expliquer comme une façon de rendre le coût plus facile à évaluer. Sans données, nous ne le présentons pas comme une hausse prouvée de la conversion.
Nous pouvons aussi montrer les limites d’une alternative. Cela aide les visiteurs à comprendre que la solution a été choisie pour une situation précise, et non parce qu’il n’existerait qu’une seule bonne façon de construire n’importe quel projet.
La publication a besoin d’un responsable
L’équipe qui produit le support vérifie les textes, les images et les fichiers exportés. Les personnes qui connaissent le projet confirment les informations et les limites de l’accord. La responsabilité ne doit pas rester dans un échange de messages flou.
Nous gardons une trace de la forme validée et des usages convenus. Si le contexte change ou si le support est retiré, nous devons savoir où il apparaît. Cette organisation aide aussi à entretenir le portfolio.
Chez NOT MORE., nous pouvons transformer le travail et le raisonnement qui le sous-tend en études de cas, démonstrations, textes, design et vidéo. Nous pouvons aussi créer des scénarios indépendants pour les services qui n’ont pas encore d’exemple public. Nous choisissons la forme selon ce qu’elle peut étayer, pas selon l’impression de réussite qu’elle pourrait donner.