Projektmanagement & UI: Warum die Oberfläche über die Akzeptanz entscheidet

Das beste Projektmanagement-Tool nützt nichts, wenn es niemand gerne pflegt. Ein Blick in ein Board verrät das schnell: Wenn die meisten Stories nur leere Hüllen ohne Beschreibung und Akzeptanzkriterien sind, liegt das selten an fehlender Disziplin – sondern oft daran, dass das Werkzeug nicht zum Alltag der Menschen passt.

Tools mit der UX-Brille vergleichen

Bei der Suche nach einem neuen Projektmanagement-Tool habe ich mehrere Kandidaten gegenübergestellt – nicht nur nach Funktionsliste, sondern auch nach Bedienbarkeit. Ein paar Beobachtungen:

• Asana ist dank seines schlankeren Funktionsumfangs sehr übersichtlich in der Navigation. Für Entwickler:innen dürfte es im Alltag aber schwierig werden – allein deckt es nicht alle Anforderungen ab.
• Jira bietet deutlich mehr Funktionen, die Navigation ist dafür weniger übersichtlich. Mehr Möglichkeiten bedeuten eben auch mehr Komplexität.
• Azure DevOps punktet mit der Nähe zur Entwicklung und war zum Zeitpunkt des Vergleichs preislich attraktiv: Die ersten fünf Nutzer:innen waren inklusive, danach kostete jede weitere Person 5,70 € pro Monat.

Die Ergebnisse habe ich in einem Pitch für die Geschäftsführung zusammengefasst. Mein wichtigstes Learning: Das eine perfekte Tool gibt es selten. Entscheidend ist, welche Rollen damit arbeiten – und was sie wirklich brauchen.

Meine Bewertungskriterien

1. Navigation und Übersicht: Finde ich mich nach einer Woche ohne Hilfe zurecht?
2. Rollen-Fit: Passt das Tool für die Entwicklung und für den Fachbereich?
3. Integration: Lässt es sich in die bestehende Umgebung – etwa Microsoft Teams und SharePoint – einbinden?
4. Migration: Können vorhandene Daten, zum Beispiel aus DevOps, übernommen werden?
5. Kosten: Lizenzmodell, Anzahl der Nutzer:innen und Zusatzfunktionen.

Integration schlägt Insellösung

Ein Tool, das tief in die vorhandene Infrastruktur integriert ist, wird eher genutzt als eine weitere Insel mit eigenem Login. Als Microsoft ankündigte, To Do, Planner und Project in einer gemeinsamen Lösung für das Arbeitsmanagement zusammenzuführen, war das für mich deshalb ein klarer Grund, auch diese Option in die Bewertung aufzunehmen.

UI-Details, die im Alltag den Unterschied machen

Wie stark die Oberfläche die Nutzung beeinflusst, habe ich auch beim UX-Design einer Projektzeiterfassung erlebt. Im Austausch mit den Nutzer:innen zeigte sich, dass der eigene Menüpunkt für die Live-Erfassung kaum gebraucht wurde: Alle arbeiteten ohnehin in der Kalenderansicht – und wollten genau dort auch live erfassen.

Die logische Konsequenz: Funktionen dorthin bringen, wo die Menschen schon sind, und die Navigation auf das Wesentliche reduzieren – zum Beispiel, indem Kalender- und Listenansicht oben integriert werden und in der Navigation nur noch zwei Punkte übrig bleiben. Solche Erkenntnisse entstehen nicht am Schreibtisch, sondern im Gespräch. Deshalb frage ich lieber einmal zu viel nach: „Sehe ich das richtig, dass ihr eigentlich nur hier arbeitet?“

Planung, die hält

• Epics sprintgerecht schneiden: Lässt sich ein Epic nicht mehreren zukünftigen Sprints zuordnen, hilft nur eins – es sauber in kleinere Einheiten schneiden, die jeweils in einen Sprint passen.
• Erst messen, dann planen: Beim Aufbau eines Design-Systems haben wir für die ersten Komponenten die tatsächlich benötigte Zeit notiert. Daraus entsteht eine realistische Timeline.
• Ehrlich kommunizieren: Eine grobe Reihenfolge für die nächsten Sprints ist noch keine echte Sprintplanung – und darf auch so benannt werden.
• Kapazitäten sichtbar machen: Ein guter Projekteinsatzplan zeigt alle Themen je Projekt auf einer Zeitachse, wer wie in welchem Projekt arbeitet und wie die Kapazitäten pro Person verteilt sind.