Softwarefunktionen
App-Design-Software ist hilfreich, wenn eine Idee für einen Bildschirm mehr als eine visuelle Skizze braucht. Entscheiden Sie zunächst, ob Sie eine Aufgabe abbilden, wiederverwendbare Oberflächenmuster festlegen oder Entscheidungen für ein Produktteam vorbereiten müssen. Wählen Sie dann einen browserbasierten Arbeitsablauf, mit dem Sie Ihre Arbeit überprüfen können.
Der Unterschied liegt im Umfang: Erkunden Sie eine Richtung oder treffen Sie Entscheidungen zur Benutzeroberfläche, die über mehrere Bildschirme hinweg Bestand haben müssen? Der folgende Vergleich hilft Ihnen bei der Wahl.
Ein softwareorientierter App-Design-Prozess ist dann sinnvoll, wenn er Ihnen hilft, zusammenhängende Entscheidungen zu treffen, statt lediglich einen ausgefeilteren Bildschirm zu zeichnen.
Notieren Sie das Ziel der Nutzer und verfolgen Sie dann die Bildschirme vom Einstieg bis zum Abschluss. Ein Willkommensbildschirm kann für sich genommen überzeugend wirken. Die App-Design-Aufgabe wird aber erst deutlich, wenn auch der nächste Schritt, ein Fehlerfall und ein Rückweg sinnvoll gestaltet sein müssen.
Halten Sie Navigation, Beschriftungen, Abstände und Rückmeldungen überall dort einheitlich fest, wo sie wiederkehren. So wird aus einer Sammlung ansprechender Ansichten eine konsistente Spezifikation der Benutzeroberfläche, die Teammitglieder prüfen können.
Prüfen Sie eine realistische Aufgabe anhand jedes Bildschirms: Kann jemand die wichtigste Aktion finden, erkennen, was sich geändert hat, und einen Fehler beheben? Halten Sie offene Fragen fest, statt einen visuellen Entwurf als getestetes Produkt zu präsentieren.
Nutzen Sie diese Tabelle als erste Checkliste. Sie vergleicht zwei Herangehensweisen an die Arbeit, keine verifizierten Funktionslisten eines bestimmten Produkts.
| Allgemeiner browserbasierter Einstieg | Softwareorientierter App-Design-Prozess | |
|---|---|---|
| Erste Eingabe | Eine grobe Bildschirmidee oder visuelle Referenz | Ein Benutzerziel und die Aufgabe, die es unterstützen muss |
| Ursprünglicher Umfang | Ein Bildschirm, um eine Richtung zu erkunden | Eine kurze Abfolge, einschließlich dessen, was als Nächstes passiert |
| Navigation | Durch die Komposition nahegelegt | Benannt und anhand des Wegs des Benutzers überprüft |
| Wiederkehrende Elemente | Berücksichtigt, während sich der Entwurf entwickelt | Dokumentiert, damit Bildschirme konsistent bleiben |
| Zustände | Beginnen oft mit der Standardansicht | Beziehen Fragen zu leeren Zuständen, Fehlern und dem Abschluss ein |
| Frage zur Überprüfung | Vermittelt die Richtung die Idee? | Kann jemand die vorgesehene Aufgabe abschließen? |
| Nächster Schritt | Wähle eine vielversprechende Richtung zur Weiterentwicklung aus | Identifiziere, was getestet werden muss oder weitere Implementierungsdetails erfordert |
Ein browserorientierter Designprozess kann Entscheidungen strukturieren, aber ein Bildschirm-Entwurf ist kein Usability-Test, keine funktionierende Anwendung und keine Garantie dafür, dass ein bestimmtes Tool jede von dir benötigte Funktionalität bietet.
Du musst die erste mobile Aufgabe zeigen, bevor du über die Implementierung sprichst.
Eine Vorlage kann Ihnen helfen, die Bildschirmstruktur zu prüfen. Ersetzen Sie die Beispielinhalte aber durch Ihr tatsächliches Nutzerziel und prüfen Sie den gesamten Ablauf.
Sie haben eine visuelle Richtung, aber noch keine abgestimmte Navigation oder Fehlerbehandlung.
Erfassen Sie die fehlenden Zustände, bevor Sie Details verfeinern. Ein Tool-Workflow kann Ihnen beim Ausprobieren helfen, aber Produktregeln nicht eigenständig festlegen.
Das Team muss zwischen einem visuellen Entwurf und einer Implementierungsspezifikation unterscheiden.
Prüfen Sie Abläufe, Beschriftungen und offene Fragen zum Verhalten gemeinsam und halten Sie technische Einschränkungen separat fest.
Sie feilen an Komponenten, obwohl die übergeordnete Aufgabe noch nicht geklärt ist.
Trennen Sie die Gestaltung der Benutzeroberfläche von der Navigation und Aufgabenlogik der App, damit das eine nicht mit dem anderen verwechselt wird.
Öffnen Sie den Einstiegspunkt im Browser mit einem Nutzerziel vor Augen. Skizzieren Sie den ersten Bildschirm, den nächsten Schritt und die Fragen, die ein Teammitglied beantwortet haben müsste, bevor es den Entwurf als Plan betrachtet. Prüfen Sie die verfügbaren Produktfunktionen am Zielort, statt einen Desktop-Download oder eine bestimmte Exportoption vorauszusetzen.
Achten Sie darauf, dass Sie mehr als einen Bildschirm betrachten, wiederkehrende Entscheidungen zur Benutzeroberfläche konsistent halten und prüfen können, was geschieht, wenn eine Aufgabe gelingt oder fehlschlägt. Prüfen Sie konkrete Funktionen für Zusammenarbeit, Prototyping oder Export auf der Website des jeweiligen Tools, bevor Sie sich darauf verlassen.
Nicht unbedingt. Ein browserbasierter Einstieg kann Ihnen helfen, Bildschirme und Abläufe zu planen, ohne eine Desktop-Anwendung vorauszusetzen. Prüfen Sie die aktuellen Anforderungen der Zielseite, um den tatsächlichen Arbeitsablauf zu erfahren.
Ein Mockup zeigt einen Bildschirm zu einem bestimmten Zeitpunkt. Ein softwaregestützter App-Design-Prozess berücksichtigt auch, wie jemand zu diesem Bildschirm gelangt, welche Aktion darauf folgt und welche Muster oder Zustände konsistent bleiben müssen.
Ein Entwurf bietet etwas Konkretes zur Überprüfung, beweist aber nicht, dass Menschen eine Aufgabe erledigen können. Bitten Sie jemanden, der das Design nicht kennt, ein realistisches Szenario durchzuspielen, und überarbeiten Sie anschließend die unklaren Schritte.
Beschreiben Sie in einem Satz, was der Nutzer tun möchte, und skizzieren Sie seine erste Aktion. Fügen Sie den nächsten Bildschirm erst hinzu, wenn Sie erklären können, warum er nötig ist. So bleibt der anfängliche Umfang überschaubar.