In einem UX/UI-Designprojekt, bei dem UX sich auf die Reise konzentriert, fokussiert sich UI tatsächlich auf Zustände und Zustandsübergänge. Ein Zustandsdiagramm ist ziemlich flexibel, Sie können es an Ihre Bedürfnisse anpassen. Bonus: Entwickler können es leicht verstehen. Lassen Sie uns sehen, was es ist und wie Sie es nutzen können.
Was ist ein Zustandsdiagramm?
Ein Zustandsdiagramm ist ein Darstellungswerkzeug, das „zur Beschreibung und Analyse der verschiedenen möglichen Zustände einer Entität innerhalb eines Systems verwendet wird“ (Business Analyst Body of Knowledge, v3, 2015). Eine Entität kann jedes Objekt innerhalb eines Systems sein, abhängig davon, welches System Sie entwerfen oder analysieren. In einem Designsystem ist die Entität bereits sehr gut definiert: Sie wird als Komponente bezeichnet, z.B. eine Farbe, ein Knopf, eine Überschrift, eine Tabelle, eine Seite.
Ein Zustand ist auch eine bekannte Definition im UI-Design: z.B. kann ein Knopf einen gedrückten Zustand und einen Standardzustand haben. Nicht alle Komponenten haben verschiedene Zustände, typischerweise hat eine Primärfarbe keine Zustände, aber die Komponenten, die diese Primärfarbe verwenden, könnten welche haben. Diese Entitäten können Zustände haben, die entweder von sich aus etwas „tun“ oder als Ergebnis einer Benutzeraktion. Der Korb in einem Webshop kann leer oder nicht leer sein, ein Feld in einem Formular kann aktiv oder inaktiv sein usw. Komplexere Komponenten können auch Zustände haben: Eine Suchergebnisliste kann leer sein und sich in diesem Zustand anders verhalten im Vergleich zu dem Zustand, wenn Ergebnisse in der Liste vorhanden sind.
Eine Komponente, die mehrere Zustände haben kann, durchläuft diese Zustände in einer vordefinierten Abfolge, und in den meisten Fällen folgt der Übergang von einem Zustand zu einem anderen bestimmten Regeln. Z.B. kann in einem Webshop der leere Korb nicht den Zustand „bezahlt“ haben, zuerst muss er etwas enthalten. Ein inaktiver Knopf kann nicht den gedrückten Zustand haben, zuerst muss er aktiv sein. Wenn also eine Komponente mehrere Zustände hat, sind nicht alle Übergänge (von einem Zustand zum anderen) gültig.
In einem Zustandsdiagramm verwenden wir Kästen, um Zustände darzustellen, und Pfeile, um gültige Zustandsübergänge darzustellen. Zustandsdiagramme sind eine Art ergänzende Methode zu den Aktivitätsdiagrammen: Im Aktivitätsdiagramm repräsentieren die Kästen Aktivitäten (Übergänge) und die Pfeile zeigen die Zustände.
Lassen Sie uns ein Beispiel betrachten. Wir haben das Design in einem Implementierungsprojekt für ein Dokumentenmanagementsystem für ein Pharmaunternehmen durchgeführt. In diesem System könnte das Dokument die folgenden Zustände haben:
- Bearbeiten: Vom Zeitpunkt der Erstellung des Dokuments durch den Benutzer können sie es bearbeiten. Bis zu dem Punkt, an dem der Eigentümer des Dokuments es zur Genehmigung sendet, betrachten wir es als in Bearbeitung.
- Warten auf Genehmigung: In diesem Zustand kann das Dokument nicht bearbeitet werden und es liegt bei den Managern, die es entweder genehmigen oder ablehnen können. Sobald es genehmigt ist, geht es in die genehmigte Phase über. Wird es abgelehnt, geht es zurück zur Bearbeitung.
- Genehmigt, wartet auf Unterschrift: Wenn alle Genehmiger das Dokument genehmigt haben, geht es an eine weitere Managementebene zur Unterschrift. Die Unterzeichner können es immer noch ablehnen, dann geht es zurück zur Bearbeitung. Oder alle Unterschriften sind gesammelt, dann geht es in den unterzeichneten Zustand über.
- Unterzeichnet: Alle Unterzeichner haben ihre Unterschrift gegeben, das Dokument kann intern verteilt oder an den Lieferanten zurückgesandt werden, abhängig von der Art des Dokuments. Es kann nicht mehr bearbeitet werden, es ist eine „endgültige“ Version.
- Ungültig: Es kann vorkommen, dass eine neue Version desselben Dokuments alle Unterschriften erhält (z.B. stellen Sie sich eine interne Urlaubsrichtlinie vor), die vorherige Version des Dokuments wird ungültig sein.
Lassen Sie uns sehen, wie diese Schritte in einem Zustandsdiagramm aussehen:
Ein Zustandsdiagramm, das ein Beispiel aus einem Dokumentenmanagementsystem zeigt.
Wie können wir ein Zustandsdiagramm verwenden?
Alle Darstellungsmethoden sind nur Empfehlungen. Wir können sie an unsere Bedürfnisse anpassen. Kein Lehrer steht hinter Ihnen, um zu überprüfen, wie genau Sie ein Zustandsdiagramm verwenden. Geschäftsanalysten lieben es, ihre Werkzeuge zu standardisieren, aber nur weil es ein formales Rechtschreibbuch Ihrer Sprache gibt, bedeutet das nicht, dass Sie nicht sagen können, was und wie Sie wollen. Ich werde zeigen, was ich meine.
Das Zustandsdiagramm im oben genannten Format mag auf den ersten Blick praktisch aussehen, aber es ist schwierig, weitere Informationen hinzuzufügen. Also lasst uns zuerst es eindimensional machen, lasst es uns abflachen. Das bedeutet, dass die Zustände in einer Reihe sein werden — es könnte dazu führen, dass zu viele Pfeile um sie herum sind, aber diesen Preis zahlen wir.
Zustandsdiagramm mit demselben Inhalt wie oben, aber diese Version ist "abgeflacht".
Jetzt können wir unserem Diagramm eine weitere Dimension hinzufügen, sodass es zu einer Matrix wird. Ich würde empfehlen, die Komponenten in der anderen Dimension hinzuzufügen, auf diese Weise können wir zeigen, wie jede Komponente in jedem Zustand aussieht. Sie können einfach eine Beschreibung hinzufügen oder die grafischen Versionen in die Matrix einfügen, es hängt davon ab, was leichter zu verstehen und zu erstellen ist. Ich würde empfehlen, nur jene Komponenten in diese Matrix einzufügen, die sich gemäß den Zuständen ändern, und nicht alle Komponenten in die Matrix einzufügen, um zu vermeiden, dass sie zu groß und unbrauchbar wird.
Außerdem können wir Funktionalitäten in den anderen Dimensionen hinzufügen und zeigen, welche Benutzergruppe die Rechte hat, auf die Funktionalitäten in jedem Zustand zuzugreifen.
Zustandsdiagramm mit einer zusätzlichen Dimension, die die Benutzerrechte in jedem Zustand zeigt.
Auf diese Weise erhalten wir eine Benutzerrechtematrix, und die Entwickler werden extrem glücklich sein. Ein weiterer Vorteil dieser Benutzerrechte vs. Zustandsmatrix ist, dass es keine Lücke gibt, da die Matrix alle Funktionen und alle Zustände enthält (und wir alle Zellen der Matrix gefüllt haben), kann es keinen Sonderfall geben, an den wir nicht gedacht haben.
Die gute Nachricht ist, dass die beiden vorherigen Matrizen auch kombiniert werden können: die Zustände, die Hauptkomponenten und die Privilegien können alle auf einer Matrix zusammengefasst werden.
Wie hilft das Zustandsdiagramm beim Design?
Ich glaube, Zustandsdiagramme sind natürliche Werkzeuge des UI-Designprozesses. Im UX konzentrieren wir uns auf die Kundenreise, die ein aktivitätsorientierter Ansatz ist. Ab dem Punkt, an dem wir die endgültigen Bildschirme entwerfen müssen, müssen wir unsere Denkweise in einen zustandsorientierten Ansatz ändern, um die UI-Komponenten aufzubauen und zu definieren, wie sich jeder Bildschirm verhalten muss. Menschen führen Prozesse durch, Bildschirme haben Zustände. Wenn wir die Reisen und Bildschirmflüsse bereits definiert haben, müssen wir die Zustände dieser Komponent en destillieren. In einigen Fällen sind diese Zustände trivial (aktiver vs. inaktiver Zustand eines Buttons), aber im Falle komplexerer Komponenten oder komplexerer Prozesse sind diese Zustände alles andere als trivial. Daher benötigen Sie ein gutes Werkzeug, um diese Zustände zu sammeln, zu beschreiben und darzustellen: Dies ist ein Zustandsdiagramm.
Ein Zustandsdiagramm ist auch ein Qualitätskontrollwerkzeug: Sobald Sie alle möglichen Zustände der Hauptkomponenten identifiziert haben, werden Sie sehen, ob Sie an alle Zustände der kleineren Komponenten gedacht haben. Ein Zustandsdiagramm ist in diesem Ansatz ein Werkzeug zur doppelten Überprüfung, ein Rahmen, der ausgefüllt werden muss.
Das Zustandsdiagramm hilft auch bei der Kommunikation mit den Entwicklern, da diese dazu neigen, Lücken in Ihrem prozessorientierten Design zu suchen. Sobald Sie alle Zustände definiert haben und alle Komponenten in jedem Zustand definiert sind: gibt es keine Lücke, und der Entwickler ist zufrieden, was bereits die halbe Miete ist.
Artikel produziert von unserer Tochtergesellschaft Works.