Unterschiede zwischen FLOW CHART und UI FLOW

Viele Konzepte im UI-Design mögen in der Formulierung ähnlich erscheinen, in Wirklichkeit sind sie jedoch sehr unterschiedlich. Der taiwanesische Designer @Akane_Lee, der lange nichts gepostet hat, nutzte die Gelegenheit, um die Konzepte zu analysieren und die Funktionen von Flow Chart und UI Flow näher zu erläutern.

Ich habe seit fast einem Monat nichts mehr gepostet. Ich war damit beschäftigt, Geschäftspläne zu schreiben, Prototypen zu erstellen und Laborberichte zu erstellen. Ich muss in letzter Zeit eine Menge am UI-Flow regeln, und je mehr ich regele, desto verwirrter werde ich. Lassen Sie uns über UI-Flow und Flussdiagramm sprechen. Flow bedeutet „Prozess“, UI Flow ist der Seitenfluss und Flow Chart ist ein Flussdiagramm. Das sind zwei völlig unterschiedliche Diagramme.

UI-Designer sind mit UI-Flow sehr vertraut, kennen sich aber möglicherweise nicht mit Flussdiagrammen aus. In der Softwareentwicklung werden Flussdiagramme normalerweise von SA geschrieben, wobei die Betonung auf „Beurteilung“ liegt. Es ist nicht so schwierig. Stellen Sie es sich einfach als einen psychologischen Test in einer Zeitschrift vor: Wählen Sie „Ja“, um nach rechts zu gehen, und „Nein“, um nach links zu gehen.

Für RD müssen Sie vor dem Schreiben eines Programms zunächst die „Logik“ kennen, also den Betriebsrahmen, der aus verschiedenen „Urteilen“ besteht. Auch die Logik ist für die Benutzeroberfläche sehr wichtig. Welche Antwort sollte der Benutzer sonst nach der Operation erhalten?

Der einfachste Mitglieder-Login

Nehmen wir als Beispiel „Mitglieder-Login“. Wenn der Benutzer Konto und Passwort korrekt eingibt, wird er automatisch zur Mitgliedsinformationsseite weitergeleitet. Bei einer falschen Eingabe wird eine Fehlermeldung angezeigt …

Wenn Sie den UI-Flow nur aus der Funktionskarte zeichnen möchten, ignorieren Sie häufig, „was zu tun ist, wenn der Benutzer während der Bedienung einen Fehler macht“. In letzter Minute stellen Sie fest, dass in der Benutzeroberfläche etwas fehlt, und Sie müssen die fehlende Seite dringend hinzufügen. RD muss Funktionen hineinstopfen, was nicht elegant ist. Fehlermeldungen sind nichts, was man für eine Phase beiseite legen oder später hinzufügen kann. Seiten und Programme sind nichts, was man mit dem Mund zeichnen oder schreiben kann …

Wenn Sie etwas zufällig eingeben, gebe ich Ihnen einen Bestätigungscode

Scheint einfach, oder? Aber so einfach ist es nicht. Beim eigentlichen Zeichnen werden Sie feststellen, dass viele Dinge leicht übersehen und im UI-Flow nicht berücksichtigt werden. (Und wie könnte dies ohne das Hinzufügen von Funktionen so sein?)

Manchmal geben Benutzer immer wieder falsche Informationen ein und es ist davon auszugehen, dass jemand versucht, ihr Konto zu stehlen. Eine gängige Sperrmethode besteht darin, Benutzer, die mehrere falsche Informationen eingegeben haben, aufzufordern, ein zusätzliches Bestätigungscode-Feld auszufüllen. Das Flussdiagramm sieht folgendermaßen aus:

Das obige Bild ist nur eine einfache Flussdemonstration. Wenn Sie beiläufig sagen: „Hey, hilf mir, eine Bestätigungscodefunktion hinzuzufügen“, wird das Flussdiagramm plötzlich größer. Bei der Login-Verifizierung für echte Mitglieder gibt es noch mehr Tricks und Sicherheitsaspekte, wie zum Beispiel die Eingabeaufforderung „Passwort vergessen“ nach drei falschen Login-Versuchen oder noch gnadenlosere Methoden, bei denen das Konto direkt gesperrt wird und der Benutzer aufgefordert wird, sich beim Kundendienst zu beschweren.

Flussdiagramm und UI-Fluss ergänzen einander, und sogar das Flussdiagramm steht vor dem UI-Fluss. Wenn Sie einen UI-Flow ohne Flussdiagramm erstellen und nicht wissen, wie viele Urteile verarbeitet werden müssen, ist die Wahrscheinlichkeit fehlender Funktionen aufgrund schlechter Planung sehr hoch.

Wenn nur ein UI-Flow, aber kein Flussdiagramm vorhanden ist, kann sich der RD kaum vorstellen, wie das Flussdiagramm und die Beurteilungsformel basierend auf dem Bildschirm eingerichtet werden. Je größer das System ist, desto wahrscheinlicher ist es jedoch, dass Fehler auftreten, und die Wahrscheinlichkeit von Fehlern wird durch die Erfahrung des RD bestimmt. Aber ohne UI Flow ist es wie ein blinder Mann, der einen Elefanten berührt, wenn man sich nur auf ein paar Wireframes oder Mockups verlässt. RD weiß nicht, wie man die Seiten aneinanderreiht, wenn man sich ein einzelnes statisches Bild ansieht, und es wäre seltsam, wenn man dies nur mit der eigenen Vorstellungskraft gut hinbekäme.

Wenn Sie nichts geben und dem RD einfach einen Prototypen vorlegen und ihn bitten, ihn zu kopieren und einen identischen zu bauen, wäre es einfach, oder? Der RD muss auf jedem Bildschirm jede Taste drücken und verschiedene Fehler ausprobieren, bevor er weiß, wie er die Funktionen verbinden muss. Wie sehr hassen Sie RD dafür, dass er ihm das angetan hat ...

Quellen:

Flussdiagramm – MBA Think Tank Enzyklopädie

Flussdiagrammbeschreibung

Aus der Perspektive eines UI-Designers kann das Flussdiagramm wie folgt betrachtet werden: „Wie gehen Benutzer vor, um Aufgaben in diesem Szenario zu erledigen, und wie reagiert die Software?“ Der UI-Flow kann erweitert werden zu „Da der Benutzer auf diese Weise vorgeht und wir diese Funktionen und Informationen präsentieren müssen, sind die Seiten auf diese Weise verknüpft.“

Ein UI-Designer muss nicht unbedingt in der Lage sein, ein Flussdiagramm zu zeichnen, aber er oder sie muss in der Lage sein, es zu verstehen. Gängige Flussdiagrammsymbole sind festgelegt. Entwerfen Sie keinen neuen Stil, nur weil er hässlich aussieht. Der RD wird den Spieß definitiv umdrehen.

Es gibt ein berühmtes Sprichwort: „Das Wasser, das vor der Ehe in Ihr Gehirn gelangt, sind die Tränen, die Sie nach der Ehe vergießen.“ Wenden wir dieses Sprichwort auf die Softwareentwicklung an: „Das Gehirn, dem Sie vor der Arbeit nicht genügend Zeit widmen, ist die Leber, die nach der Arbeit geschädigt wird.“ Es gibt so viele Funktionen, an die in der Frühphase nicht gedacht wurde, wie es Arbeitsstunden gibt, mit denen in der späteren Phase nicht gerechnet wurde …