Software entwirft man am besten unter Beteiligung der Benutzer:innen. Daher möchte ich mit Hilfe von Domain-Driven Design ein konzeptionelles Klassenmodell entwerfen und auch gleich zur Grundlage der Informationsarchitektur der Anwendung (Ein SaaS für Trainer) machen. Das sollte für die User ein Gefühl des Wieder-Erkennens ihrer Domänensprache ergeben, was dann noch durch Usability Tests zu beweisen wäre.
Ausgangspunkt: Interview mit Domänenexperten
In der ersten Folge meines Selbstversuches hatte ich ein (zugegeben erfundenes) Interview mit einem Trainer protokolliert. Einige der Aussagen darin konnte ich jetzt zu einem ersten Domänenmodell für die Aufgabe "Design von professionellen Trainings" verdichten:
- Der Trainer sammelt viel RawMaterial für seine Trainings
- RawMaterial kann eine Note (also Text) oder ein Upload (z.B. ein Bild, Video, oder ein Audio) sein
- In den Notes markiert er Elements mittels Highlights
- Die Elements (ursprünglich: Snippets) fasst er in Categories (ursprünglich: Buckets) zusammen
PO und Entwickler dürfen auch zum Modell beitragen
Ich selbst (als PO und Entwickler) habe dann noch Team und Project hinzugefügt, damit mehrere Trainer:innen als Team zusammenarbeiten können und jede:r Trainer:in auch mehrere Trainings als ein Project verwalten kann. Letzteres könnte wichtig werden, wenn Trainings nicht einzelne Ereignisse sind, sondern sich über eine längere Zeit erstrecken.
Auch habe ich die Möglichkeit hinzugefügt, dass Bilder, Videos und Audios (also Uploads) in Notes eingebunden dargestellt werden können (daher die Dependency von Note zu Upload).
Die Wörter Snippet und Bucket fand ich etwas zu sehr "Slang", deshalb habe ich sie in Element und Category umbenannt. Mal sehen, ob sich diese Eigenmächtigkeit des Entwicklers eines Tages rächen wird (z.B. in Form von User Feedback). Sie sehen, ich baue Fehler ein, um den Selbstversuch halbwegs realistisch zu gestalten. Natürlich hätte ich vor dem Umbenennen zuerst mit Domänenexpert:inn:en sprechen müssen.
Was der Trainer am Schluss des Interviews erwähnte, nämlich die Umwandlung der Notes und Highlights in Modules und Units, die ein Training bilden, habe ich in diesem Modell noch weggelassen. Ich möchte zuerst einmal dies hier umsetzen und dann mit echten Trainer:innen darüber sprechen, bevor ich weitermache.
Erste Ideen für das Domänenmodell
Daraus ergibt sich jetzt folgendes Klassendiagramm, das sich mit PlantUML am einfachsten erzeugen ließ:
Aus diesem Klassenmodell kann ich jetzt sowohl meine Java- und TypeScript-Typen machen, als auch die Namen der Menüs und Funktionen in der Oberfläche des SaaS. User Interfaces für die folgenden zwei Funktionen werden wahrscheinlich sehr anspruchsvoll werden, um gute Benutzbarkeit zu erreichen:
- das Editieren von Notes und Einbinden von Uploads
- das Einordnen von Notes in NoteGroups und von Elements in Categories
Für die erste Funktion möchte ich einen Online-Editor einsetzen, für die zweite eine Art Taskboard mit Karten, die der User in Spalten schiebt.
Informationsarchitektur
Die Struktur und die Navigationswege auf der Oberfläche des SaaS möchte ich so gestalten, dass die Trainer:innen eine Art "ist-enthalten-in-Gefühl" haben, wenn sie entlang einer Aggregation oder Komposition im obigen Diagramm navigieren. Beispiele:
- Teams enthalten Members und Projects
- Projects enthalten Trainings
- Trainings enthalten RawMaterial
- NoteGroups enthalten Notes
- Categories enthalten Elements
Für noch nicht gefüllte Collections (z.B. noch keine Projects im Team, oder noch keine Notes im Training) möchte ich im UI empty states einsetzen, die dem User sagen, dass momentan noch nichts da ist (und wie er/sie leicht etwas hinzufügen kann).
Für leichteres Zurück-Navigieren aus den Collections heraus möchte ich Breadcrumbs einsetzen.
Insgesamt sollte sich durch klare Informationsarchitektur und sprechende empty states ein angenehmes Bediengefühl einstellen. Ich bin gespannt.
Titelfoto
Vielen Dank an Bonneval Sebastien für das Foto von der UX-Arbeit:
Unsplash
Kommentare