Wie strukturiere ich die Inhalte und wie gestalte ich die Interaktionen?
Aus der Reihe: UX Design in 5 Ebenen
Mit Design Thinking kann man nutzerzentriert Nutzerbedürfnisse und Produktanforderungen analysieren und iterativ verbessern. Mithilfe mehrerer Abteilungen können viele Nutzungskontexte einbezogen werden und der gemeinsame Wissenspool kann langfristig hilfreich sein. Mithilfe der 5 Elemente des UX Designs kann man sich den Maximen des Design Thinkings annähern. Dabei handelt es sich um ein konzeptionelles Framework, das den Designprozess in fünf Elemente aufteilt. Man analysiert das Problem in abstrakter Weise, um dann immer konkreter in den Fragestellungen und Lösungsideen zu werden. Die Erarbeitung der Ebenen sollte nacheinander ablaufen und Entscheidungen können dafür sorgen, dass die vorige Ebene erneut angegangen und ergänzt oder korrigiert wird. Das kann zum Beispiel beim Wechsel einer Priorität passieren.
In den vorigen Blogartikeln wurden bereits die Strategie und die Scope Ebene vorgestellt. In der ersten werden die Bedürfnisse der Nutzer:innen erforscht und die unternehmenseigenen Ziele. In der Scope Ebene werden daraus die Anforderungen analysiert, sodass Features und Inhalt des Produkts entworfen und priorisiert werden. Die Structure Ebene behandelt das Interaction Design und die Information Architecture. Dabei werden folgende Fragen gestellt:
Wie interagieren Nutzer:innen mit dem System? Wie reagiert das System (auch auf Fehlerfälle)?
Wie sollte der Inhalt strukturiert werden?
Interaction Design
Um eine nutzerfreundliche Software zu implementieren, sollte man im Designprozess hinterfragen, wie Nutzer:innen mit dem Produkt umgehen und wie das Produkt entsprechend reagieren sollte. So kann sichergestellt werden, dass ein Task ohne Missverständnisse und Unterbrechungen abgearbeitet werden kann. Hierbei kann mit konzeptionellen Modellen gearbeitet werden. In dem Beispiel unserer Blogreihe behandeln wir das Design eines Personalmanagementtools. Hier könnte man also mit konzeptionellen Modellen arbeiten, die Metaphern aus der realen Welt nutzen: Für Arbeitsunfähigkeitsbescheinigungen könnte statt "Dateien hochladen" das Wording "AUs einreichen" gewählt werden. Entscheidet man sich einmal für eine Metapher, sollte diese konsistent beibehalten werden. Wenn es durch (Konkurrenz-)Produkte bereits Konventionen für Metaphern zu einem Anwendungsfall gibt, dann können diese übernommen werden, um Nutzer:innen keine Umgewöhnung zuzumuten. Eine alternative Metapher kann aber Sinn machen, wenn es eine geeignetere für den konkreten Anwendungsfall gibt.
Neben den voraussichtlichen Interaktionen der Nutzer:innen, um ein Ziel zu erreichen, sollten auch potentielle Missverständnisse analysiert werden. Zwar können Features detailliert und mit viel Nutzerforschung konzipiert werden, aber es kann immer vorkommen, dass Nutzer:innen Fehler im System erzeugen. Fehlerquellen sollten erkannt und vorgebeugt oder korrigiert werden können. Weiterhin ist es wichtig, eine transparente Fehlermeldung an die Nutzer:innen zurückzugeben.
Fehlermeldungen sollten für Nutzer:innen verständlich und lösungsorientiert sein. Idealerweise wird Nutzer:innen mitgeteilt, was fehlerhaft ist und wie der Fehler zu korrigieren ist. Dabei gibt man so viele Informationen wie nötig und so knapp wie möglich weiter. Beispiel: "Das Enddatum kann nicht vor dem Startdatum liegen."
Information Architecture
Der Inhalt sollte so strukturiert sein, dass Nutzer:innen schnell und einfach finden, wonach sie suchen. Die Struktur kann durch Kategorisierung erstellt werden. Abwärtsgerichtet kann sie erstellt werden, indem man direkt mit den Ergebnissen der Strategie Ebene arbeitet: Aus den allgemeinen Nutzer- und Unternehmenszielen werden Kategorien und daraus wiederum Unterkategorien erstellt. Diese dienen als leerer Rahmen, in die die Ergebnisse der Scope Ebene, demnach die Funktionen und Inhalte, einsortiert werden. Ein Nachteil kann sein, dass Erkenntnisse aus der Scope Ebene nicht berücksichtigt werden.
Die Struktur kann auch aufwärtsgerichtet umgesetzt werden: Dabei werden die Funktionen und Inhalte der Scope Ebene gruppiert und kategorisiert. Die ermittelten Kategorien werden dann wiederum in Überkategorien verbunden. Ein Nachteil hierbei kann sein, dass die Kategorien so auf die aktuellen Ergebnisse zugeschnitten sind, dass sie nicht flexibel genug sind, um auch nach Änderungen durch das skalierte Produkt nutzbar zu sein.
Es gibt nicht nur hierarchische Strukturen. Man kann Informationsknoten auch in mehrere Richtungen verknüpfen. Das kann sinnvoll sein, wenn es viele verschiedene Anwendungsfälle gibt, in denen Nutzer:innen entsprechend andere Wege gehen, um in effizienter Weise eine Aufgabe zu erledigen. In den meisten Fällen ist eine hierarchische Navigation aber der sinnvollste Weg, daher wird hier nicht weiter auf die anderen Strukturen eingegangen.
Wie im Interaction Design bereits genannt, ist auch in der Information Architecture ein konsistentes Vokabular zu beachten. Das vereinfacht die fließende Nutzung ohne Missverständnisse oder kurze Unterbrechung, da nicht überlegt werden muss, ob mit einem genutzten Synonym nicht doch etwas anderes gemeint sein könnte. Um sich für das richtige Vokabular zu entscheiden, sollten die Notizen und Ergebnisse der Nutzerforschung einbezogen werden: Idealerweise werden die Formulierungen im Produkt benutzt, die bereits von der Zielgruppe benutzt werden.
Welche Methoden gibt es?
Ressourcenintensiv
Langfristig kann es lohnenswert sein, einen Vollzeit Information Architect einzustellen, der das wachsende Produkt mit dem Fokus der Informationsarchitektur begleitet und die Grundstruktur regelmäßig aktualisiert. Bei Produkten, die häufig neue Inhalte und neue Funktionen erhalten, kann dies sinnvoll sein. Skalierte Produkte, dessen Struktur lange nicht aktualisiert wurde, können dann durch einen chaotischen Seitenaufbau negativ bei Nutzer:innen auffallen. So etwas wird verhindert, wenn ein Information Architect involviert ist oder jemand aus dem Entwicklungsteam, dem diese Aufgabe konkret zugewiesen wird und ausreichend Ressourcen für Analysen und Korrekturen gegeben werden.
Ressourcensparend
Mithilfe von Card Sorting können Inhalte gruppiert werden. Dafür werden die Inhalte auf einzelne Karten geschrieben und in passende Gruppen sortiert. Mithilfe der physischen Karten erhält man einen guten Überblick und das Ausprobieren der Gruppierungen geht schnell. Setzt man die Methode mit mehren Leuten um, bietet sich bei einer Remote Anwendung auch ein digitales Board an, in dem die Karten entsprechend digital erstellt und verschoben werden.
Das empfohlene Minimum
Card Sorting ist ein beliebtes Mittel, um Struktur in eine inhaltliche Planung zu bringen. Um zu verhindern, dass zu subjektiv gruppiert wird, macht es auch hier Sinn, interdisziplinär zu arbeiten. Mit den verschiedenen Kontexten im Hinterkopf kann dann noch in der Designphase diskutiert werden, bevor Fehler in der Grundstruktur erst beim Testing auffallen, wor die Korrektur bereits deutlich teurer wäre.
Ein Beispiel:
Ein Personalmanagementtool soll konzipiert und implementiert werden. Das eigene Software Unternehmen ist mit dem bisher genutzten Produkt nicht ausreichend zufrieden, sodass ein eigenes entwickelt werden soll. Da es sich um ein intern zu nutzendes Produkt handelt, handelt es sich bei den Nutzer:innnen um Kolleg:innen und die Stakeholder sind die Geschäftsführung, die Personalabteilung und Projektleitungen. Das genutzte Vokabular orientiert sich an bestehenden Konventionen.
Welche Methode wird zur Strukturierung genutzt?
Ein UX-Experte findet sich mit zwei weiteren Kolleg:innen aus der Personalabteilung und Projektteams zusammen, um mithilfe von Card Sorting die inhaltliche Grundstruktur für die Software zu schaffen. Das Meeting wird auf zwei Stunden angesetzt. In der ersten halben Stunde werden die Ergebnisse der ersten beiden Ebenen (Strategie mit den Nutzer- und Unternehmenszielen und Scope mit den Features und Inhalten) bereitgestellt und die Teilnehmenden notieren unabhängig voneinander Überbegriffe für die Struktur. Erste Versuche einer hierarchischen Anordnung werden dabei ebenfalls durchgeführt. Darauf folgt eine Stunde Austausch mit Diskussion. Ziel dabei ist es, sich auf Kategorien zu einigen. Die finalen Kategorien und die Hierarchische Ordnung werden dann in der letzten halben Stunde erarbeitet.
Was sind die Kategorien?
Da es sich um ein MVP handelt, ist noch nicht viel Inhalt einzuordnen. Die entstandenen Kategorien sind Mitarbeiter, Arbeitsstunden, Gehalt, Bescheinigungen und Verträge.
Was ist die Hierarchie?
Mitarbeiter dient als oberster Knotenpunkt. Davon ab gehen Arbeitsstunden und Gehalt. Bescheinigungen und Verträge sind Details, die von den letzten beiden Knotenpunkten abgehen.
Bis zu dieser Stelle hat man also Nutzerforschung betrieben, hat darauf basierend Unternehmenziele um Nutzerziele ergänzt, passende Features und Inhalte konzipiert und eine Struktur in die inhaltlichen Anforderungen gebracht. Da die theoretischen Voraussetzungen nun gegeben sind, beginnen wir in der nächsten Ebene Skeleton endlich mit der Visualisierung.
