Navegação Mobile
UX Design
Times Pequenos
Prototipagem
Arquitetura de Informação

App-Navigationsfluss: Tools für kleine Teams, um bessere Entscheidungen zu treffen

Kleine Teams können sich nicht den Luxus leisten, den Navigationsfluss zweimal falsch laufen zu lassen; Das richtige Tool erkennt das Problem vor dem Code.

App-Navigationsfluss: Tools für kleine Teams, um bessere Entscheidungen zu treffen

In einem kleinen Team kostet jede fehlgeschlagene Navigationsentscheidung doppelt: einmal für den Aufbau, einmal für die Wiederholung. Und die Wiederherstellung eines Navigationsablaufs, nachdem er bereits in der Produktion ist, ist eines der teuersten Dinge, die eine App verlangen kann, da dadurch die Architektur, der Code und die Denkweise des Benutzers verändert werden, der den alten Weg bereits erlernt hat.

Der Navigationsfluss ist genau die Art von Problem, die am besten gelöst werden kann, bevor eine Codezeile existiert. Die schlechte Nachricht ist, dass kleine Teams diesen Schritt oft überspringen, weil sie denken, sie würden es „beim Bauen“ herausfinden. Sie erfahren es fast nie. Sie sammeln Bildschirme an, die nicht miteinander kommunizieren.

Dieser Text richtet sich an diejenigen, die nur wenige Hände haben und die richtigen Werkzeuge verwenden möchten, um den Ablauf gleich beim ersten Mal richtig hinzubekommen oder zumindest auf dem Papier einen billigen Fehler machen möchten, bevor sie im Code einen kostspieligen Fehler machen.

Warum Flow wichtiger ist als ein hübscher Bildschirm

Es ist verlockend, Figma zu öffnen und mit dem Zeichnen wunderschöner Leinwände zu beginnen. Aber screen ist ein Substantiv und flow ist ein Verb. Der Benutzer verwendet keine isolierten Bildschirme; er kreuzt einen Weg, um eine Aufgabe auszuführen. Wenn der Pfad verwirrend ist, gibt es keine schönen Bildschirmschoner.

Für ein kleines Team hat dies eine direkte praktische Auswirkung: Die Zeit, die für die Gestaltung des Navigationsflusses aufgewendet wird, bringt mehr Ertrag als die Zeit, die für das Polieren von Pixeln aufgewendet wird. Ein klarer Ablauf reduziert Nacharbeit, reduziert den Support und reduziert Abbrüche. Es ist die größte Hebelwirkung, die ein schlankes Team in UX tätigen kann.

Die Tools, die zu einem schlanken Team passen

Bei der Auswahl eines Tools für ein kleines Team kommt es vor allem auf ein Kriterium an: Es muss zu dem passen, was man bereits hat. Ein leistungsstarkes Tool, das einen engagierten Spezialisten erfordert, ist ein Luxus, den sich ein kleines Team nicht leisten kann.

Um den Fluss abzubilden

Vor der visuellen Gestaltung kommt die Karte. FigJam, Miro und Whimsical lösen den Schritt der Zuordnung von Benutzerpfaden mit Kästchen und Pfeilen gut. Sie sind kostengünstig, kooperativ und erfordern keine Schulung. Für ein Team aus zwei oder drei Personen spart es Wochen, wenn man hier beginnt und den Fluss als Diagramm vor allen Bildschirmen zeichnet.

Der eigentliche Vorteil dieser Tools besteht darin, dass sie den Fluss irrelevant machen. Ein Diagramm an der Wand erzwingt die Konversation „Moment, wie kommt der Benutzer von diesem Bildschirm zurück?“ geschieht vor dem Code, und genau dort kostet es weniger.

Für Prototyping und Tests

Figma ist der De-facto-Standard, und das aus gutem Grund: anklickbare Prototypen, wiederverwendbare Komponenten und Zusammenarbeit in Echtzeit in einem Plan, der in ein Startup-Budget passt. Für ein kleines Team ist die Möglichkeit, ein Wireframe in einen navigierbaren Prototyp umzuwandeln, ohne Code schreiben zu müssen, die Möglichkeit, den Ablauf mit echten Benutzern zu testen, bevor man sich an die Entwicklung macht.

Mit der Prototypenfunktion von Maze und Figma können Sie kostengünstige Remote-Usability-Tests durchführen. Sie benötigen kein Labor, sondern fünf Benutzer und einen Link.

Zur Validierung mit Daten nach dem Start

Sobald die App live ist, zeigen Tools wie Firebase Analytics oder Mixpanel, wo der Benutzer im tatsächlichen Ablauf stecken bleibt. Für ein kleines Team reicht das kostenlose Level dieser Tools in der Regel für lange Zeit aus. Wichtig ist, die Flow-Entscheidungspunkte von Anfang an zu instrumentieren, nicht erst, nachdem das Problem aufgetreten ist.

Wie würde ich das in der Praxis ordnen?

Zuerst kartieren, später zeichnen, immer validieren. Beginnen Sie mit dem Flussdiagramm in Whimsical oder FigJam. Erst wenn der Weg frei ist, gehen Sie zum Prototyp in Figma. Testen Sie mit fünf echten Benutzern. Anpassen. Erst dann bauen.

Diese Reihenfolge scheint offensichtlich, aber genau das überspringen kleine Teams unter dem Druck, „bald liefern“ zu müssen. Die Ironie besteht darin, dass das Überspringen der Flow-Phase die Lieferung nicht beschleunigt, sondern verzögert, da die Nacharbeit später eintrifft und umfangreicher ist.

Der häufigste Fehler in einem kleinen Team

Der klassische Fehler besteht darin, Bewegung mit Fortschritt zu verwechseln. Die gezeichneten Bildschirme vermitteln ein Gefühl des Fortschritts. Aber wenn der zugrunde liegende Ablauf falsch ist, ist jeder neue Bildschirm eine Schuld. Ich sah, wie kleine Teams zwanzig wunderschöne Bildschirme bauten, die mit einem Navigationsablauf verknüpft waren, bei dem der Benutzer sieben Mal tippen musste, um das zu tun, was eigentlich zwei Mal nötig gewesen wäre.

Ein weiterer Fehler besteht darin, zu viele Tools einzusetzen. Kleine Teams brauchen FigJam, Figma, Maze, Mixpanel und drei andere nicht. Sie benötigen einen zum Abbilden, einen zum Prototypenbau und einen zum Messen. Zu viele Tools bedeuten zu viele Lizenzen, zu viel Kontext und niemand beherrscht eines davon wirklich.

Navigationsmuster: Erfinden Sie nicht neu, was bereits funktioniert

Ein kleines Team hat weder Zeit noch Benutzer übrig, um neue Arten des Surfens zu erfinden. Und diese Einschränkung ist keineswegs ein Problem, sondern ein Vorteil: Konsolidierte Navigationsmuster existieren, weil sie funktionieren und weil der Benutzer sie bereits kennt.

Tabs unten für Hauptbereiche, konsistente Zurück-Geste, klare Hierarchie zwischen übergeordneten und untergeordneten Bildschirmen. Systeme wie das Material Design von Android und die Human Interface Guidelines von Apple dokumentieren diese Standards ausführlich. Für ein kleines Team erspart die Befolgung dieser Richtlinien Dutzende von Designentscheidungen und liefert eine App, die der Benutzer versteht, ohne etwas lernen zu müssen.

Die Kreativität eines schlanken Teams sollte sich auf die Einzigartigkeit Ihres Produkts, das Wertversprechen und die Kernfunktionalität konzentrieren und nicht darauf, die Art und Weise, wie der Benutzer zwischen den Bildschirmen navigiert, neu zu erfinden. Die erfundene Navigation ist ein Lernaufwand, der dem Benutzer in den Schoß geworfen wird und verwirrte Benutzer deinstalliert.

Zu einem guten Einsatz von Werkzeugen gehört hier die Nutzung der vorgefertigten Komponentensätze, die Figma für diese Designsysteme anbietet. Anstatt jedes Navigationselement von Grund auf neu zu entwerfen, beginnt das Team mit getesteten Blöcken und konzentriert sich auf das, was das Produkt auszeichnet. Für diejenigen mit wenigen Händen ist dies ein Produktivitätsmultiplikator.

Die Reflexion, die Teams trennt

Kein Tool kann einen guten Ablauf für Sie gestalten. Dadurch wird der Fluss nur schneller sichtbar, wenn die Reparatur noch kostengünstig ist. Der Unterschied zu einem erfolgreichen kleinen Team besteht nicht darin, dass es das teuerste Tool hat, sondern in der Gewohnheit, über den Weg des Benutzers nachzudenken, bevor man es erstellt.

Für ein Team mit wenigen Händen ist diese Angewohnheit ein echter Wettbewerbsvorteil. Während Ihr Konkurrent die Produktionsabläufe neu gestaltet, haben Sie Ihre bereits auf dem Papier validiert.

Wenn Sie ein kleines Team leiten und jetzt den Navigationsfluss Ihrer App entwerfen, lohnt es sich, darüber zu sprechen, wie Sie diesen Prozess strukturieren können, ohne das Team aufzublähen. Es gibt weitere Artikel auf dem Blog über Prototyping, mobile UX und Produktvalidierung, die sich direkt mit diesem Thema befassen.

Lesen Sie auch