En résumé, il décrit 3 cas qui induisent un espace allant de la petite faille à un gouffre entre utilisateur et designer lors du design d'un projet :

  1. Le designer est l'utilisateur :
    C'est le cas (le plus confortable) par exemple des projets open source designed by geeks, for geeks où le designer et l'utilisateur final partagent la même hyper-connaissance du domaine d'application. Pourtant, il lui faudra effectuer un minimum d'aller-retour pour recueillir des feedbacks et améliorer le design du projet initial.
  2. Le designer comprend le produit :
    L'article prend l'exemple du design d'un téléphone portable. Bien qu'il en utilise un lui même, le travail du designer sur un tel produit ne se résume pas à y intégrer sa seule expérience avec un téléphone portable. Il existe bien des utilisations que seule une série de tests utilisateur pertinents peut découvrir.
    De plus, généralement, l'équipe de design est sur-compétente techniquement, ce qui l'empêche d'être impartiale dans la définition d'un produit qui doit toucher une audience non qualifiée.
  3. Designer pour un domaine inconnu :
    Le designer endosse le rôle du newbie et doit s'en remettre à l'expérience des experts d'un domaine qui lui est totalement inconnu. L'article suggère même le recrutement de personnes du métier pour découvrir comment elles travaillent, quelles sont leurs attentes etc... et travailler sur des prototypes papier pour tester les premières idées.
Dans tous les cas, on voit bien que le designer ne peut pas sortir un design de son chapeau magique. Il lui faut des données tangibles sur le produit et son environnement pour produire un design cohérent.
A méditer...