Warum zeigt der Case keine Screens und keine Zahlen?

Weil wir aus diesem Engagement keine Produkt-Screens und keine Messwerte veröffentlichen, die nicht ausdrücklich freigegeben sind. Wir beschreiben Problem, Vorgehen und Ergebnis qualitativ; Details gibt es im Gespräch, soweit wir sie teilen dürfen.

Was bringt Beabstracto aus dieser Arbeit für Hersteller von Enterprise-Software mit?

Erfahrung mit genau den Problemen, die Head of Product und Produktmanagement bei Enterprise-SaaS beschäftigen: dichte Tabellen, wiederkehrende Filterarbeit, Muster, die pro Modul auseinanderlaufen, und ein Design-System, das Konsistenz sichern soll, ohne Weiterentwicklung zu blockieren. Dazu die Praxis, Konzepte in Usability-Tests zu validieren, bevor sie skaliert werden.

Wie arbeitet Beabstracto in einer bestehenden Design-Organisation mit eigenem Design-System?

Innerhalb des Rahmens, den das System vorgibt. Wir lernen zuerst, welche Muster bereits gelten, nehmen an Critiques teil und dokumentieren so, dass andere Teams die Arbeit weiterführen können. Wo das System einen Bedarf nicht abdeckt, begründen wir die Erweiterung, statt eigene Komponenten einzuführen.

Ist das auf Fachsysteme in Banking und Industrie übertragbar?

Ja. Tabellen mit vielen Zeilen, gespeicherte Ansichten, lesbare Zustände und Entscheidungen unter Zeitdruck sind der Alltag in Fondsbuchhaltung, Steuerreporting und Leitsystemen genauso wie im IT-Asset-Management. Die Fachdomäne wechselt, die UX-Fragen bleiben: Wie findet die Person, was sie braucht, und wie erkennt sie, was Aufmerksamkeit verlangt?

Wie lief die Zusammenarbeit remote mit einem Team in den USA?

Vollständig remote, über Zeitzonen hinweg mit Produktmanagement, Engineering, Research und Designer:innen. Das setzt saubere Dokumentation und asynchrone Abstimmung voraus – Fähigkeiten, die wir im DACH-Raum ebenso einsetzen, wenn Fachbereich, IT und externe Berater:innen an verschiedenen Standorten sitzen.

Enterprise SaaS · IT-Asset-Management · 2025–2026

Aus einem Tabellenproblem ein wiederverwendbares Produktmuster machen.

Für Flexera, einen Anbieter von Enterprise-Software für IT-Asset-Management, FinOps und Software Asset Management, hat Thiago Andrade als Senior Product Designer dichte, tabellenlastige Workflows klarer und bedienbarer gemacht. Ausgangspunkt war ein konkretes Navigationsproblem in einer Tabelle. Ergebnis war ein Konzept für gespeicherte Filter und Ansichten, das über diese eine Stelle hinaus im Produkt trägt – validiert in Usability-Tests und abgestimmt mit einer Design-Organisation von mehr als 20 Designer:innen.

Erstgespräch vereinbaren Wie wir vorgegangen sind

Kunde: Flexera
Branche: Enterprise SaaS · IT-Asset-Management (ITAM), FinOps, Software Asset Management
Rolle: Senior Product Designer, eingebunden in die Produkt- und Design-Organisation
Zeitraum: Oktober 2025 – Juli 2026 · remote, USA
Systeme: ITAM-Plattform (Enterprise SaaS) · bestehendes Design-System
Team: Design-Organisation mit 20+ Designer:innen, Produktmanagement, Engineering, Research

Kurz gesagt

Flexera ist ein Anbieter von Enterprise-Software für IT-Asset-Management, FinOps, Software Asset Management und komplexe IT-Betriebsprozesse. Die Nutzer:innen sind technische und operative Fachleute, die aus großen Datentabellen Entscheidungen ableiten, Ansichten speichern und Produktzustände über viele Vorgänge hinweg verstehen müssen. Von Oktober 2025 bis Juli 2026 war Thiago Andrade dort als Senior Product Designer eingebunden. Er hat Workflows für ITAM-Oberflächen entworfen und verfeinert, Tabellennavigation und gespeicherte Filter konzipiert, Usability-Tests und Konzeptvalidierung durchgeführt und die Ergebnisse mit einer Design-Organisation von mehr als 20 Designer:innen abgestimmt. Aus einem lokalen Tabellenproblem wurde so eine Chance für ein wiederverwendbares Produktmuster.

Für Hersteller von Enterprise-Software ist das relevant, weil die typischen Probleme – überladene Tabellen, wiederholte Filterarbeit, Muster, die pro Modul neu erfunden werden – nicht an einer Branche hängen. Beabstracto bringt aus dieser Arbeit die Erfahrung mit, wie man in einer großen Produktorganisation mit bestehendem Design-System Verbesserungen durchsetzt, die lokal helfen und das Gesamtprodukt nicht fragmentieren.

Ausgangslage

Wo stand das Produkt, bevor die Arbeit begann? In einem Umfeld, in dem Datenmenge kein Fehler, sondern der Kern des Produkts ist.

Flexera entwickelt Enterprise-Software für IT-Asset-Management, FinOps und Software Asset Management. Die Produkte helfen Unternehmen, ihre Software- und Cloud-Bestände, Lizenzen und Kosten über große, heterogene IT-Landschaften hinweg zu überblicken und zu steuern. Das ist ein Fachgebiet, in dem Vollständigkeit zählt: Eine Tabelle, die nur einen Teil der Assets zeigt, ist für den Fachbereich wertlos.

Die Nutzer:innen sind technische und operative Fachleute. Sie navigieren durch dichte Daten, treffen Entscheidungen auf Basis komplexer Tabellen, verwalten gespeicherte Ansichten und müssen den Zustand von Objekten und Vorgängen in hohem Volumen verstehen. Anders als bei Verbraucher-Software ist das Ziel nicht, Informationen auszublenden, sondern sie so zu strukturieren, dass die Person trotz Dichte schnell zu einer Entscheidung kommt.

Die Arbeit fand in einer großen Produkt- und Design-Organisation statt: mehr als 20 Designer:innen, dazu Produktmanagement, Engineering und Research, verteilt über mehrere Produktbereiche. Ein bestehendes Design-System setzte den Rahmen für Komponenten und Interaktionsmuster. Jede lokale Verbesserung musste deshalb zwei Fragen beantworten: Hilft sie den Nutzer:innen an dieser Stelle? Und passt sie zu dem, was in anderen Bereichen des Produkts bereits gilt?

Der Auftrag von Thiago Andrade als Senior Product Designer war, Workflows für ITAM-orientierte Oberflächen zu entwerfen und zu verfeinern, mit Fokus auf Klarheit, Bedienbarkeit und Entscheidungsfähigkeit – in enger Zusammenarbeit mit Produktmanagement, Engineering, Research und den anderen Designer:innen. Das Engagement lief remote mit einem Team in den USA, von Oktober 2025 bis Juli 2026.

Das Problem

Was war das Problem? An der Oberfläche ein Navigationsproblem in einer dichten Tabelle. Darunter eine Reihe von Mustern, die sich in Enterprise-Software immer wieder zeigen.

Tabellen, in denen man sucht statt entscheidet
Die Nutzer:innen mussten in großen Tabellen finden, filtern, speichern und handeln – oft in einem Arbeitsgang. Wenn Navigation und Interaktion nicht zusammenpassen, wird die Tabelle zum Ort, an dem man sucht, statt zum Ort, an dem man entscheidet. Nicht die Datenmenge war das Problem, sondern die fehlende Struktur im Umgang damit.
Dieselben Filter, jeden Tag neu
Wer wiederkehrende Fragen an denselben Datenbestand stellt, baut dieselben Filterkombinationen immer wieder auf. Das kostet Zeit und erzeugt Fehler. Gespeicherte Filter und wiederverwendbare Ansichten waren deshalb nicht Komfort, sondern Voraussetzung für effiziente Arbeit.
Produktzustände schwer lesbar
In Workflows mit hohem Volumen müssen Nutzer:innen verstehen, in welchem Zustand sich Objekte und Vorgänge befinden – ohne jedes Element einzeln zu öffnen. Dichte ohne Priorisierung macht genau das schwer: Alles ist sichtbar, nichts ist hervorgehoben.
Lokale Lösung, globale Nebenwirkung
In einer Organisation mit mehr als 20 Designer:innen und mehreren Produktbereichen ist die naheliegende Gefahr, dass jedes Team das Tabellenproblem für sich löst. Das Ergebnis wären mehrere Varianten desselben Musters – verwirrend für Nutzer:innen, teuer für Engineering.
Design-System, Produktanforderung, Nutzerbedarf
Die drei Kräfte ziehen nicht immer in dieselbe Richtung. Das bestehende Design-System gab Komponenten vor, das Produktmanagement hatte Anforderungen und Fristen, die Nutzer:innen brauchten etwas, das in ihren realen Abläufen funktioniert. Eine gute Lösung musste alle drei ernst nehmen, ohne eine davon zu opfern.

Wie wir vorgegangen sind

Wie sind wir vorgegangen? Vom konkreten Problem zur übertragbaren Lösung – mit Validierung an jeder Stelle, an der eine Entscheidung über die eine Tabelle hinaus wirkte.

1
Einarbeitung in Produkt, Nutzer:innen und bestehende Muster
Zu Beginn stand die Ist-Analyse des Produktkontexts: Wer arbeitet mit diesen Tabellen, welche Entscheidungen werden daraus abgeleitet, welche Muster gelten bereits im Design-System und in benachbarten Produktbereichen. B. Interviews, Analyse bestehender Tickets]]
2
Vom Tabellenproblem zum Interaktionsmodell
Ausgangspunkt war ein spezifisches Navigationsproblem in einer dichten Tabelle. Statt es isoliert zu lösen, haben wir die Navigations- und Interaktionsmuster für Tabellen untersucht, in denen Nutzer:innen große Informationsmengen finden, filtern, speichern und bearbeiten müssen. Daraus entstanden User Flows, Wireframes und Interaktionsmodelle, die das Verhalten der Tabelle als Ganzes beschreiben – nicht nur die eine Stelle, an der es hakte.
3
Gespeicherte Filter und wiederverwendbare Ansichten
Parallel haben wir untersucht, wie gespeicherte Filter und ein Konzept für Ansichtsverwaltung wiederkehrende Arbeit reduzieren und den Nutzer:innen mehr Kontrolle über ihre Arbeitsumgebung geben. Der Anspruch war, dass dasselbe Konzept in mehr als einem Produktbereich funktioniert. So wurde aus einer Verbesserung für eine Tabelle eine Chance für ein Muster, das sich im Produkt wiederverwenden lässt.
4
Usability-Tests und Konzeptvalidierung
Die Designrichtungen wurden in Usability-Sitzungen mit Nutzer:innen geprüft. Dafür haben wir Testpläne erstellt, Sitzungen durchgeführt, Feedback in Schleifen zurückgespielt und die Ergebnisse strukturiert synthetisiert. Die zentrale Frage war nicht, ob ein Entwurf gefällt, sondern ob die Verbesserungen die realen Arbeitsabläufe tragen.
5
Abstimmung über Teams und Design-System
In einer Organisation mit mehr als 20 Designer:innen ist Abstimmung Teil der Designarbeit. Wir haben die Konzepte in Critiques vorgestellt, mit Designer:innen anderer Produktbereiche abgeglichen und so dokumentiert, dass lokale Verbesserungen mit den übergreifenden Produktmustern kompatibel blieben. Wo das Design-System Grenzen setzte, haben wir innerhalb dieser Grenzen gearbeitet oder den Bedarf für eine Erweiterung begründet, statt eigene Komponenten zu bauen.
6
High-Fidelity-Design und Übergabe
Die validierten Konzepte wurden als High-Fidelity-Designs ausgearbeitet, die sich an das Design-System halten, und zusammen mit Interaktionsmodellen und teamübergreifender Design-Dokumentation an Produktmanagement und Engineering übergeben. Engineering sollte nicht nur Screens bekommen, sondern das Verhalten verstehen – auch dort, wo Tabellen, Filter und Zustände zusammenspielen.

Ergebnis

Was kam dabei heraus? Klarere Workflows in einem dichten Enterprise-Produkt – und ein Muster, das über die ursprüngliche Stelle hinaus trägt. Wir nennen hier bewusst keine Kennzahlen, weil uns dafür keine freigegebenen Messwerte vorliegen.

Aspekt	Vorher	Nachher
Tabellennavigation	Ein konkretes Navigationsproblem in einer dichten Tabelle, lokal betrachtet	Ein Interaktionsmodell für Tabellen, das Finden, Filtern, Speichern und Handeln als zusammenhängenden Ablauf beschreibt
Wiederkehrende Filter	Filterkombinationen wurden pro Sitzung neu aufgebaut	Validiertes Konzept für gespeicherte Filter und wiederverwendbare Ansichten, angelegt für mehrere Produktbereiche
Reichweite der Lösung	Verbesserung für eine Stelle im Produkt	Chance für ein wiederverwendbares Produktmuster, mit anderen Teams abgestimmt
Produktrichtung	Designrichtungen auf Basis von Annahmen	Richtungen in Usability-Tests und Konzeptvalidierung geprüft, Befunde strukturiert synthetisiert
Konsistenz	Risiko paralleler Varianten desselben Musters in verschiedenen Teams	Design-System-konforme Muster und teamübergreifende Dokumentation

Klarere Workflows für dichte Daten
Informationsarchitektur, Interaktionsverhalten und Entscheidungsabläufe für Nutzer:innen, die mit dichten operativen Daten arbeiten, wurden verbessert. Die Dichte blieb, aber mit Struktur, Klarheit und Priorisierung.
Vom lokalen Problem zum Muster
Das ursprüngliche Tabellenproblem wurde zu einer breiteren Chance für ein wiederverwendbares Muster. Das ist der eigentliche Hebel in einem großen Produkt: eine Lösung, die nicht an einer Stelle endet.
Validierte Produktrichtung
Usability-Tests und Konzeptvalidierung haben geprüft, ob die vorgeschlagenen Verbesserungen reale Arbeitsabläufe unterstützen. Die Produktrichtung stützte sich damit auf Beobachtung statt auf Annahmen.
Wirksam in einer großen Design-Organisation
Trotz starker teamübergreifender Abhängigkeiten entstanden Ergebnisse, die lokal halfen, ohne das Produkt zu fragmentieren – Nutzerbedarf, Enterprise-Komplexität und Design-System-Konsistenz im Gleichgewicht.

Was wir gelernt haben

01
Ein Tabellenproblem ist selten nur ein Tabellenproblem
Wenn Nutzer:innen in einer Tabelle nicht weiterkommen, liegt die Ursache meist im Zusammenspiel von Navigation, Filtern, gespeicherten Ansichten und Zustandsanzeige. Wer nur die gemeldete Stelle repariert, bekommt das nächste Ticket aus dem Nachbarmodul. Wir prüfen deshalb bei jedem lokalen Befund, ob er ein Symptom eines fehlenden Musters ist – in ITAM-Plattformen genauso wie in Fachsystemen für Banken oder Leitsystemen in der Industrie.
02
Dichte ist kein Fehler – fehlende Priorisierung ist einer
Technische und operative Nutzer:innen brauchen viel Information auf einmal. Der Reflex, Dinge auszublenden, führt bei ihnen zu Misstrauen. Was sie brauchen, ist Struktur: Was ist der Zustand, was braucht Aufmerksamkeit, was kann warten. Gutes Enterprise-Design nimmt die Dichte an und ordnet sie, statt sie wegzudesignen.
03
In großen Organisationen ist Abstimmung Teil des Designs
Mit mehr als 20 Designer:innen und mehreren Produktbereichen entscheidet nicht der beste Entwurf, sondern der Entwurf, der mit dem Rest des Produkts kompatibel ist und von anderen Teams getragen wird. Critiques, Pattern-Dokumentation und frühe Gespräche mit den Nachbarteams sind keine Nebenarbeit – sie sind der Weg, auf dem eine lokale Idee zum Produktmuster wird.
04
Erst validieren, dann skalieren
Ein Muster, das im ganzen Produkt gelten soll, muss mehr aushalten als eine Einzellösung. Bevor wir ein Konzept für gespeicherte Filter als wiederverwendbar vorgeschlagen haben, wurde es in Usability-Sitzungen gegen reale Arbeitsabläufe geprüft. Die Reihenfolge ist wichtig: Validierung vor Skalierung spart Engineering-Aufwand und verhindert, dass ein Fehler in alle Module kopiert wird.
05
Das Design-System ist ein Rahmen, kein Hindernis
Es ist leichter, eine eigene Komponente zu zeichnen, als die bestehende zu verstehen und zu erweitern. Nachhaltig ist nur das Zweite. Wenn ein Bedarf im System nicht abgedeckt ist, begründen wir die Erweiterung, statt daran vorbeizuarbeiten – das hält das Produkt konsistent und die Übergabe an Engineering berechenbar.

Was wir geliefert haben

User Flows für tabellenlastige ITAM-Workflows
Wireframes und Interaktionsmodelle für Tabellennavigation
Konzepte für gespeicherte Filter und wiederverwendbare Ansichten
High-Fidelity-Designs, konform zum bestehenden Design-System
Usability-Testpläne
Research-Synthese und Befunde aus der Konzeptvalidierung
Tabellen-Interaktionsmuster mit Potenzial zur Wiederverwendung
Design-System-konforme Muster
Teamübergreifende Design-Dokumentation für Produktmanagement und Engineering

Häufige Fragen

Warum zeigt der Case keine Screens und keine Zahlen?: Weil wir aus diesem Engagement keine Produkt-Screens und keine Messwerte veröffentlichen, die nicht ausdrücklich freigegeben sind. Wir beschreiben Problem, Vorgehen und Ergebnis qualitativ; Details gibt es im Gespräch, soweit wir sie teilen dürfen.
Was bringt Beabstracto aus dieser Arbeit für Hersteller von Enterprise-Software mit?: Erfahrung mit genau den Problemen, die Head of Product und Produktmanagement bei Enterprise-SaaS beschäftigen: dichte Tabellen, wiederkehrende Filterarbeit, Muster, die pro Modul auseinanderlaufen, und ein Design-System, das Konsistenz sichern soll, ohne Weiterentwicklung zu blockieren. Dazu die Praxis, Konzepte in Usability-Tests zu validieren, bevor sie skaliert werden.
Wie arbeitet Beabstracto in einer bestehenden Design-Organisation mit eigenem Design-System?: Innerhalb des Rahmens, den das System vorgibt. Wir lernen zuerst, welche Muster bereits gelten, nehmen an Critiques teil und dokumentieren so, dass andere Teams die Arbeit weiterführen können. Wo das System einen Bedarf nicht abdeckt, begründen wir die Erweiterung, statt eigene Komponenten einzuführen.
Ist das auf Fachsysteme in Banking und Industrie übertragbar?: Ja. Tabellen mit vielen Zeilen, gespeicherte Ansichten, lesbare Zustände und Entscheidungen unter Zeitdruck sind der Alltag in Fondsbuchhaltung, Steuerreporting und Leitsystemen genauso wie im IT-Asset-Management. Die Fachdomäne wechselt, die UX-Fragen bleiben: Wie findet die Person, was sie braucht, und wie erkennt sie, was Aufmerksamkeit verlangt?
Wie lief die Zusammenarbeit remote mit einem Team in den USA?: Vollständig remote, über Zeitzonen hinweg mit Produktmanagement, Engineering, Research und Designer:innen. Das setzt saubere Dokumentation und asynchrone Abstimmung voraus – Fähigkeiten, die wir im DACH-Raum ebenso einsetzen, wenn Fachbereich, IT und externe Berater:innen an verschiedenen Standorten sitzen.