Est-il approprié ou judicieux de fusionner deux entrées de recherche similaires?
J'ai une équipe d'application qui construit un composant de recherche simple dans lequel il y a deux champs. Les deux acceptent une valeur numérique uniquement qui représente les clés primaires dans deux tables différentes. Serait-il préférable que ces domaines soient combinés du point de vue de l'utilisabilité ou devrions-nous les garder séparés? Y a-t-il des avantages à les garder séparés comme indiqué ci-dessous?
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Information additionnelle:
Peu importe ce que l'utilisateur entre, dans l'un ou l'autre champ, le même tableau lui est présenté. L'utilisateur ne peut pas remplir les deux entrées en même temps.
Pour plus de précision, il s'agit d'un système de tâches. La première zone de saisie permet aux utilisateurs d'entrer un nombre (jusqu'à 9 chiffres) qui représente une tâche spécifique ou un ensemble de tâches (c'est-à-dire toutes les tâches commençant par 100 * ou la tâche portant le numéro 123456789). La deuxième entrée permet à l'utilisateur de rechercher toutes les tâches liées à un numéro de client spécifique. Pour la deuxième entrée, l'utilisateur doit saisir le numéro complet.
Si je comprends bien, l'utilisateur sait ce qu'il recherche. L'utilisateur doit donc décider s'il s'agit d'une recherche de tâche ou d'une recherche d'utilisateur.
- Si le système est en mesure de décider si l'entrée est un numéro de tâche ou un champ numéro un client, ce serait mieux parce que l'utilisateur ne serait pas obligé de décider. Dans le cas, il y a des hits sur les clients et sur les tâches que vous pourriez demander à l'utilisateur qui doit être affiché dans la liste des résultats. Si cela se produit souvent, la demande serait ennuyeuse. Mais si cela ne se produit que parfois, cela pourrait être une possibilité.
- S'il n'est pas possible de laisser le système décider, vous pouvez afficher un champ de recherche et afficher deux boutons "Rechercher un utilisateur" et "Tâche de recherche". Avantage: comme il n'y a qu'un seul champ d'entrée, la mise au point est toujours au bon endroit. L'utilisateur peut simplement commencer à taper sans se soucier s'il est dans le bon champ de saisie. Avec deux champs, il y a toujours la possibilité que l'utilisateur tape dans le mauvais champ et il est difficile de taper à nouveau le numéro dans l'autre champ.
Si le système peut déterminer si les données sont une identité1 ou une identité2, je vous recommande de n'avoir qu'un seul champ et un seul bouton d'envoi, et d'ajouter une étiquette (ou un espace réservé) pour expliquer que vous pouvez donner une identité1 ou une identité2.
Par exemple, supposons que Identity1 est un nom et Identity2 est une adresse, vous pouvez avoir:
Plus généralement, vous pouvez avoir quelque chose comme ça pour Identity1, Identity2, ... IdentityN:
La chose seulement est de pouvoir reconnaître l'identité d'une donnée. Si vous ne le pouvez pas, il est également possible de rechercher dans toutes les identités la présence des données.
Les deux champs se comportent-ils différemment ou sont-ils exactement les mêmes, mais l'utilisateur voudra insérer plusieurs éléments de recherche? Si l'utilisateur souhaite simplement ajouter plusieurs critères de recherche, vous pouvez utiliser une entrée qui accepte plusieurs entrées comme Sélectionnez 2 .
Pouvez-vous d'abord nous dire pour quelles raisons vous avez décidé ce dont les futurs utilisateurs de l'interface avec ces zones de recherche auront besoin?
Comme vous le savez, nous sommes là pour concevoir pour les utilisateurs, mais vous avez dit que votre équipe est plus convaincue par l'une ou l'autre solution.
Je suis sûr que vous devriez le tester avec des utilisateurs de cette industrie spécifique. Ce n'est pas un scénario courant et nous ne savons pas assez sur leurs préférences et le contexte pour décider pour eux. Les gens qui travaillent avec une telle interface sont déjà habitués à certains types de convivialité et de conception, vous devriez donc leur demander!