Labregister ist ein Lab Inventory Management System (LIMS), das entwickelt wurde, um Wissenschaftler:innen dabei zu unterstützen, in Echtzeit den Überblick über im Labor verfügbare Geräte, Reagenzien, Proben, Chemikalien usw. zu behalten. Darüber hinaus ermöglicht es die Visualisierung von DNA-Sequenzen, Kauf- und Ablaufdaten sowie weiterer relevanter Metadaten, mit der zusätzlichen Möglichkeit, diese über Barcode-Scanner direkt im System zu registrieren.

Zu den weiteren Funktionen zählen eine erweiterte Suchfunktion mit logischen Operatoren sowie die Registrierung von Parent- und Child-Komponenten, die im Labor im Rahmen der Eigenproduktion hergestellt wurden.

Firma	Labforward GmbH
Rollen	Senior Produktdesignerin
Umfang	UX, UI, Designsystem, Informationsarchitektur
Tools	UXPin, Illustrator
Jahre	2020-2022
Briefing	Neugestaltung der Inventaranwendung, die zu einem eigenständigen Produkt weiterentwickelt wurde, um es Wissenschaftlern zu ermöglichen, jedes gelagerte Element in ihren eigenen sowie in anderen Laboren anhand präziser Standortangaben zu finden, sowie zur Entwicklung eines Managementsystems zur Echtzeit-Aktualisierung der Laborbestände.

Die Herausforderung

Von der Erweiterung zur eigenständigen Anwendung

Labregister wurde ursprünglich im Jahr 2016 als Erweiterung von Labfolder entwickelt, dem unternehmenseigenen ELN. Damals trug es den Namen Material Datenbank (MDB). Die Designreise begann, als im Rahmen einer Geschäftsentscheidung beschlossen wurde, LabregisterMDB zu einem eigenständigen Produkt weiterzuentwickeln – einem vollwertigen LIMS mit dem Zielnamen Labregister.

So sah MDB im Jahr 2016 aus. Zu diesem Zeitpunkt gab es noch kein bestehendes Designsystem für potenzielle Erweiterungen von Labfolder – lediglich ein Farbkonzept war vorhanden.

2) Meine Rollen im Projekt

Produktdesignerin

• Auf der UX-Design-Seite bestand ein großer Teil der Arbeit darin, verschiedene Stakeholder zu interviewen: Zu den berücksichtigten Personas gehörten unterschiedliche Arten von Wissenschaftlern, wie Molekularbiologn, Neurobiologn und analytische Chemikern, sowie natürlich das Top-Management.

• Auf der UI-Design- und Frontend-Seite sollte das Frontend mit Aurelia, einem Open-Source-Framework, entwickelt werden. Zudem musste eine Frontend-Bibliothek implementiert werden, weshalb wir uns entschieden, eine selbstgehostete Instanz auf dem Entwicklungsserver einzurichten, um Klarheit über die entwickelten Komponenten zu schaffen und deren Wiederverwendbarkeit im Team sicherzustellen.

3) UX-Neudefinition

Schmerzpunkte

• Datenverwaltung ohne Skalierbarkeit: MDB war ursprünglich als Integration in das ELN gedacht. Zwar war es möglich, Inventarobjekte im ELN zu referenzieren, jedoch standen die Daten innerhalb von MDB kaum in Beziehung zueinander – abgesehen von Kategorien und den darin enthaltenen Elementen. Automatisierung bedeutete in diesem Kontext, dass Elemente ohne manuellen Aufwand aktualisiert werden konnten und sich automatisch aktualisierten, wenn sie in ELN-Einträgen als „verwendetes Material“ referenziert wurden.

• Bulk-Aktionen fehlten: Die Bearbeitung der Datenbanken auf Massenebene war nicht möglich. Ziel war es, ein nahezu Excel-ähnliches Niveau zu erreichen. Funktionen wie Archivieren, Löschen oder Exportieren waren schlicht nicht vorhanden.

Maßnahmen: Feature-Design gemeinsam mit Stakeholdern durch Design Sprints

Design Sprints wurden für jede identifizierte fehlende Funktion durchgeführt. Mit einer leichten Anpassung der Methodik und einer regelmäßigen Durchführung zweimal pro Quartal hatte ich jeweils eine Woche Zeit, eine Reihe von Features gemeinsam mit verschiedenen Stakeholdern zu evaluieren.

• Die erste Stakeholder-Gruppe bestand aus Wissenschaftler:innen mit Hintergründen in Biologie, Neurowissenschaften und Chemie, unter anderem. In diesen ersten Sprints erarbeitete ich gemeinsam mit ihnen Wireframes, um ein fundiertes Verständnis der unterschiedlichen Anforderungen zu entwickeln. Die Wireframing-Übungen wurden zunächst auf Papier durchgeführt und anschließend zur gemeinsamen Analyse in Miro übertragen.

Nachdem alle Informationen aus der ersten Stakeholder-Gruppe zusammengetragen und ausgewertet worden waren, kam die nächste Stakeholder-Gruppe ins Spiel.

• Die zweite Stakeholder-Gruppe bestand aus Softwareentwicklern. Ich erstellte schnelle User Flows und Entscheidungsdiagramme, um die Umsetzbarkeit gemeinsam mit den Entwickler:innen zu bewerten. Hier ist ein Ausschnitt solcher Diagramme zu sehen: