L'Étude de Cas Design Traditionnelle Est en Train de Mourir

L'étude de cas design gonflée est en train de mourir. L'étude de cas elle-même, non.

Cette distinction est tout l'argument, alors accrochez-vous y. Le deck de 47 écrans avec six semaines de documentation de processus perd du terrain face à un Loom de trois minutes d'un produit fonctionnel construit en une seule session. Quand un recruteur peut cliquer sur une URL en direct en dix secondes, votre parcours double diamant commence à ressembler à des devoirs que vous lui assignez.

Ce n'est pas un avis de décès pour la réflexion. C'est un avis que la preuve a bougé. L'artefact devient l'argument, et le deck de slides expliquant l'artefact devient optionnel.

Le fil qui a divisé les designers sur Twitter

La bataille est devenue publique quand le designer @andrewk a posté un fil demandant si l'étude de cas traditionnelle est maintenant obsolète. Ça a fait un tabac : environ 9 800 reposts et plus de 400 réponses, avec les designers divisés en deux camps.

Cette division est le signal. Une moitié de la salle a soutenu que l'étude de cas est un artisanat sacré. L'autre moitié a pointé ses propres démos en direct et demandé pourquoi quelqu'un aurait besoin du deck quand le produit est là.

Aucun camp n'a tort, c'est exactement pourquoi ça s'est propagé. Le désaccord ne porte pas sur le fait que les designers devraient réfléchir. Il porte sur l'endroit où les preuves de cette réflexion devraient vivre maintenant que livrer est presque gratuit.

Ce qui a vraiment changé (une session, vraie authentification, vrais paiements, livré le même jour)

Voir en direct sur cursor.com

Ce qui a changé, c'est que le coût d'un artefact fonctionnel s'est effondré. Des designers indépendants et des fondateurs publient maintenant des applications complètes et fonctionnelles, avec authentification, paiements et flux de données réels, générées en une seule session prolongée et livrées le même jour.

Les outils ont rendu cela crédible rapidement. Un build de longue durée dans Claude Code ou Cursor peut maintenant maintenir un plan cohérent sur toute une session au lieu de s'effondrer après le troisième fichier. La fiabilité à long horizon de Fable 5 et ses récentes victoires sur CursorBench expliquent pourquoi "en une prise" a cessé de ressembler à un tour de démo et a commencé à ressembler à un mardi ordinaire.

Alors le calcul s'est inversé. L'ancienne étude de cas existait en partie parce que construire la vraie chose était coûteux, lent et conditionné à l'ingénierie. Vous documentiez le processus parce que le processus était la majeure partie du travail que vous pouviez réellement montrer.

Maintenant, la vraie chose est peu coûteuse à produire. Quand vous pouvez remettre à quelqu'un une URL en direct en fin de journée, une reconstruction statique de la façon dont vous l'auriez construite se lit comme une version inférieure d'une preuve que vous avez déjà.

Livrable traditionnel vs artefact fonctionnel (le tableau honnête)

Voici la comparaison qui rend cela concret. Ce n'est pas du battage, c'est une différence dans ce que chaque format fait réellement pour la personne qui vous évalue.

Lisez la ligne "ce que ça peut cacher" deux fois. L'étude de cas statique peut cacher que le design n'a jamais survécu au contact de vraies données, de vrais états ou d'un vrai backend. L'artefact fonctionnel ne peut pas cacher ça, parce que le recruteur se trouve à l'intérieur.

C'est pourquoi l'artefact gagne en confiance. Il est plus difficile de simuler quelque chose qui tourne que quelque chose qui est rendu.

L'étude de cas n'est pas morte, la version gonflée l'est

Maintenant le contre-argument honnête, parce que la version nécrologique de ce point de vue est paresseuse.

Une démo en direct prouve que la surface fonctionne. Elle ne prouve pas, à elle seule, que vous avez compris le problème, pesé les compromis ou choisi cette forme plutôt que trois autres pires. Une belle application qui résout le mauvais problème est toujours le mauvais problème, livré plus vite.

C'est le piège dans "l'étude de cas est morte". Les gens l'entendent et suppriment la réflexion avec le gonflement des slides. Ce ne sont pas la même chose. Le gonflement, c'est les 12 slides de citations de personas et le moodboard que personne n'a demandé. La réflexion, ce sont les deux décisions qui ont vraiment façonné le produit.

Donc le mouvement n'est pas "arrêtez d'expliquer votre travail". Le mouvement est "arrêtez de rembourrer". Gardez le jugement, coupez le théâtre. Un artefact fonctionnel sans histoire derrière peut se lire comme "j'y suis arrivé à coups de prompts", et pour les postes seniors, c'est un vrai handicap.

Ce que votre portfolio doit prouver maintenant (goût, jugement, cadrage du problème)

Une fois que livrer est presque gratuit, ce qui est rare n'est pas la production. Ce sont les trois choses qu'une application one-shot ne peut pas prouver par elle-même.

Goût. Quand n'importe qui peut générer une interface passable, l'écart entre passable et juste est tout le travail. Le goût, c'est les mille petites décisions qu'un modèle ne prendra pas pour vous : quoi couper, quoi ralentir, où ajouter de la friction intentionnellement.

Jugement. Montrez le fork. Montrez la version que vous avez tuée et la raison en une phrase pour laquelle vous l'avez tuée. Un seul "on a essayé X, ça brisait la confiance au paiement, alors on a fait Y" prouve plus qu'un récit de 40 slides d'un chemin sans embranchements.

Cadrage du problème. La démo répond à "l'avez-vous construit". Le cadrage répond à "cela aurait-il dû exister, et sous cette forme". Cette question est l'endroit où les designers seniors méritent leur titre, et c'est la partie qu'un modèle est le moins apte à vous donner.

Remarquez qu'aucun de ces éléments n'a besoin de 50 écrans. Ils ont besoin d'une chose en direct et de quelques phrases honnêtes sur les décisions que vous avez prises en la construisant.

Comment reconstruire votre portfolio ce mois-ci (commencez par la chose en direct, gardez un court journal de décisions)

Voir en direct sur cursor.com

Vous pouvez reconstruire cela en un mois sans détruire ce que vous avez. La forme est simple : commencez par l'artefact, appuyez-le avec du jugement, coupez le reste.

1. Commencez par la chose en direct. Premier écran de chaque projet : une URL cliquable ou un parcours de 60 à 90 secondes du produit en fonctionnement. Pas un hero shot, le vrai produit. Le recruteur doit toucher quelque chose de réel avant de lire un mot.

2. Gardez un court journal de décisions. Trois à cinq décisions par projet, chacune en une ligne. La décision, l'alternative que vous avez rejetée, la raison. C'est la preuve de jugement qu'une démo seule ne peut pas porter.

3. Montrez un fork par projet. La version qui n'a pas été livrée et pourquoi. C'est la façon la plus rapide de prouver que vous réfléchissiez, pas seulement que vous génériez.

4. Coupez le théâtre de processus. Supprimez les slides de personas, les cartes d'empathie que vous n'avez jamais utilisées, le moodboard, les écrans "d'idéation". Si ça n'a pas changé le produit, ça ne mérite pas de place.

5. Mettez la date de livraison. "De l'idée au live en une session" ou "livré en un week-end" est maintenant une accréditation. Ça signale que vous pouvez avancer à la vitesse à laquelle le travail avance réellement en 2026.

C'est toute la migration. Commencez par l'artefact, prouvez le jugement en cinq lignes, jetez le rembourrage qui a toujours été du rembourrage.

FAQ

L'étude de cas design est-elle complètement morte ?

Non. L'étude de cas gonflée et orientée processus meurt en tant que valeur par défaut. Ce qu'elle prouvait, que vous pouvez réfléchir et livrer, vit maintenant mieux dans un artefact fonctionnel plus un court journal de décisions.

Devrais-je simplement poster un prototype fonctionnel sans explication ?

Non, et c'est la sur-correction la plus courante. Une démo sans histoire se lit comme "j'y suis arrivé à coups de prompts", ce qui vous dessert pour les postes seniors. Associez l'artefact en direct à trois à cinq décisions en une ligne et un fork que vous avez rejeté.

Qu'est-ce qu'une application one-shot, exactement ?

Un produit complet et fonctionnel, souvent avec authentification, paiements et vraies données, construit en une seule session prolongée dans un outil comme Claude Code ou Cursor et livré le même jour. Le jugement humain est toujours impliqué. Ce qui s'est effondré, c'est la distance entre l'idée et la chose en direct.

Cela signifie-t-il que les designers juniors sont en difficulté ?

La barre est passée de "pouvez-vous décrire une méthode" à "pouvez-vous livrer et défendre". Ça aide quiconque sait construire, parce qu'un artefact cliquable est plus honnête qu'un deck. Le risque concerne les portfolios qui cachaient une substance mince derrière des slides de processus.

Comment prouver ma réflexion si l'étude de cas a disparu ?

Vous n'avez pas besoin de l'étude de cas longue forme pour prouver la réflexion. Utilisez un court journal de décisions : la décision que vous avez prise, l'option que vous avez rejetée, la raison en une phrase. Trois à cinq de ces éléments à côté d'un artefact en direct prouvent plus de jugement qu'un récit de 40 écrans.

Et pour le travail enterprise complexe ou les systèmes qui ne peuvent pas être one-shot ?

Alors votre artefact est différent, mais le principe tient. Montrez une tranche fonctionnelle ou un composant qui fonctionne, et attachez-y le journal de décisions. Le changement est "commencez par quelque chose de réel et cliquable", pas "reconstruisez votre SaaS entier en un week-end".

La conclusion (l'artefact est l'argument)

L'artefact est l'argument maintenant. Quand vous pouvez donner à quelqu'un quelque chose qui tourne, le deck expliquant comment vous l'auriez construit devient la copie plus faible d'une preuve que vous détenez déjà.

Le fil @andrewk a divisé les designers autour de 9 800 reposts et plus de 400 réponses parce que les deux moitiés défendaient quelque chose de vrai. Une moitié défendait la réflexion. L'autre défendait la preuve. La résolution est que la preuve s'est déplacée dans la chose fonctionnelle, et la réflexion s'est déplacée dans cinq lignes honnêtes à côté.

Alors ne pleurez pas l'étude de cas. Archivez la version gonflée, gardez le jugement, et commencez par la chose en direct. Le processus dehors, le produit dedans.

Les designers qui gagnent la salle en 2026 ne sont pas ceux avec le deck le plus épais. Ce sont ceux qui peuvent dire "cliquez ici", puis expliquer, en cinq lignes, exactement pourquoi c'est façonné ainsi.