Februar bis Mai 2025
Kommunikations-Tool für ein Projekt-Management-System
Nach drei Jahren Diskussionen und verschobenen Entscheidungen haben der Produkt-Manager Christian und ich in acht Wochen einen der größten Pain-Points im System gelöst. Zum ersten Mal können alle Nutzer im Projekt-Management-System direkt, nachvollziehbar und ohne Umwege miteinander kommunizieren: jobbezogen, dokumentiert und ohne externe Tools.
Methoden & Leistungen
Analyse | Konzept-Entwicklung | User Flows | User-Research | User Interviews | User Journey | Design-Thinking-Workshop | Wireframing | Prototyp-/Klick-Dummy | UX-/UI-Design
Drei Jahre Diskussionen, ohne klare Entscheidung
Christian war kurz zuvor zum Product-Lead ernannt worden. Er wusste, dass das Thema Kommunikation im System seit Jahren offen war, konnte aber nicht nachvollziehen, wo genau das Problem lag.
Die Stelle zu übernehmen war ohnehin schon eine große Aufgabe. Dazu kam der Druck, diese Anforderung endlich umzusetzen. Aber ohne neue Daten konnte er genauso wenig eine Entscheidung treffen wie die Produkt-Verantwortlichen vor ihm.
Das Sales-Team fragte schon lange nach einer vernünftigen Funktion, mit der sich die Nutzer im System austauschen können. Drei Jahre lang wurde diskutiert, wie diese Lösung aussehen könnte.
Sollte es ein Teams-ähnlicher Chat sein oder doch ein ganzes Communication-Center? Reicht es, die aktuelle E-Mail-Funktion zu optimieren, oder sollte ein externes Tool eingebunden werden?
Das eigentliche Problem:
Es gab zu viele Annahmen und offene Fragen.
Es lagen keine echten Daten darüber vor, wie die Nutzer im Arbeitsalltag im System kommunizieren.
Jeder hatte seine eigene Idee, aber niemand konnte reale Use-Cases vorweisen.
Es fehlten die Daten, um zu entscheiden, welche Anforderungen und Funktionen die Nutzer wirklich brauchen.
Entwicklungs-Prozess
1. Analyse
Wir haben die bestehenden Kommunikationswege im System geprüft und drei zentrale Nutzergruppen identifiziert:
Manager-User: Nutzen das System täglich und durchgehend.
Interne Prüfer: Arbeiten mehrmals pro Woche im System.
Externe Nutzer: Nutzen das System gelegentlich, wenn sie eine konkrete Aufgabe erhalten.
Alle drei Gruppen müssen sich regelmäßig abstimmen, Dokumente austauschen und Freigaben klären. Aber die vorhandenen Funktionen waren dafür nicht geeignet.
Nach der Analyse war klar: Viele Informationen fehlten und zahlreiche Annahmen standen ungeprüft im Raum.
Wie läuft der Austausch im Arbeitsalltag wirklich ab?
Welche Tools nutzen die verschiedenen Gruppen?
Was davon passiert innerhalb des Systems und was außerhalb?
Bevor eine neue Funktion definiert werden konnte, mussten wir zuerst verstehen, wie die Kommunikation im realen Arbeitskontext tatsächlich abläuft.
2. User-Interviews
Ich habe 12 Interviews geführt, verteilt auf zwei Unternehmen und drei Nutzergruppen. Ziel war es, zu verstehen, wie Nutzer im Arbeitsalltag tatsächlich kommunizieren und welche Pain-Points dabei entstehen.
Das Ergebnis war deutlich komplexer als erwartet.
Wir gingen davon aus, dass sich zwei oder drei dominante Kommunikationswege herauskristallisieren würden. Stattdessen hatten die Nutzer mehr als 8 unterschiedliche Wege entwickelt, um sich innerhalb und außerhalb des Systems zu verständigen.
Jeden dieser Wege habe ich systematisch analysiert und in einer strukturierten Übersicht festgehalten:
In welchen Situationen wird dieser Weg genutzt?
Welche wiederkehrenden Probleme treten auf?
Welches konkrete Bedürfnis steckt dahinter?
Welche Verbesserungsvorschläge haben die Nutzer geäußert?
Der Kern der Erkenntnisse
Manager-User bearbeiten teilweise bis zu 100 Jobs pro Woche. Den Überblick zu behalten, welche Information und welche E-Mail zu welchem Job gehört, ist ein massiver Pain-Point.
Es gibt keine Möglichkeit, im System jobbezogen zu kommunizieren und diese Kommunikation nachvollziehbar zu dokumentieren.
Informationen sind verteilt auf E-Mails, Teams-Chats, Notizen und PDF-Kommentare und lassen sich kaum strukturiert wiederfinden.
Kurz gesagt: Nutzer brauchen ein einfaches, schnelles Tool, um sich zu einem konkreten Job austauschen zu können. Direkt im Job, nicht außerhalb.
Mit diesem klaren Bild war es anschließend deutlich einfacher, konkrete User Stories und Requirements abzuleiten.
3. Konzept-Entwicklung
In einem Design-Thinking-Workshop haben wir gemeinsam mit dem Produkt-Team mögliche Lösungsansätze erarbeitet. Zuerst alle Ideen sammeln, ohne uns durch technische Einschränkungen begrenzen zu lassen. Dann gemeinsam bewerten, auf Basis der identifizierten User Needs, Pain-Points und der strategischen Ausrichtung des Produkts.
Die Entscheidung fiel auf eine klare, reduzierte Lösung: eine nachvollziehbare, jobbezogene Kommunikation über einen eigenen Comment-Tab.
Die Lösung: Ein Comment-Tab im Job
Mit dem Comment-Tab können Nutzer:
Fragen und Informationen direkt zu einem Job teilen, ohne auf externe Tools ausweichen zu müssen
Kommunikation vollständig im Job dokumentieren, sodass sie auch Monate später noch nachvollziehbar ist
Dokumente und Bilder anhängen, um Kontext herzustellen
Personen taggen und andere Jobs verlinken, um Abläufe zu beschleunigen
Festlegen, welche Nutzergruppen bestimmte Kommentare lesen dürfen
Es brauchte weder ein zusätzliches Communication-Center, noch ein weiteres Chat-System. Die Funktion ist direkt im bestehenden Arbeitskontext verankert und wurde aus realem Nutzerverhalten abgeleitet.
4. Prototyp-Tests und Optimierung
Um sicherzustellen, dass die definierten Anforderungen tatsächlich erfüllt werden, habe ich einen klickbaren Prototyp entwickelt und mit fünf Nutzern aus den relevanten Gruppen getestet.
Dabei ging es um folgende Fragen:
Ist die Logik des Comment-Tabs intuitiv verständlich?
Finden sich die Nutzer ohne Erklärung zurecht?
Deckt die Lösung die wichtigsten Use-Cases im Arbeitsalltag ab?
Die Nutzer haben konkret beschrieben, an welchen Stellen sie unsicher waren und welche Funktionen im Alltag besonders wichtig sind. Auf Basis dieses Feedbacks konnten gezielte Anpassungen vorgenommen werden, bevor die Funktion in die Entwicklung ging.
5. Überarbeitung der Layouts
Nach einer weiteren Überarbeitung und Optimierung der Prototypen und Layouts konnte die Funktion in die Entwicklung gegeben werden.
Die Ergebnisse
Acht Wochen, zwölf Interviews und ein klares Konzept haben mehr bewegt als drei Jahre Diskussion.
Das Produkt-Team hat heute ein gemeinsames Verständnis davon, wie Nutzer tatsächlich kommunizieren und was sie dafür brauchen. Diskussionen basieren nicht mehr auf Meinungen, sondern auf konkreten Use-Cases, dokumentierten Pain-Points und klar definierten Requirements.
Die Interviews und Analysen dienen als feste Entscheidungsgrundlage. Wenn neue Anforderungen oder Einwände auftauchen, kann sich das Team auf reale Nutzerverhalten, konkrete Nutzerzitate und belegte Bedürfnisse beziehen, statt wochenlang zu diskutieren.
Christians Reaktion nach den Interviews und dem fertigen Konzept: „Wow, das ist endlich mal eine wirklich sinnvolle und einfache Funktion. Das ist ein Riesen-Mehrwert für die Nutzer.“