Votre expert n’est pas votre utilisateur

Les experts offrent des informations, mais ce ne sont pas vos utilisateurs. Construisez de meilleurs logiciels en équilibrant la contribution interne avec la rétroaction du marché.

Si vous développez ou concevez des logiciels d’entreprise, en particulier pour les applications spécifiques à l’industrie, vous reconnaissez probablement les utilisateurs qui commencent comme ceci:

En tant qu’utilisateur, je voudrais… pour que je puisse…

Il capture une partie critique et essentielle du développement de logiciels:

Comprendre votre utilisateur. Construire pour votre utilisateur.

La réalité est que les utilisateurs n’ont pas toujours leur mot à dire dans le processus de développement.

En tant que concepteur UX, mon rôle était de représenter la perspective de l’utilisateur. Cela signifiait faire des recherches – en cours, parler aux utilisateurs, poser des questions et comprendre leur comportement par l’empathie et les méthodes éprouvées.

À la fin de la journée, je voulais concevoir en pensant à l’utilisateur.

Et il en va de même pour les développeurs. Ils posent des questions sur la logique, le flux et les résultats parce que ce que nous essayons en fin de compte de faire est simple:

Créer des logiciels qui aident quelqu’un à accomplir une tâche.

Mais mes utilisateurs étaient sur le terrain. Ils ont travaillé sous la pression du temps. Ils étaient en quarts de 12 heures. Ils étaient partout dans le monde. Ce n’était pas aussi simple que de sauter sur un appel, d’envoyer une enquête ou de les rendre visite sur place.

La vérité est: il est courant pour les développeurs et les concepteurs de créer des logiciels à distance. Et, malheureusement, la recherche sur les utilisateurs n’est pas toujours suffisamment hiérarchisée pour inclure la saisie des utilisateurs comme constante dans le processus.

Donc, ce que la plupart des entreprises font – et à juste titre – sont en cours d’expertise. Ils apportent l’expert. Comme intermédiaire.

Mais c’est aussi risqué.

Parce que l’expert n’est pas votre utilisateur.

Comment les experts apparaissent dans le développement de logiciels

La plupart des organisations qui construisent des logiciels d’entreprise ont une expertise interne. La forme que l’expertise prend peut varier – selon la phase du projet, le niveau de soutien organisationnel, le contexte stratégique, la participation au leadership et comment la conception est intégrée au développement.

D’après mon expérience, la participation des experts apparaît généralement de trois manières:

Consultants et analystes commerciaux internes ou externes

Ces personnes traduisent les besoins des clients – y compris ceux de l’utilisateur final – dans quelque chose sur lequel l’entreprise peut agir. Ils sont généralement concentrés en externe et disponibles uniquement dans un rôle réactif. Certains sont à temps plein, d’autres à temps partiel.

Propriétaires de produits ou chefs de produit

Ce sont généralement des gens qui venaient du terrain ou du domaine et qui y ont ensuite emménagé ou un développement. Ils peuvent ne plus représenter pleinement la perspective de l’utilisateur final – bien qu’un bon propriétaire de produit reste près de lui.

La PME – expert en matière de subjectif

Appelons-les simplement «l’expert»: quelqu’un qui a joué le rôle de l’utilisateur lui-même – ou le fait toujours à temps partiel. Les PME servent souvent de représentants internes de ce rôle.

Dans les équipes sur lesquelles j’ai travaillé, nous avons jumelé chaque fonctionnalité avec une PME et généralement travaillé dans un triangle: PME, concepteur UX et propriétaire de produit. Chacun a apporté un angle légèrement différent, mais nous avons partagé un objectif: découvrir, créer et définir les bonnes exigences du produit.

4 pièges à éviter lorsqu’ils comptent sur les experts

Travailler avec des experts est une bénédiction – car honnêtement, vous ne pouvez pas savoir ce qu’ils savent. Vous n’avez pas vécu ce qu’ils ont vécu. Et vous ne le ferez probablement jamais.

J’ai travaillé avec de nombreux experts différents. Et il y a quatre choses que vous devez absolument éviter lorsque vous le faites.

Biais d’experts

Ceci est souvent appelé la malédiction de la connaissance: en supposant que les autres savent ce que vous savez.

Une chose très courante que j’ai entendue des experts lors de la simplification des flux de travail ou de l’ajustement de la terminologie:

« L’utilisateur n’est pas stupide. »

Cette simple déclaration révèle une plus grande tension: la simplicité par rapport à la complexité.

Les experts sont habitués à travailler sur des projets à charge cognitive à haute teneur. Ils sont confortables à dépenser de l’énergie à comprendre. Mais une bonne conception est destinée à réduire cette charge – pour rendre les décisions plus faciles et aider les gens à se déplacer plus rapidement.

En supposant que tout le monde sait ce que sait l’expert mène à sur-complication. Et cela crée souvent des obstacles pour les utilisateurs subalternes – les personnes mêmes que votre produit devrait également prendre en charge.

Anecdote sur les preuves

Les histoires comptent. Les experts aident à visualiser et à humaniser ce que les utilisateurs passent.

Mais le risque est que les anecdotes commencent à ressembler à des faits – et les preuves réelles sont ignorées.

Un expert peut se souvenir de détecter un flux ou d’éviter une fonctionnalité, mais cela ne signifie pas qu’il est inutile. Cela signifie simplement que nous devons vérifier les données.

J’ai vu des experts devenir des sources de vérité, remplaçant complètement la recherche. Et lorsque cela se produit, les données cessent de conduire des décisions.

Excessive à une seule voix

Les données vous donnent une échelle. Il apporte une entrée de toute la base d’utilisateurs – pas une seule voix. Mais lorsque les équipes comptent trop sur un expert, le produit peut être trop basé sur les préférences personnelles.

Je l’ai vu se produire: pas de place pour d’autres perspectives, pas d’espace pour les idées de non-experts. En fin de compte, nous ne concevons pas pour les utilisateurs. Nous concevions pour l’expert.

Sauter la validation du marché

Cela pourrait être le plus grand risque de tous.

À la fin de la journée, avoir un expert de l’équipe peut vous conduire à la validation de sauts. Je l’ai vu moi-même: nous avions le potentiel, mais nous n’avons pas assez écouté le marché. Nous avons itéré en interne – mais perdu l’opportunité du marché.

Sans commentaires des utilisateurs, nous avons supposé que nous avions raison. Et nous étions proches. Mais pas assez proche.

3 façons de faire des experts vos alliés

Recoupement

Validez vos hypothèses, avec des tests, avec des recherches. Vérifiez tout. Avec des données.

Assurez-vous que votre expert est un véritable défenseur – un écho du marché, pas un substitut pour cela. Lorsque cela sera vrai, leur contribution, leur expérience et leurs idées renforceront l’ensemble de votre cycle de développement.

Vous vous déplacerez plus vite et plus intelligemment car votre équipe détient déjà une grande partie des informations nécessaires. Cela réduit le besoin de phases de recherche coûteuses et longues.

Collaborer

L’expert ne devrait pas rédiger des exigences et s’attendre à ce que nous suivions. Cela doit être un effort de collaboration.

J’ai vu des développeurs changer comment les experts pensent du domaine. Cela a fait de la place pour une véritable innovation. J’ai également fait la recherche d’utilisateurs côte à côte avec des experts. J’interviewerais les utilisateurs et poserais les questions «stupides»:

Pourquoi faites-vous cela? Qu’est-ce que c’est? Qu’est-ce que cela signifie?

Mais j’ai amené l’expert en tant que traducteur.

Coffre

J’ai travaillé avec des experts incroyables qui avaient une vision claire pour l’avenir. Ils savaient comment les logiciels pouvaient changer le jeu. Ils avaient ressenti la douleur. Ils avaient utilisé de mauvais outils. Ils savaient ce qui manquait.

Ainsi, lorsque nous nous sommes co-infiés (croquis, wireframes, prototypes), nous avons construit certaines des meilleures fonctionnalités que j’ai vues. Nous avons en fait construit des fonctionnalités de pointe et révolutionnaire.

Dans ces moments, je n’étais pas le designer. J’étais le facilitateur. L’expert a dirigé la réflexion.

Et déverrouiller ce genre de créativité? Cela entraîne un réel succès.

Conclusion: Respectez l’expert, défendez l’utilisateur

La vérité est qu’avoir un expert de votre équipe est une mine d’or. Cela peut vous donner un véritable avantage, mais c’est aussi un risque. Un piège potentiel. Assurez-vous qu’ils sont un défenseur d’un utilisateur, pas un remplaçant pour l’utilisateur.

Collaborer. Travailler ensemble. Mais ne perdez jamais la représentation de l’utilisateur.

En fin de compte, c’est le marché qui vous dira ce qui fonctionne – pas les personnes qui construisent le logiciel.

Et honnêtement, je n’aurais pas pu le faire sans un expert à mes côtés.

Mais sans utilisateurs? Il n’y aurait pas eu de point de le faire du tout.