Fallstudie: Gestaltung eines komplexen pharmazeutischen Testablaufs in einer Woche, ohne ausgearbeiteten Prototypen
Wie wir in nur einer Woche einen komplexen pharmazeutischen Testprozess ohne finalen Prototypen entwarfen? In einem stark manuellen, Excel-basierten Laborautomatisierungsprojekt mussten wir die Geschäftslogik schnell erfassen, sie mit dem Kunden abstimmen und einen präsentationsfähigen Prozess gestalten. In diesem Beitrag zeige ich, wie wir innerhalb einer Woche von null zur ersten funktionierenden Demo gekommen sind.
Für ein pharmazeutisches Testlabor sollten wir eine Automatisierungslösung entwerfen. Das Labor analysiert Wirkstoffproben und erstaunlicherweise liefen viele ihrer Prozesse noch vollständig manuell oder in Excel ab. Als Startup holten sie uns ins Boot, um Teile ihrer Geschäftsabläufe zu automatisieren.
Der erste Schritt bestand darin, zu verstehen, wie ihr Prozess tatsächlich funktionierte, und anschließend eine Integration zu entwerfen, die Folgendes verbindet:
→ unsere Software (die Automatisierungsebene)
→ ihre internen Laborsysteme
→ und ihre Kunden (externe Unternehmen, die Proben zur Analyse einsenden)
Zu Beginn des Projekts hatten wir nur sehr wenige Informationen – lediglich ihre Website und ein paar E-Mails, in denen sie ihre Vorstellung des Prozesses grob beschrieben. Das ist nicht viel, insbesondere in einem so komplexen und streng regulierten Bereich wie der Pharmaindustrie.
Wir hatten ein paar Screenshots einer früheren Lösung mit ähnlicher Funktionalität, aber schnell wurde klar: Diese passen nicht. Die Anforderungen und Prozesse unterscheiden sich je nach Kunde erheblich. Unsere bestehenden Lösungen waren nicht kompatibel – wir mussten also alles von Grund auf neu gestalten.
Und die Zeit war knapp: Der Start der Integration war in etwa sechs Wochen geplant, und die erste Demo mit dem Kunden stand genau eine Woche später an.
Also musste ich die Prozessarchitektur in kürzester Zeit entwerfen.
Ich habe in FigJam ein High-Level-Prozessdiagramm erstellt:

→ zur Darstellung des vollständigen Ablaufs
→ zur Abbildung der Beziehungen zwischen den drei Nutzerrollen
→ zur Definition, welche Rolle in welchem Schritt welche Informationen sieht
Zuerst habe ich das Diagramm intern mit unserem Team besprochen. Wir teilten, was wir bereits wussten, identifizierten fehlende Szenarien und überlegten gemeinsam, wie sich das Ganze technisch mit den verfügbaren Ressourcen umsetzen ließe.
Aufgrund der knappen Zeit schickte ich dem Kunden gezielte Fragen per E-Mail, um offene Punkte zu klären. Sie antworteten so gut sie konnten, und basierend auf diesen Rückmeldungen aktualisierte ich das Diagramm und das Konzept, sodass wir beim Demo-Termin bereits etwas Greifbares diskutieren konnten.
Zusätzlich erstellte ich für einen Teil des Prozesses erste Bildschirmdesigns. Dafür verwendete ich unser bestehendes Designsystem (das ich bereits vor Monaten entwickelt hatte) und baute auf bestehenden Komponenten auf.

Innerhalb einer Woche konnte ich:

→ das Nutzerproblem verstehen
→ den tatsächlichen Prozess kartieren und validieren
→ und mit dem Kunden erste Tests durchführen
Diese enge Zusammenarbeit ermöglichte es uns schließlich, den Projektschwerpunkt klar zu definieren. Wir konnten erkennen, welche Bereiche für den Start kritisch sind und was auf spätere Entwicklungsphasen verschoben werden kann.

Einige zentrale Learnings aus diesem Projekt:

→ Es ist manchmal schwer, dem Kunden Fragen zu stellen, wenn die eigene Lösung noch nicht „perfekt“ ist. Aber es ist viel besser, ihn ehrlich in den Prozess einzubeziehen. Vor dem Demo sagte ich ganz offen: Wir validieren gerade den Ablauf – das hier ist kein fertiges Produkt.
→ Frühe Validierung spart enorm viel Zeit und Energie. Sie verhindert, dass Funktionen entwickelt werden, die entweder nicht funktionieren oder keinen echten Bedarf abdecken.
→ Kunden schätzen Transparenz. Sie erklären ihre Abläufe gerne, vor allem wenn sie merken, dass man ihr Geschäft wirklich verstehen will.
→ Prozessdiagramme + gemeinsames Denken helfen, Fehlentwicklungen zu vermeiden. Das Diagramm machte Lücken und offene Fragen sofort sichtbar – für beide Seiten.
→ Als Designer oder Entwickler merkt man oft, dass die Realität anders ist als gedacht. Je früher man das erkennt, desto besser.
→ Verlasse dich nie nur auf eigene Annahmen. Auch erfahrene Teams übersehen schnell wichtige Details, wenn sie nicht bewusst überprüft werden.
→ Die besten Lösungen entstehen gemeinsam: das Geschäftsverständnis des Kunden plus technisches und UX-Know-how im Team führen zu echtem Mehrwert.
→ Die Prozessvisualisierung hilft auch bei der Priorisierung: Was wird automatisiert, was bleibt manuell, was wäre nur ein „Nice-to-have“.
→ Frühe Validierung mit dem Kunden – selbst mit groben Skizzen – ist entscheidend. Es braucht kein glänzendes Prototyping. Einige Teile existierten bei uns nur als Post-its (z. B. Dropdown-Inhalte), andere folgten bereits dem UI aus dem Designsystem – beides hat wunderbar funktioniert.
Gerade bei engen Deadlines ist es wichtiger, Einigkeit über den Prozess und die Prioritäten zu haben, als eine perfekte Optik zu liefern.
Das ist nicht immer leicht für den inneren Perfektionisten, aber: Das hier ist kein Pitch. Es ist Co-Creation.
Text author: Viktoria Biki
Image: ChatGPT mockup, flow design by Ways Team
Made on
Tilda