Non, malgré son nom : le Design Thinking s'applique à tout type de problème impliquant des humains, bien au-delà du design de produits. Né dans le monde du design, il s'est diffusé dans une immense variété de domaines : conception de services (améliorer un parcours client, un service public), organisation (repenser un processus interne), éducation (concevoir des formations), santé (améliorer l'expérience des patients), social (résoudre des problèmes communautaires), et même la stratégie d'entreprise. Ce qui compte n'est pas le « produit high-tech » mais le principe central : partir des besoins réels des personnes concernées (empathie) plutôt que de ses suppositions, générer largement des solutions, puis les tester tôt auprès des utilisateurs et itérer. Ce principe est universel : dès qu'on veut résoudre un problème qui touche des gens (clients, usagers, collègues, citoyens), comprendre profondément ces gens avant de concevoir la solution est pertinent. Une TPE peut l'utiliser pour améliorer son accueil client, une association pour concevoir un service, un manager pour repenser l'organisation de son équipe. Le « design » dans « Design Thinking » désigne une façon de penser et de résoudre les problèmes (avec empathie, créativité et itération), pas le métier de designer. Ne vous laissez pas intimider par le vocabulaire ou l'association aux startups : c'est une démarche accessible et polyvalente, utile dans quasiment tous les contextes où l'on cherche à créer quelque chose d'utile pour des personnes.

Parce que, aussi paradoxal que cela paraisse, tester tôt fait gagner du temps et évite les erreurs coûteuses — c'est l'un des apports les plus précieux du Design Thinking. Le réflexe classique est de « bien réfléchir », peaufiner une solution dans son coin, la développer entièrement, puis la lancer… pour découvrir trop tard que les utilisateurs n'en veulent pas, ne la comprennent pas, ou avaient un besoin différent. On a alors investi énormément de temps et d'argent dans une solution inadaptée. Le prototypage et le test précoces inversent cette logique : on matérialise rapidement et à moindre coût une version simple de l'idée (un croquis, une maquette papier, un scénario — section 4.3), on la confronte immédiatement aux vrais utilisateurs, et on recueille leurs retours avant d'avoir tout investi. Les bénéfices sont énormes : on détecte tôt les problèmes (quand ils sont faciles et peu coûteux à corriger, plutôt qu'après le lancement) ; on apprend ce que veulent réellement les utilisateurs (leurs réactions concrètes valent mieux que nos suppositions) ; on itère et améliore progressivement vers une solution qui marche vraiment. « Échouer vite et à peu de frais » pour réussir mieux ensuite : un prototype raté nous coûte quelques heures et nous apprend énormément, alors qu'un produit fini raté nous coûte des mois. Cela ne veut pas dire ne pas réfléchir — l'empathie et la définition (réflexion) précèdent — mais ne pas trop réfléchir dans l'abstrait avant de confronter au réel. Les idées, aussi brillantes soient-elles sur le papier, doivent être éprouvées par le contact avec les utilisateurs.