Können Sie unsere DocuWare-Workflows verbessern?

Ja – aus Anwendersicht. Wir nehmen Ihre Prozesse auf (Rechnungseingang, Freigaben, Posteingang, Akten), prüfen mit Ihren Key Usern, wo Workflows und Konfiguration haken, und erarbeiten ein Fachkonzept, das Ihr DocuWare-Partner oder Ihre IT umsetzt. Wir verkaufen keine Lizenzen und konfigurieren nicht gegen Ihren Betreuer; wir sorgen dafür, dass das, was konfiguriert wird, vom Fachbereich verstanden und genutzt wird.

Sind Sie DocuWare-Partner?

Nein. Beabstracto ist kein DocuWare-Partner, kein Reseller und nicht vom Hersteller beauftragt. Thiago Andrade war von Februar 2023 bis Februar 2026 dort als UX/UI Designer angestellt; Beabstracto ist unabhängig und berät ohne Lizenzverkauf. Dieser Case beschreibt Erfahrung aus einer Festanstellung, kein Beratungsmandat.

Was bedeutet „pragmatische und hedonische Qualität“ konkret?

Pragmatische Qualität meint: Erledigen Nutzer ihre Aufgabe effizient, sicher und mit wenigen vermeidbaren Problemen? Hedonische Qualität meint: Wirkt das Produkt stimmig, modern, vertrauenswürdig? Wir arbeiten mit Benchmarks, die sich an Modellen wie dem User Experience Questionnaire (UEQ) und Hassenzahls Unterscheidung orientieren, und machen beides vor und nach Änderungen vergleichbar.

Wir sind Softwarehersteller, kein DMS-Anwender – passt das?

Gerade dann. Konfigurationslastige Module, Workflow-Editoren, Admin-Oberflächen und Design-System-Grundlagen sind der Kern dieser Erfahrung. Wir unterstützen Produktteams mit Research, Benchmarks, Prototypen und Design-System-Arbeit – als externe UX-Kapazität, die in Squads mitarbeitet, nicht als Agentur, die Entwürfe über den Zaun wirft.

Wir stehen vor einer DMS-Einführung oder vor dem Wechsel auf den webbasierten Workflow Designer. Wo setzen Sie an?

Vor der Konfiguration. Wir nehmen die Ist-Prozesse auf, formulieren mit dem Fachbereich das Soll im Fachkonzept, testen kritische Workflows mit Key Usern vor dem Go-live und begleiten Schulung und Hypercare. Der Umstieg auf eine neue Workflow-Designer-Generation ist der richtige Moment, Altlasten in den Workflows zu bereinigen, statt sie eins zu eins zu migrieren.

Woher stammen die Inhalte dieses Cases?

Aus dem öffentlich beschriebenen Tätigkeitsprofil der Festanstellung. Interne Benchmark-Werte, Kundennamen, Teamgrößen und Produktinterna veröffentlichen wir nicht. Deshalb finden Sie hier qualitative Vorher-Nachher-Beschreibungen statt Prozentzahlen.

DMS/ECM · DocuWare · 2023–2026

Workflow-Konfiguration im DMS verständlich machen – und UX-Qualität messbar.

Für Administratoren und Key User, die in einem Dokumentenmanagementsystem Workflows konfigurieren, zählen Präzision, vorhersehbares Verhalten und klare Rückmeldung. Drei Jahre UX/UI-Design in Festanstellung bei DocuWare: Workflow Designer, Enterprise-Konfiguration, Design-System-Grundlagen – und UX-Qualität, die über Benchmarks, Rituale und OKRs messbar wurde.

Erstgespräch vereinbaren Wie wir vorgegangen sind

Kunde: DocuWare (Arbeitgeber, Festanstellung)
Branche: Dokumentenmanagement und Workflow-Automatisierung (DMS/ECM), B2B-SaaS
Rolle: UX/UI Designer in Festanstellung – Produktdesign, Research, Design-System, UX-Benchmarks
Zeitraum: Februar 2023 – Februar 2026, München
Systeme: DocuWare Workflow Designer, Enterprise-Konfiguration, Figma
Team: Mehrere Produktteams (Squads) mit Produktmanagement, Engineering, QA, UX Research und Design

Kurz gesagt

DocuWare ist eine B2B-SaaS-Plattform für Dokumentenmanagement und Workflow-Automatisierung: Unternehmen erfassen, verarbeiten, leiten, archivieren und finden damit Geschäftsdokumente – vom Rechnungseingang bis zur revisionssicheren Ablage. Thiago Andrade, Gründer von Beabstracto, arbeitete dort von Februar 2023 bis Februar 2026 in Festanstellung als UX/UI Designer in München. Schwerpunkte: Usability des Workflow Designers, konfigurationslastige Enterprise-Flows, Grundlagen des Design-Systems (Tokens, Figma-Migration, Dokumentation) sowie UX-Benchmarks, Qualitätsrituale und OKRs, die UX-Qualität in einem reifen Produkt messbar machten.

Warum das für Sie relevant ist: Ob ein DMS im Fachbereich wirklich genutzt wird, entscheidet sich bei der Konfiguration der Workflows und an der Frage, ob Anwender ihre Aufgaben sicher zu Ende bringen. Diese Erfahrung bringt Beabstracto in DMS/ECM-Einführungen auf Kundenseite und in Produktteams von Softwareherstellern ein – unabhängig, ohne Lizenzverkauf.

Ausgangslage

Was war die Ausgangslage? Ein ausgereiftes B2B-SaaS-Produkt mit einer großen, heterogenen Nutzerbasis – und ein Werkzeug im Zentrum, das mächtig und genau deshalb anspruchsvoll ist: der Workflow Designer.

DocuWare wird von Unternehmen eingesetzt, um Geschäftsdokumente zu erfassen, zu indexieren, durch Prüf- und Freigabeprozesse zu leiten, GoBD-konform zu archivieren und wiederzufinden. Der typische Fall im Mittelstand ist der digitale Rechnungseingang: Eine Rechnung kommt an, wird indexiert, läuft durch sachliche Prüfung und Freigabe – oft mit Vier-Augen-Prinzip – und landet in der Buchhaltung und im Archiv. Ähnlich funktionieren Posteingang, Vertragsakten oder Personalvorgänge.

Herzstück dieser Automatisierung ist der Workflow Designer. Darin modellieren Administratoren und Key User, wie ein Dokument durch das Unternehmen läuft: Welche Bedingung löst welchen Schritt aus, wer entscheidet, was passiert bei Ausnahmen, wann wird eskaliert. Ein Konfigurationsfehler fällt dabei selten beim Klicken auf, sondern später im Betrieb – wenn ein Vorgang in einer Schleife hängt oder eine Freigabe niemanden erreicht.

Die Menschen, die solche Flows konfigurieren, sind selten Softwareentwickler. Es sind IT-Verantwortliche, Fachbereichsleitungen und Key User, die das DMS neben ihrer eigentlichen Arbeit betreuen. Sie brauchen Präzision, vorhersehbares Verhalten und klare Rückmeldungen – nicht noch mehr Funktionen.

Die Design-Aufgabe war darum nicht, hübschere Oberflächen zu zeichnen. Sie war, Enterprise-Anwendern zu helfen, Dokumentenprozesse zu verstehen, Workflows zu konfigurieren, Ausnahmen zu behandeln und Aufgaben effizient abzuschließen – in einem reifen Produkt-Ökosystem, in dem jede Änderung Bestandskunden betrifft. Dazu kam ein zweiter Auftrag: die UX-Praxis der Organisation reifen zu lassen, mit Research-Routinen, Design-System-Standards, Usability-Benchmarks und Qualitätsritualen über mehrere Produktteams hinweg.

Thiago Andrade war in dieser Zeit als UX/UI Designer in Festanstellung Teil mehrerer Squads und arbeitete eng mit Produktmanagement, Engineering, QA, UX Research und anderen Designern zusammen. Dieser Case ist also kein Beratungsmandat von Beabstracto. Er zeigt, welche Erfahrung das Studio aus drei Jahren im Inneren eines DMS-Herstellers für seine Kunden mitbringt.

Das Problem

Was war das Problem? Weniger ein einzelner Fehler als eine Summe von Reibungen in konfigurationslastigen Abläufen. Interviews, Usability-Studien und strukturierte Feedback-Sessions zeigten im Workflow Designer immer wieder dieselben vier Muster – Navigation, Progressive Disclosure, Feedback und Aufgabenabschluss – und dahinter zwei organisatorische Ursachen.

Orientierung im Workflow geht verloren
Ein Workflow besteht aus Schritten, Bedingungen, Rollen und Ausnahmen. Wer tief in einer Verzweigung arbeitet, verliert leicht den Überblick: Wo bin ich, was habe ich schon konfiguriert, was fehlt noch? Die Navigation musste den Kontext tragen, statt ihn zu verstecken.
Alles auf einmal statt Schritt für Schritt
Konfigurationsmasken zeigten viele Optionen gleichzeitig – auch solche, die erst später oder nur in Sonderfällen relevant sind. Für Experten bequem, für Key User überfordernd. Es fehlte an Progressive Disclosure: das Nötige zuerst, das Mögliche auf Abruf.
Keine klare Rückmeldung
Ist der Workflow gültig? Wurde die Änderung übernommen? In welchem Zustand ist dieser Schritt? Wo Zustände nicht sichtbar waren, entstand Mehrdeutigkeit – und Mehrdeutigkeit in einem Konfigurationswerkzeug heißt: nachfragen, ausprobieren, Ticket schreiben.
Unsicherheit beim Abschluss
Enterprise-Anwender brauchen Präzision und vorhersehbares Verhalten. Bleibt unklar, ob eine Aufgabe wirklich fertig ist und was beim Speichern oder Aktivieren passiert, zögern Nutzer – oder sie verlassen sich auf Support und Partner statt auf das Produkt.
Uneinheitliche Muster zwischen Produktbereichen
Über Teams und Jahre hinweg waren Abstände, Größen, Radien, Elevation und Komponentenverhalten auseinandergelaufen. Jeder Produktbereich fühlte sich ein wenig anders an; Nutzer mussten Bedienlogik mehrfach lernen, Teams bauten Ähnliches mehrfach.
UX-Qualität als Geschmacksfrage
Ohne gemeinsame Messgröße wurde über Design per Meinung entschieden. Was „gut genug“ ist, war nicht definiert – und damit gegen neue Features auch nicht priorisierbar.

Wie wir vorgegangen sind

Wie sind wir vorgegangen? Von der Ist-Analyse über Benchmark und Prototyp bis zu Validierung und Qualitätsritualen – immer im Verbund mit Produktmanagement und Engineering, und mit dem Anspruch, Entscheidungen auf Research und Daten zu stützen statt auf Geschmack.

1
Ist-Analyse und Research
Zuerst verstehen, dann gestalten. Interviews, Usability-Studien und strukturierte Feedback-Sessions mit Anwendern zeigten, wo Konfigurationsflows ins Stocken geraten – nicht als Wunschliste, sondern als beobachtete Reibung: Suchen, Zögern, Abbrechen, Nachfragen. Die Synthese daraus wurde zur gemeinsamen Problemdefinition mit Produktmanagement und Engineering.
2
UX-Benchmark aufsetzen
Damit Verbesserung nachweisbar wird, braucht sie einen Ausgangswert. Gemeinsam mit UX Research wurden Benchmarks definiert, orientiert an etablierten Modellen wie dem User Experience Questionnaire (UEQ) und Hassenzahls Unterscheidung von pragmatischer Qualität (Kann ich meine Aufgabe effizient und sicher erledigen?) und hedonischer Qualität (Wirkt das Produkt stimmig, modern, vertrauenswürdig?). So ließ sich der Workflow Designer vor und nach Änderungen vergleichen.
3
Konzept und Prototyp
Auf Basis der Befunde entstanden User Flows, Wireframes und High-Fidelity-Designs für Navigation, Progressive Disclosure und Zustandsanzeigen – als interaktive Prototypen, die früh mit Produktmanagement, Entwicklern und QA geteilt wurden. Technische Grenzen des bestehenden Systems wurden nicht als Hindernis behandelt, sondern als Rahmenbedingung im Konzept.
4
Validierung und Entscheidung
Prototypen wurden in Usability-Tests und Konzeptvalidierungen geprüft; strukturierte UX-Reviews hielten die Ergebnisse fest. Entscheidend war, Research-Erkenntnisse, Benchmark-Daten und Produktentscheidungen zusammenzubringen – damit das Team nicht über Meinungen diskutiert, sondern über Befunde.
5
Design-System-Grundlagen
Parallel ging es an die Basis: Design-Tokens für Abstände, Größen, Radien, Elevation und responsives Verhalten, die Migration nach Figma, Komponentenspezifikationen und Dokumentation. In Design-Critiques und Systemdiskussionen mit anderen Designern wurden Muster abgestimmt, die mehrere Produktbereiche teilen – und Konsistenz wurde zu einer gemeinsamen Verantwortung statt zur Nebensache einzelner Teams.
6
Qualitätsrituale und OKRs
Damit UX-Qualität nicht vom Einzelprojekt abhängt, wurden Verbesserungsrituale etabliert und UX-Audit-Checklisten entwickelt; Benchmark-Ergebnisse flossen als Inputs in OKRs ein, die Usability und Produktqualität verbinden. UX wurde damit zu einer messbaren Größe im Zielsystem der Organisation – nicht zu einem Abnahmeschritt am Ende.

Ergebnis

Was ist das Ergebnis? Verständlichere Konfigurationsflows, ein konsistenteres Produkt und eine Organisation, die UX-Qualität misst statt darüber zu streiten. Interne Benchmark-Werte veröffentlichen wir aus Vertraulichkeitsgründen nicht; die Veränderung beschreiben wir qualitativ.

Aspekt	Vorher	Nachher
Orientierung im Workflow Designer	Kontext geht in tiefen Verzweigungen verloren; Nutzer suchen den eigenen Standort	Navigation trägt den Kontext; sichtbar, was konfiguriert ist und was noch fehlt
Konfigurationsmasken	Alle Optionen gleichzeitig, auch die für Sonderfälle	Progressive Disclosure: Nötiges zuerst, Erweitertes auf Abruf
Rückmeldung und Zustände	Unklar, ob Änderungen gültig sind und übernommen wurden	Zustände sichtbar, Feedback an der Stelle, an der gehandelt wird
Aufgabenabschluss	Zögern, Ausprobieren, Nachfragen beim Support	Vorhersehbares Verhalten; Nutzer wissen, wann sie fertig sind
Design-System	Abstände, Größen und Komponenten je Produktbereich auseinandergelaufen	Gemeinsame Tokens, Figma-Bibliothek und Dokumentation über Squads hinweg
UX-Qualität	Geschmacksfrage, gegen Features nicht priorisierbar	Benchmarks, Rituale und OKR-Inputs; vergleichbar vor und nach Änderungen

Workflow-lastige Flows besser bedienbar
Die Usability-Verbesserungen im Workflow Designer und in Konfigurationsflows setzten dort an, wo Research die Reibung gezeigt hatte: Navigation, Progressive Disclosure, Feedback, Aufgabenabschluss. Weniger Mehrdeutigkeit, sichtbarere Zustände, verständlichere Konfiguration.
Design-System als gelebte Praxis
Token-Grundlagen, Figma-Migration, Komponentenspezifikationen und Dokumentation schufen die Basis für konsistentere Produktbereiche. Konsistenz wurde von der Nebensache einzelner Teams zur geteilten Verantwortung.
UX-Qualität messbar gemacht
Benchmarks, Rituale und OKR-Inputs verbanden Usability mit Produktergebnissen. Designqualität war damit keine subjektive Meinung mehr, sondern eine Größe, die sich über die Zeit verfolgen und gegen andere Prioritäten abwägen lässt.
Bessere Zusammenarbeit über Squads hinweg
Frühes Teilen, strukturierte UX-Reviews und Design-Critiques verbesserten die Zusammenarbeit zwischen Design, Produktmanagement und Engineering – lokale Produktbedürfnisse und gemeinsame Muster wurden gegeneinander ausbalanciert statt gegeneinander ausgespielt.

Was wir gelernt haben

01
Eine DMS-Einführung scheitert selten am Archiv – sie scheitert an der Konfiguration
Ob ein Dokumentenmanagementsystem im Fachbereich angenommen wird, entscheidet sich beim Einrichten der Workflows: Rechnungsfreigabe, Posteingang, Vertragsakte. Wer Prozesse erst versteht und dann konfiguriert – Ist-Analyse vor dem ersten Klick – spart Nacharbeit, Tickets und Frust bei den Key Usern. Für Einführungsprojekte heißt das: Prozessaufnahme, Fachkonzept und Key-User-Begleitung gehören in den Projektplan, nicht in die Hypercare.
02
Pragmatische Qualität zuerst, hedonische nicht vergessen
In Fachanwendungen zählt zuerst, ob Nutzer ihre Aufgaben effizient, sicher und mit wenigen vermeidbaren Problemen erledigen. Aber ein Produkt, das sich altmodisch oder widersprüchlich anfühlt, verliert Vertrauen – und Vertrauen entscheidet über Adoption und Nutzung. Beide Dimensionen gehören in den Benchmark, und beide gehören in die Priorisierung.
03
Messen statt streiten
Ein UX-Benchmark mit Ausgangswert verwandelt Designdiskussionen in Entscheidungen. Er muss nicht akademisch sein; er muss wiederholbar sein und an Ziele gekoppelt, die das Produktteam ohnehin verfolgt – etwa als OKR-Input. Dasselbe gilt für Kunden, die ein neues System einführen: Wer vor dem Go-live misst, kann nach dem Go-live zeigen, was sich verändert hat.
04
Konsistenz ist Schulungsersatz
Jedes Bedienmuster, das Nutzer nur einmal lernen müssen, spart Schulungszeit und Supportanfragen. Design-Tokens, dokumentierte Komponenten und geteilte Muster sind darum kein Design-Luxus, sondern ein Beitrag zu Einführungskosten und Supportlast – beim Hersteller ebenso wie beim Anwenderunternehmen, das Masken und Workflows selbst konfiguriert.
05
Früh teilen, technische Grenzen ernst nehmen
In einem reifen Produkt mit Bestandskunden ist nicht jede gute Idee umsetzbar. Wer Konzepte früh mit Engineering teilt, Annahmen validiert und technische Constraints ins Konzept aufnimmt, liefert Lösungen, die ankommen – nicht Entwürfe, die im Backlog altern. Das gilt in Squads eines Softwareherstellers genauso wie im Einführungsprojekt zwischen Fachbereich, IT und Implementierungspartner.

Was wir geliefert haben

User Flows
Wireframes
High-Fidelity-Designs
Interaktive Prototypen
Usability-Testpläne
Research-Synthesen
UX-Benchmark-Berichte
Design-System-Dokumentation
Design-Tokens und Komponentenspezifikationen
UX-Audit-Checklisten
Teamübergreifende Produktmuster (Cross-Squad-Patterns)
UX-Qualitätsinputs für OKRs

Häufige Fragen

Können Sie unsere DocuWare-Workflows verbessern?: Ja – aus Anwendersicht. Wir nehmen Ihre Prozesse auf (Rechnungseingang, Freigaben, Posteingang, Akten), prüfen mit Ihren Key Usern, wo Workflows und Konfiguration haken, und erarbeiten ein Fachkonzept, das Ihr DocuWare-Partner oder Ihre IT umsetzt. Wir verkaufen keine Lizenzen und konfigurieren nicht gegen Ihren Betreuer; wir sorgen dafür, dass das, was konfiguriert wird, vom Fachbereich verstanden und genutzt wird.
Sind Sie DocuWare-Partner?: Nein. Beabstracto ist kein DocuWare-Partner, kein Reseller und nicht vom Hersteller beauftragt. Thiago Andrade war von Februar 2023 bis Februar 2026 dort als UX/UI Designer angestellt; Beabstracto ist unabhängig und berät ohne Lizenzverkauf. Dieser Case beschreibt Erfahrung aus einer Festanstellung, kein Beratungsmandat.
Was bedeutet „pragmatische und hedonische Qualität“ konkret?: Pragmatische Qualität meint: Erledigen Nutzer ihre Aufgabe effizient, sicher und mit wenigen vermeidbaren Problemen? Hedonische Qualität meint: Wirkt das Produkt stimmig, modern, vertrauenswürdig? Wir arbeiten mit Benchmarks, die sich an Modellen wie dem User Experience Questionnaire (UEQ) und Hassenzahls Unterscheidung orientieren, und machen beides vor und nach Änderungen vergleichbar.
Wir sind Softwarehersteller, kein DMS-Anwender – passt das?: Gerade dann. Konfigurationslastige Module, Workflow-Editoren, Admin-Oberflächen und Design-System-Grundlagen sind der Kern dieser Erfahrung. Wir unterstützen Produktteams mit Research, Benchmarks, Prototypen und Design-System-Arbeit – als externe UX-Kapazität, die in Squads mitarbeitet, nicht als Agentur, die Entwürfe über den Zaun wirft.
Wir stehen vor einer DMS-Einführung oder vor dem Wechsel auf den webbasierten Workflow Designer. Wo setzen Sie an?: Vor der Konfiguration. Wir nehmen die Ist-Prozesse auf, formulieren mit dem Fachbereich das Soll im Fachkonzept, testen kritische Workflows mit Key Usern vor dem Go-live und begleiten Schulung und Hypercare. Der Umstieg auf eine neue Workflow-Designer-Generation ist der richtige Moment, Altlasten in den Workflows zu bereinigen, statt sie eins zu eins zu migrieren.
Woher stammen die Inhalte dieses Cases?: Aus dem öffentlich beschriebenen Tätigkeitsprofil der Festanstellung. Interne Benchmark-Werte, Kundennamen, Teamgrößen und Produktinterna veröffentlichen wir nicht. Deshalb finden Sie hier qualitative Vorher-Nachher-Beschreibungen statt Prozentzahlen.