Programmation orientée utilisateurs

Le chantier commence. Toutes les pièces de notre nouveau chauffage ont enfin été livrées et l’équipe d’installation commence le travail. Nous avons défini dans les grandes lignes les emplacements des différents éléments avec le chef du projet il y a quelques mois. Nous nous arrangerons pour les détails, nous avait-il dit.

Ces « arrangements » s’avèrent, comme souvent, plus compliqués que prévus.

Nous essayons d’exprimer notre souci d’économie de place. L’équipe de montage, elle, nous fait part de limites techniques et d’économie de temps. N’étant pas expert·es dans le domaine, nous posons beaucoup de questions pour faire la différence entre l’impossible et ce qui est possible avec un peu plus de travail. De son côté, l’équipe s’agace car elle est coincée entre les délais qu’elle doit respecter et nos exigences d’une solution qui fait du sens à long terme pour nous.

En réfléchissant à la situation, je ne peux m’empêcher de faire le parallèle avec notre domaine et la collaboration entre équipes de conception et de développement. Ces échanges mélangent aussi souvent des soucis de respect de deadline, de compromis entre utilité et faisabilité technique et, surtout, de confiance entre les deux parties. Je ne suis pas expert en chauffage, par contre j’ai passé assez de temps entre de le design et l’implementation technique pour savoir que nous avons beaucoup de potentiel pour améliorer la qualité et l’efficacité dans notre domaine.

Une certaine évolution

Cela fait un peu plus de 30 ans que nous apprenons à parfaire l’art de créer des sites web. Que de chemin parcouru depuis le bon temps des pages pleines de textes clignotants et de sites non accessibles en Flash. Les contenus ont bien changé, mais aussi notre façon de travailler. D’une personne à tout faire, le webmaster, nous sommes passé aux spécialisations : design / développement, UX design / visual design, développement front-end / développement back-end, et ainsi de suite.

Le compromis le plus évident de la spécialisation est le besoin de collaboration. Pour utiliser ces savoirs approfondis, nous devons travailler ensemble pour combiner notre savoir-faire. S’aligner sur la vision, partager les tâches et communiquer clairement ensemble est un défi. Les progrès en méthodes de travail (lean, agile) et en outils (guides de style, bibliothèques de composants) nous ont permis de simplifier cette collaboration.

Pourtant, trop souvent, c’est dans cette phase cruciale de transition entre le design et le développement que beaucoup d’énergie et de potentiel est perdu.

Le design ? C’est pas mon truc…

Même si l’on se spécialise sur un seul sujet, il est essentiel d’avoir un minimum des bases de connaissances sur les sujets adjacents. Cela simplifie la collaboration. Ainsi, par exemple, les spécialistes front-end ont souvent des connaissances de back-end, de développement d’application, de SEO, d’accessibilité, de devops et ainsi de suite. Pour l’avoir vécu, je peux témoigner de l’incroyable expansion des domaines à maîtriser en tant que développeur·euse.

Par contre, quand il s’agit de s’intéresser au domaine du design, les lacunes sont plus grandes. Nous prétextons parfois que c’est un tout autre domaine, une autre façon de travailler ou même de penser… Que c’est un autre métier et qu’il y a des spécialistes pour s’en charger…

Cette pensée trouve sûrement ses origines dans l’idée erronée que le design est une discipline artistique concentrée sur le visuel. Au contraire, les concepts de base du design les plus importants ont attrait à la psychologie humaine et mettent l’accent sur l’expérience des utilisateur·ices.

Tout ce qu’il faut pour s’intéresser au design, c’est de l’empathie. Avoir la curiosité de s’interroger sur ce que les utilisateur·ices vont faire de ce que je développe.

Assez d’autres choses à gérer

En tant que développeur·euse, nous avons tellement d’aspects à gérer dans notre quotidien. Il ne s’agit pas simplement de s’assurer qu’une solution fonctionne. Il faut aussi qu’elle soit simple, maintenable, sûre, pas limitante, optimisée, légère, rapide, accessible, adaptée à plusieurs plateformes et ainsi de suite… Il y a tellement de paramètres à gérer pour trouver la solution la plus adaptée. Se soucier de l’impact sur l’expérience utilisateur de la fonctionnalité que l’on vient de développer n’est instinctivement pas notre premier souci.

Et c’est bien là le problème. La valeur de l’expérience utilisateur qui a fait l’objet de tant d’attention durant la phase de design se trouve rétrogradée au même rang d’importance que ces autres aspects à gérer. Notre vision de l’expérience utilisateur est brouillée par le nombre d’aspects que nous devons gérer dans notre rôle de développeur·euse.

Il est temps de donner plus de place à l’experience utilisateur dans la phase de développement. De la même manière que l’on parle de design centré sur l’utilisateur (user centered design), nous avons beaucoup à gagner à centrer un peu plus nos développements sur les utilisateur·ices.

C’est trop compliqué…

Dans les discussions avec l’équipe de montage de notre chauffage, nous arrivons souvent à des responses comme « c’est trop compliqué ! » ou même « ce n’est pas possible ! ». En posant des questions pour en savoir plus, nous réalisons souvent que la vraie réponse est plus nuancée.

En tant que développeur·euse, il est tentant de raccourcir une discussion en invoquant une complexité technique sans donner plus de détails. C’est pratique, quand on a déjà tellement d’autres choses à gérer comme on l’a vu plus tôt, mais le plus souvent nuisible à la collaboration. Cela donne l’impression au designer que l’on veut cacher la poussière sous le tapis et altère la relation de confiance.

Une meilleure façon de procéder est de parler directement des conséquences. Mettre à plat l’impact technique d’une nouvelle fonctionnalité permet de montrer notre engament à construire un produit de qualité. C’est aussi un bon exercice pour mettre nos instincts au défi : vraiment se poser la question si la valeur pour l’utilisateur·ice ne vaudrait quand même pas un code légèrement plus complexe.

Il n’est parfois pas facile d’expliquer des concepts techniques à des personnes qui n’ont pas beaucoup de connaissances techniques. Le secret est de relier les impacts techniques à des impacts sur l’expérience des utilisateur·ices. Par exemple, quand nous choisissons entre sauver des données dans le navigateur comme les cookies, le sessionStorage, ou encore l’URL, quelles sont les conséquences pour l’utilisateur·ice ? Quand va-t-iel perdre ses données ? Ses données sont-elles sécurisées ?

En observant beaucoup de ces échanges, je peux attester qu’ils mènent a de bien meilleurs produit pour les utilisateurs.

Conclusion

Le plaisir de l’utilisateur·ice est trop souvent perdu de vue pendant la phase de développement.

Pour améliorer la qualité des produits que l’on crée, nous pouvons :

• ne pas déléguer le design seulement aux designers ;
• donner une place plus grande au plaisir de l’utilisateur·ice dans le développement ;
• oser plus souvent considérer des solutions qui nous paraissent complexes techniquement avant de les dénier.

Les bénéfices sont multiples :

• une qualité accrue des produits ;
• des designers plus conscients de l’impact de leurs designs ;
• des développeur·euses qui ont plus d’impact ;
• une collaboration plus efficace.