Designers vs ingénieurs
J’ai trouvé un article très intéressant il y a quelques temps chez Nicolas Nova, qui s’intitule “Lessons from teaching design approaches to engineering students”. J’en profite donc pour vous le partager et vous expliquer un peu ce qui a retenu mon attention.
Dans cet article, l’auteur nous explique qu’il enseigne les processus de design à des étudiants en école d’ingénieur. Dans le cadre de ces cours, des groupes d’étudiants ont dû mener à bien un projet de conception et ont rencontré un certain nombre de difficultés qui sont d’après l’auteur caractéristiques du monde de l’ingéniérie. Voici les problèmes rencontrés par les étudiants :
Pas de prise de risque
Cette absence de prise de risque peut être liée à une peur de l’échec, alors qu’on sait bien que l’échec est très instructif et permet de progresser). Avoir peur de l’échec empêche aussi de tester des solutions plus originales et produit des solutions avec un faible degré d’innovation.
Une seule façon de concevoir, biais d’implémentation
Quand ils sont confrontés à un problème, les étudiants investiguent une seule solution, ils n’essayent pas d’explorer des solutions alternatives. Lorsqu’ils sont engagés dans la conception d’une solution, il est quasi impossible de les faire changer de direction. D’après l’auteur, ceci est dû à la difficulté de gérer les incertitudes.
Pour rencontrer fréquemment ce problème au bureau, je ne peux que confirmer. Pour moi c’est aussi lié à une dissonance cognitive. Lorsque l’on conçoit un objet, on est amené à prendre des décisions. À chaque décision, on met un peu plus le doigt dans l’engrenage de l’escalade d’engagement, ce qui fait qu’il est de plus en plus difficile de changer de direction.
Je fais aussi un lien avec le problème de la “surcharge fonctionnelle”. On rajoute toujours des fonctionnalités sans jamais en supprimer. La suppression d’une fonctionnalité est vraiment très dure psychologiquement pour les ingénieurs. On en avait besoin, on l’a spécifié, on l’a conçu. Il est difficile d’admettre qu’on ait pu se tromper ou que le contexte ait changé. Est-ce un problème culturel chez les ingénieurs ? Est-ce encore une escalade d’engagement ? Je ne sais pas. Je note juste que la société 37signals a une approche intéressante à ce niveau : ils décident volontairement de limiter le scope fonctionnel de toutes leurs applications, ils essayent d’en faire moins que la concurrence mais en offrant une réalisation plus soignée.
Ce qui est gênant lorsque l’on est lancés sur les rails d’un processus linéaire de conception, c’est qu’on peut avoir du mal à prendre du recul. Il est par exemple difficile pour un concepteur peu expérimenté d’anticiper la différence entre sa logique de conception et la logique d’utilisation de ses futurs utilisateurs (autrement dit entre la tâche prescrite et la tâche réalisée). Seuls les tests en situation réelle avec des utilisateurs représentatifs permettent de détecter ces différences. Il est donc nécessaire d’adopter une méthode de conception itérative.
Difficulté d’apprendre par la pratique
Les ingénieurs auraient besoin de réfléchir avant d’attaquer le prototypage, de planifier, de modéliser sur papier ou sur ordinateur. Pour ce point, j’avoue que je suis assez étonné car dans mon expérience, les étudiants ont plutôt tendance à foncer tête baissée et à développer directement. On essaye alors de les modérer et on leur enseigne de planifier avant de commencer à bricoler. Ceci est probablement dû au point précédent, si les décisions faites à ce moment sont mauvaises, on devra se traîner de mauvaises bases pour le reste du développement de l’application (c’est la dette technique). Si ce sont de bons conseils pour le développement d’un produit, ils le sont probablement moins pour le prototypage.
La façon naturelle de travailler pour un designer est très différente de celle d’un ingénieur. En effet pour eux il est indispensable de pratiquer pour pouvoir avancer. Il n’y a pas de process de design incluant le prototypage, mais le prototypage EST le process, comme le dit si bien Diego Rodriguez. Le fait de vouloir organiser et séquencer le processus de design leur semble bien trop restrictif.
En conclusion
Que faut-il retenir de cet article ? Mon point de vue est qu’il peut être intéressant pour des ingénieurs ou développeurs de réfléchir à leurs méthodes de travail, d’ouvrir leurs chakras et éventuellement de s’inspirer des méthodes des designers. Après tout, la conception est un processus créatif comme un autre. En tant que tel il faut essayer d’implémenter certaines bonnes pratiques qui permettent d’ajuster le tir, comme par exemple le processus itératif de design. Enfin je note pour ma part l’importance de la prise en compte de l’utilisateur. Il ne suffit pas d’anticiper ses besoins, mais il faut vraiment l’impliquer dans le design de la solution.
Vous avez tout lu jusqu’ici ? C’est très bien ! En récompense, vous avez le droit à une chtite nvidéo stylisée Gangnam.
Souvent, je garde pour plus tard les articles qui me semblent les plus intéressants dans mon lecteur RSS. Le risque, c’est de ne jamais revenir les lire… Voici un petit repêchage.
