Problématiques de développement

Architecture et Base de données
Du design à la réalité du développement

Concevoir le processus de recherche est un travail collectif, et ce avec notamment, les développeurs. Nous verrons dans cette partie en quoi intégrer les équipes techniques le plus en amont possible lors de la conception peut nous sauver beaucoup de temps et de réflexion en nous apportant des solutions que nous designers n’auraient même pas envisagées.

Se connecter avec les développeurs permet d’avoir une idée de leurs défis et de leurs problématiques. Si nous ne sommes pas familiers au développement d’applications mobiles, nous allons vite déchanter si nous partons avec les mêmes attentes que du web.

Architecture et Base de données

La construction de l’architecture de développement est un point crucial du développement de notre application. Le plus souvent elle s’articule autour d’une base de données liée à une API, qui servira comme interface pour communiquer avec celle-ci. En tant que designers, notre rôle n’est pas de décider si telle ou telle architecture est meilleure qu’une autre, car ce n’est pas notre métier, mais plutôt de communiquer aux équipes de développement le plus possible sur notre interface, les données disponibles sur l’interface et notre logique d’architecture de l’information.
La construction de l’API et de l’architecture sont des procédures plutôt lentes, il est donc important de mettre à plat en amont du projet les différents aspects de l’application avec les équipes de développement.

Dans le cas du moteur de recherche, il est très important de se poser quelques questions afin de communiquer au mieux notre visualisation de l’interface de recherche. Quelques exemples choisis :

Quelles informations des produits sont visibles sur la page des résultats de recherche ?
Sur quelles données du produit les mots-clés de la recherche peuvent-elles matcher ?
Quels facteurs définissent l’importance d’un résultat, ce qui le fera remonter dans la liste ?
Pour plus d’informations concernant la gestion de ces facteurs, voir la prochaine partie concernant les algorithmes qui y est consacrée.

Du design à la réalité du développement

En tant que designer il est primordial d’appréhender les difficultés et les facilités de développer sur des plateformes différentes dans le cas d’applications natives, ou les contraintes liées aux applications hybrides ou aux pwa.
Nous découvrirons assez vite qu’il est, par exemple, très compliqué d’implémenter un en-tête fixe sur Android ou une vue horizontale scrollable sur IOS.

Brief et scénarios

Selon ma conception et mon historique (junior, il est vrai 😉) de la gestion de projet, c’est notre rôle d’aider au maximum les développeurs dans l’anticipation des scénarios d’usages, en complément du brief de design et d’architecture.

Pourquoi ? Parce que le moteur de recherche est un point de contact direct avec l’utilisateur, avec plus ou moins de liberté d’action pour celui-ci. Je suis sûr que tout comme moi, vous êtes encore surpris par leur créativité à toute épreuve quand il s’agit d’utiliser nos chères interfaces.
C’est encore plus vrai sur un moteur de recherche, et cela dépendra de sa nature. Le principal scénario d’usage à prévoir restant celui-ci :

Que faire en cas d’absence de résultat ?

Asos Zalando

Asos (Android) et Zalando (Android)

Nous ne devons pas laisser l’utilisateur dans une impasse pendant le processus de la recherche, le risque étant d’engendrer de la frustration. Proposons des options ou des alternatives. L’exemple de Zalando et d’Asos sont symboliques des applications e-commerces proposant souvent des alternatives de produits populaires ou matchant à minima avec un mot-clé de la requête. On observe également sur d’autres types d’applications des propositions liées à une faute d’orthographe initiale dans la requête, ou des produits correspondant à une partie de la requête.

Orthographe

Voici comment les utilisateurs de Google écrivent “Britney Spears”

Les fautes d’orthographe sont si courantes dans la recherche, surtout dans le cas du mobile où le clavier est encore moins utilisable que celui sur ordinateur, à cause de l’espace limité entre les touches. Il est donc très important que vos résultats de recherches comprennent un système de reconnaissance des fautes d’orthographe. Anticiper l’intention de l’utilisateur en corrigeant leurs fautes permettront de réduire considérablement leur frustration et ainsi améliorer l’expérience globale.

Comment y parvenir ?

Les technologies de moteurs de recherches intégrés, comme Algolia ou Elastic, proposent chacun des solutions respectives ( respectivement Typo Tolerance et Fuzziness ). En se basant sur le lexique de la langue choisie, ils établissent des “niveaux” de fautes ( Distance sur Typo Tolerance ), grâce à la distance de Levenshtein.
La Distance de Levenshtein est un algorithme permettant de calculer la ressemblance entre deux chaînes de caractères, avec comme résultat une “distance”. Cette distance est d’autant plus grande que le nombre de différences entre les deux chaînes et le nombre de caractères à supprimer/échanger/déplacer pour passer d’une chaîne à l’autre sont grands.

C’est au développeur mais aussi à nous de choisir quel niveau de tolérance l’application requiert, car elle définira le niveau d’aide que nous proposons à l’utilisateur.
On peut donc imaginer que plus le lexique de notre application sera complexe, plus le niveau de tolérance sera élevé.

Autocomplete

Nous devons nous assurer que les suggestions automatiques sont utiles, et surtout, rapides. Certaines mal désignées peuvent distraire ou embrouiller l’utilisateur. Des suggestions orthographiques, de mots racines ou de prédictions sont autant de méthodes permettant d’accompagner l’utilisateur sans le brusquer.

Tout d’abord il est intéressant de savoir que, si cela n’est pas pris en compte par les développeurs, une lettre tapée par l’utilisateur équivaut à une requête envoyée au serveur.
Ce qui peut s’avérer endommager l’expérience utilisateur, notamment sur l’autocomplete, où une requête à chaque lettre rendrait l’autocomplete soit pas assez réactif, soit trop envahissant car il proposerait une nouvelle autocomplétion à chaque lettre.

Une solution est d’attendre un temps donné avant d’envoyer cette requête. Il doit évidemment être assez court, mais aussi assez long pour laisser l’utilisateur finir de taper son mot ou son début de mot, et d’attendre ensuite la proposition d’autocomplétion.
Une autre solution est d’attendre un certain nombre de caractères, souvent trois, avant de procéder à la requête, car cela réduit le coût de la recherche en termes de requêtes, mais aussi car cela permet de proposer des suggestions beaucoup plus pertinentes.

Nous devons proposer moins de cinq résultats, sans scroll, afin que les suggestions ne deviennent pas encombrantes. Mettons en valeur les différences entre le texte entré et les suggestions proposées, soit par une graisse ou un type de texte différent.