Maison  >  Article  >  interface Web  >  Quelles sont les différences entre FLOW CHART et UI FLOW ?

Quelles sont les différences entre FLOW CHART et UI FLOW ?

php中世界最好的语言
php中世界最好的语言original
2018-01-25 11:25:031518parcourir

Cette fois, je vais vous présenter les différences entre FLOW CHART et UI FLOW, et quelles sont les précautions lors de l'utilisation de FLOW CHART et UI FLOW dans des projets. Ce qui suit est un cas pratique, jetons un coup d'œil. .

De nombreux concepts de conception d'interface utilisateur ne semblent peut-être pas très différents sur le papier, mais en réalité, ils sont très différents. Le professeur @Akane_Lee, un designer taïwanais qui n'a pas posté depuis longtemps, en a profité pour analyser des concepts et développer les fonctions de Flow Chart et UI Flow~

Cela fait presque un mois que j'ai posté, occupé à rédiger des projets, à travailler sur des prototypes, à rédiger le rapport des étudiants en laboratoire. Récemment, j'ai dû trier de nombreux flux d'assurance-chômage, et plus je les règle, plus mon cerveau se sent en désordre. Parlons du flux et de l'organigramme de l'interface utilisateur. Le flux est un "processus", le flux UI est le flux des pages et le diagramme est un organigramme. Les deux sont des organigrammes complètement différents.

UI Designer connaît très bien UI Flow, mais n'est peut-être pas familier avec Flow Chart. Dans le développement de logiciels, Flow Chart est généralement écrit par SA, et l'accent est mis sur le « jugement »... Ce n'est pas si difficile. Considérez-le comme un test psychologique attaché à un magazine. Si vous choisissez « Oui », allez sur. vers la droite, et si vous choisissez « Non », allez vers la gauche.

Pour RD, avant d'écrire un programme, il faut d'abord connaître la « logique », qui est l'opération structure composée de divers « jugements ». La logique est également très importante pour l'interface utilisateur, sinon quelle réponse l'utilisateur doit-il lui donner après l'opération ?

La connexion membre la plus populaire

En prenant comme exemple « Connexion membre », l'utilisateur saisit le mot de passe du compte, si la saisie est correcte, il passera automatiquement à la page d'informations du membre. Si la saisie est incorrecte, un message d'erreur apparaîtra...

Je veux juste dessiner le flux d'interface utilisateur à partir du. Carte fonctionnelle. J'ignore souvent "Que faire si l'utilisateur fait une erreur d'opération", et ne découvre qu'au dernier moment qu'il y a une faille. L'interface utilisateur ajoute de toute urgence les pages manquantes, la fonction du plug-in RD est inélégante et. les invites d'erreur ne peuvent pas être laissées à l'étape suivante ou ajoutées lorsque vous avez le temps. Les pages et les programmes ne sont pas dessinés et écrits oralement...

Entrez au hasard et je vous donnerai un code de vérification

Cela semble très simple. Ce n'est pas que ça. Lorsque vous dessinez réellement, vous constaterez qu'il y a beaucoup de choses qui sont facilement négligées dans l'UI Flow. (Et comment cela pourrait-il être ainsi sans ajouter de fonctions ?)

Parfois, les utilisateurs continuent de taper des erreurs. Il est raisonnable de supposer que quelqu'un essaie de voler le compte. Une méthode de blocage courante consiste à demander aux utilisateurs qui effectuent plusieurs entrées incorrectes de remplir un champ de code de vérification supplémentaire. Ainsi, l'organigramme devient :

L'image ci-dessus n'est qu'une simple démonstration de processus, mais si vous dites simplement "Hé, aidez-moi à ajouter une fonction de code de vérification", l'organigramme deviendra soudainement plus gros. Il existe d'autres astuces et considérations de

sécurité pour la vérification de la connexion d'un membre réel. Par exemple, si vous vous connectez de manière incorrecte trois fois, le message "mot de passe oublié" vous sera demandé, etc., ou encore plus sévèrement, le compte sera directement verrouillé et l'utilisateur sera invité à faire appel au service client.

Flow Chart et UI Flow se complètent, et même Flow Chart vient en premier avant UI Flow. Lorsqu'il n'y a pas d'organigramme et que vous ne savez pas combien de jugements traiter, le flux d'interface utilisateur est généré. La probabilité de fuite de pages en raison d'une mauvaise planification est très, très élevée.

S'il n'y a qu'un flux d'interface utilisateur et aucun organigramme, RD peut à peine imaginer l'organigramme et comment utiliser la formule de jugement basée sur l'image. Cependant, plus le système est grand, plus il est probable qu'il en ait. bugs. Le taux d'affrètement est déterminé en fonction de la valeur de l'expérience de RD. Mais il n'y a même pas d'UI Flow. Se fier à quelques Wireframes ou Mockups est simplement un aveugle essayant de comprendre l'éléphant En regardant une seule image

statique, le RD ne saura pas comment relier l'éléphant. pages. Il est étrange de se fier uniquement au brainstorming.

Si vous ne me donnez rien, jetez simplement le prototype à RD et demandez-lui de le copier. Est-il facile d'en faire un exactement pareil ? RD doit également appuyer sur chaque

bouton sur chaque écran Ce n'est qu'après avoir observé et essayé diverses erreurs que vous saurez comment connecter la fonction. À quel point détestez-vous RD pour avoir traité les gens comme ça... Du point de vue d'un concepteur d'interface utilisateur, vous pouvez considérer l'organigramme comme « comment l'utilisateur opère pour accomplir la tâche dans cette situation, et comment le logiciel répond", étendant UI Flow à "parce que l'utilisateur fonctionne de cette manière, et nous avons ces fonctions et informations à présenter, donc les pages sont connectées de cette manière."

UI Designer n'a pas forcément besoin d'être capable de dessiner un Flow Chart, mais il doit être capable de le comprendre. Les symboles courants des organigrammes sont corrigés. Ne concevez pas un nouveau style simplement parce qu’il a l’air moche. RD va certainement renverser la situation.

Il y a un dicton célèbre : « L'eau dans votre tête avant le mariage, ce sont les larmes que vous versez après le mariage. » Lorsqu'on l'applique au développement de logiciels, « Le cerveau qui est le moins dépensé avant de commencer à travailler est le foie qui le fera. être blessé après avoir commencé à travailler. Combien de fonctions n'étaient pas attendues au début et combien d'heures de travail n'étaient pas attendues plus tard...

Je pense que vous maîtrisez les méthodes après avoir lu ces cas. Pour des informations plus intéressantes, veuillez faire attention aux autres articles connexes sur le site Web PHP chinois !

Lecture connexe :

Comment définir le centrage horizontal et vertical des éléments HTML


Quelles sont les balises couramment utilisées en XHTML

Comment utiliser les annotations de lignes horizontales et les commentaires de code en HTML

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn