Sprechen wir
Banking · RAQUEST / MiKaDiv
Ein MiKaDiv-Meldemodul, das Sachbearbeiter unter Fristdruck sicher bedienen können.
Beabstracto arbeitete als UX-Beratung für den Hersteller einer Software zur Quellensteuer-Erstattung. Für ein neues Meldemodul nach MiKaDiv und die Modernisierung der etablierten Plattform RAQUEST haben wir verstreutes Fachwissen in ein wiederverwendbares Entscheidungsgerüst übersetzt — und in einen Prototyp in TypeScript, den Stakeholder von Tier-1-Banken für fertige Software hielten.
- Kunde
- Hersteller der Software RAQUEST (Quellensteuer-Erstattung)
- Branche
- Banking · Steuer-Software · regulatorisches Reporting
- Rolle
- Externe UX-Beratung, UX-Lead für zwei Produktfronten
- Systeme
- RAQUEST, MiKaDiv-Meldemodul (BZSt/ELMA), Figma, Prototyp in TypeScript
- Team
- Beabstracto: UX-Lead und ein weiterer Designer · Herstellerseite: Entwickler, Product Owner, CEO
Kurz gesagt
Beabstracto war UX-Beratung für den Hersteller einer Software zur Quellensteuer-Erstattung (RAQUEST). Der Auftrag umfasste zwei verbundene Fronten: ein neues Reporting-Modul für das Mitteilungsverfahren MiKaDiv an das Bundeszentralamt für Steuern und die UX-Modernisierung der etablierten Plattform. Das Fachwissen war vorhanden, aber über Entwickler, Product Owner und Geschäftsführung verstreut. Wir haben es in eine Kette von Artefakten übersetzt — Glossar, Personas, Prozess-Cluster, kritische Momente, UX-Tensions, Design-Prinzipien, Informationsarchitektur — und in einen TypeScript-Prototyp für „Manage Reports“, den Stakeholder von Tier-1-Banken für ein fertiges Produkt hielten. Ergebnis: elf wiederverwendbare UX-Fundamente und eine MVP-Referenz für das Modul.
Für Hersteller von Banking- und Steuer-Software zeigt der Case, wie ein neues regulatorisches Modul ohne lange Schulung bedienbar wird — und wie UX-Entscheidungen so dokumentiert werden, dass Engineering, Produktmanagement und Vertrieb sie wiederverwenden können.
Zahlen
Alle Zahlen stammen aus den Projektartefakten, wie sie im Portfolio dokumentiert sind. Geschäftskennzahlen wurden in dieser Phase nicht gemessen.
- 11
- wiederverwendbare UX-Fundamente, vom Glossar bis zum KPI-Rahmen
- 6 → 8
- UX-Tensions im Team abgestimmt, daraus acht Design-Prinzipien
- 12
- kritische Momente, in denen das System nicht versagen darf
- 10
- Tabs im Report-Detail, vom Überblick bis zu XML-Ansicht und Validierung
Projektartefakte, Portfolio-Dokumentation
Workshop-Voting, Projektartefakte
Workshop ‚Critical Moments‘, Projektartefakte
TypeScript-Prototyp Manage Reports
Ausgangslage
Was war die Ausgangslage? Ein etablierter Hersteller mit tiefem Fachwissen, ein neues Meldeverfahren mit festem Datum — und noch keine explizite UX-Logik.
RAQUEST ist eine seit über zwanzig Jahren am Markt etablierte Software zur Quellensteuer-Erstattung. Ihr Hersteller ist eine engineering-geführte Organisation: Entwickler, Product Owner und Geschäftsführung kennen Erstattungsprozesse, Verwahrketten und die Anforderungen der Finanzverwaltung aus langer Praxis. Die Nutzer der Software sind Fachleute in Banken und bei auszahlenden Stellen, keine Gelegenheitsnutzer. Sie arbeiten mit Fristen, Validierungsregeln, Vier-Augen-Freigaben, Audit-Trails und technischen Nachweisen.
Mit MiKaDiv, dem Mitteilungsverfahren für Kapitalerträge und Dividenden, kommt eine neue Meldepflicht an das Bundeszentralamt für Steuern (BZSt) hinzu. Sie gilt erstmals für Kapitalerträge, die nach dem 31. Dezember 2026 zufließen, also operativ ab dem 1. Januar 2027 (§ 52 Abs. 44b EStG). Meldepflichtig sind Emittenten (§ 45b Abs. 9 EStG), auszahlende Stellen (§ 45b EStG) und Wertpapiersammelbanken (§ 45c EStG); die Fristen laufen im Folgejahr auf den 31. März, den 30. April und den 31. Juli zu (Quelle: BZSt). Für den Hersteller hieß das: ein neues Reporting-Modul, das innerhalb des bestehenden Ökosystems laufen muss — validierungsintensiv, fristgetrieben, mit Tausenden Meldungen pro Periode.
Wer diese Meldungen bearbeitet, sitzt im Fachbereich einer Bank oder einer auszahlenden Stelle: Sachbearbeiter, die Fälle vorbereiten und einreichen; erfahrene Sachbearbeiter, die Fälle Ende-zu-Ende bearbeiten und im Vier-Augen-Prinzip freigeben; Teamleiter, die SLAs und Durchsatz verantworten; Administratoren, die Stammdaten, Regeln und Berechtigungen pflegen. In den Workshops beschrieben die Fachleute des Herstellers diesen Alltag mit Sätzen wie „Was mache ich jetzt?“ bei unklaren Fehlermeldungen, „Die Information ist überall verteilt“ beim Wechsel zwischen Screens und Tabs und „Wann erreichen wir das SLA?“ beim Blick auf isolierte Kennzahlen ohne Kontext.
Auf dem Spiel stand mehr als ein Screen-Design. Fehler in einem regulierten Meldeprozess erzeugen SLA-, Rechts-, Finanz- und Vertrauensrisiken. Gleichzeitig durfte die Modernisierung der bestehenden Plattform die etablierten Workflows und das Vertrauen der Bestandskunden nicht beschädigen. Beabstracto wurde als externe UX-Beratung für die UX-Führung beider Fronten engagiert; wir haben die UX-Arbeit geleitet und einen weiteren Designer aus unserem Studio koordiniert.
Das Problem
Was war das Problem? Nicht fehlendes Fachwissen — sondern eine UX-Logik, die noch nicht explizit, nicht wiederverwendbar und nicht an Geschäftsentscheidungen gekoppelt war.
Fachwissen verstreut, Personas implizit
Wer die Software nutzt, wussten Entwickler, Product Owner und Geschäftsführung — jeder aus seiner Perspektive. Es gab keine priorisierten Personas, an denen sich Trade-offs entscheiden ließen. Entscheidungen klangen wie „Ich glaube, die Nutzer würden …“ oder „Machen wir es flexibel für alle“.
Prozesse als Feature-Listen
Geschäftsprozesse wurden als Features oder Screens diskutiert, nicht als Ende-zu-Ende-Workflows. Wo im Ablauf Wert entsteht und wo das SLA-Risiko sitzt, war nicht sichtbar — und damit auch nicht, was zuerst gebaut werden muss.
Trade-offs meinungsgetrieben
Geschwindigkeit oder Sicherheit? Führung oder freie Navigation? Automatisierung oder manuelle Kontrolle? In einem regulierten Umfeld sind das keine Geschmacksfragen, sondern Geschäftsentscheidungen. Sie wurden aber pro Screen neu verhandelt, je nachdem, wer gerade im Raum war.
SLA- und Risikologik nicht im Interface
Dass Fristen und SLAs den Alltag bestimmen, war allen klar. Nur hatte sich das noch nicht in Interface-Verhalten übersetzt: Statusanzeigen, Validierungszustände, Eskalationssignale, rollenbasierte Aktionen.
Manage Reports unter SLA-Druck
Im Kern des neuen Moduls mussten operative Nutzer Tausende Meldungen pro Periode finden, validieren, korrigieren, freigeben und nachverfolgen — bevor Fristen reißen, im Vier-Augen-Prinzip und mit lückenlosem Audit-Trail. Das System war, in den Worten des Teams, noch „passiv“: Man musste nach Aufgaben suchen, statt zu erfahren, was bis wann zu tun ist und warum.
Wie wir vorgegangen sind
Wie sind wir vorgegangen? In drei Arbeitsmodi und entlang einer Kette von Artefakten, in der jedes das nächste ermöglicht. Als Moderator haben wir Arbeitssitzungen mit Entwicklern, Product Owner und CEO strukturiert, um Fachwissen herauszuholen, Trade-offs sichtbar zu machen und Risiken zu priorisieren. Als Übersetzer haben wir regulatorische und technische Komplexität in UX-Artefakte und Produktentscheidungen übersetzt, die das Team täglich nutzen kann. Als Maker haben wir den Prototyp gebaut, mit dem Team und Interessenten das Produkt erleben konnten, statt es sich vorzustellen. Die Artefakte waren dabei keine unabhängigen Deliverables: Die gemeinsame Sprache ermöglichte Personas, Personas klärten die relevanten Prozesse, Prozesse zeigten kritische Momente, kritische Momente wurden zu UX-Tensions, Tensions zu Prinzipien, Prinzipien zu Regeln, Regeln zur Informationsarchitektur — und die Informationsarchitektur zum Prototyp.
- 1
Gemeinsame Sprache (Ist-Analyse)
Zuerst Glossar und Taxonomie: Was ist ein Antrag, was ein Claim, was ein Ertrag? Wer ist Approver, was leistet der Audit-Trail, was läuft über ELMA an das BZSt? Dazu ein regulatorisches Mapping von MiKaDiv, Fristen und SLAs. Ohne diese Sprache konnten UX, Product Owner, Engineering und Geschäftsführung nicht über dasselbe Produktverhalten reden. Das Glossar wuchs auf Dutzende Begriffe über RAQUEST und MiKaDiv hinweg.
- 2
Für wen wir entwerfen: Personas und Nutzung × Auswirkung
Mit dem Team haben wir Nutzergruppen und Kundentypen gesammelt und nach täglicher Nutzung und Geschäftsauswirkung priorisiert. Vier Personas entstanden: der Assistant Clerk, der klare Handlungsaufforderungen und geführte Prozesse ohne Interpretationsspielraum braucht; der Professional Clerk, der Fälle Ende-zu-Ende bearbeitet und mit Audit-Trail freigibt; der Team Lead, für den SLA-Dashboards der Einstiegspunkt sind; der Systemadministrator für Stammdaten, Regeln und Berechtigungen. Assistant Clerk und Team Lead wurden die primären Design-Anker — für MiKaDiv und für die gemeinsamen Muster der Plattform.
- 3
Welche Arbeit das Produkt tragen muss: Prozessaufnahme und Cluster
Statt über Screens zu reden, haben wir Ende-zu-Ende-Prozesse gesammelt — Standarderstattung einreichen, Vier-Augen-Freigabe, SLAs überwachen, Importläufe korrigieren, Relief-at-Source-Dokumente erzeugen — und in fünf Cluster gruppiert: Standard- und Quick-Refund, Systemadministration, Managing/Reporting, Relief at Source und Import-Management. Jedes Cluster wurde nach Nutzungshäufigkeit und Schaden bei Versagen (SLA, Risiko, Geld) bewertet. Der wichtigste Produkt-Shift kam aus dieser Übung: weg vom passiven System („Ich muss nach Aufgaben suchen“), hin zum informativen („Erledige das bis Datum X, weil SLA Y gilt“).
- 4
Wo das Produkt nicht versagen darf: kritische Momente und UX-Tensions
Entlang der Journeys hat das Team zwölf kritische Momente benannt — kein Import oder Export, verpasste Fristen, Stammdatenänderungen, die manuelle Korrekturen überschreiben, falsche Besteuerungsregeln, fehlerhafte Daten aus Vorsystemen, unklare Fehlermeldungen, Review-Aufgaben beim falschen Nutzer. Dann die Trade-offs: Sechs UX-Tensions — Geschwindigkeit gegen Sicherheit, Führung gegen Exploration, Flexibilität gegen Kontrolle, Transparenz gegen Abstraktion, Automatisierung gegen manuelle Kontrolle, Sichtbarkeit gegen Minimalismus — wurden im Team per Voting entschieden, bevor jemand über ein UI stritt.
- 5
Wie sich das Produkt verhalten soll: Prinzipien und Regeln (Fachkonzept)
Aus den Gewinnern der Tensions wurden acht Design-Prinzipien: Sicherheit vor Geschwindigkeit, Führung vor freier Exploration, Systemkontrolle vor Flexibilität, Transparenz vor Abstraktion, Automatisierung vor manueller Kontrolle, kontextuelle Sichtbarkeit vor Minimalismus, Standardisierung vor übermäßiger Anpassung, Strenge vor der Einreichung und Nachsicht danach. Jedes Prinzip wurde in konkrete Regeln übersetzt: ungültige Aktionen früh blockieren und kontrollierte Korrektur danach erlauben; SLA-Status, Blockaden und fehlende Dokumente anzeigen, ohne das UI zu überladen; regelbasierte Entscheidungen nicht vom Gedächtnis der Nutzer abhängig machen. Eine RACI-artige Berechtigungslogik klärte, wer Fälle sieht, wer im Vier-Augen-Prinzip freigibt, wer SLAs überwacht und wer Importe verwaltet.
- 6
Wie das zum Interface wird: Informationsarchitektur und Journeys
Die Informationsarchitektur verknüpfte Rollen, Aufgaben und Produktbereiche zu rollenbasierten Einstiegen. Die Haupt-Journey für Manage Reports bekam sieben Schritte mit je einer klaren Absicht: Periode und Arbeitslast verstehen, filtern, Probleme erkennen, Details prüfen, korrigieren und revalidieren, freigeben oder ablehnen, SLA-Fortschritt überwachen. Informationsarchitektur und Journeys wurden mit den Stakeholdern validiert, bevor hochaufgelöstes UI entstand.
- 7
Prototyp in TypeScript statt Klick-Dummy
Figma allein hätte das operative Verhalten nicht vermittelt: Filter, Statuswechsel, Bulk-Aktionen, Report-Inspektion, Validierung, Logs und Modal-Interaktionen mussten sich echt anfühlen. Also haben wir Manage Reports in TypeScript gebaut, mit realistischen Daten: eine Liste mit Periodenkontext und Arbeitslast-Signalen; erweiterte Filter nach Periode, Kunde, Land, ISIN, Status, SLA und Bearbeitungsstand; Ampel-Validierung mit Fehlerzählern; Bulk-Freigabe, -Revalidierung und -Ablehnung; ein Report-Detail mit zehn Tabs — Überblick, Eigentum, Ertrag, Zahlungskette, Steuerbescheinigung, Bestände, Historie, Übertragungslogs, XML-Ansicht, Validierung. Der Prototyp diente intern als Abstimmungsinstrument zwischen Engineering und Geschäftsführung und extern in Gesprächen des Herstellers mit Tier-1-Banken.
Artefakte
Ausgewählte Tafeln aus der Fundamentarbeit — ohne Kundendaten und ohne Produkt-Screenshots.
Ergebnis
Was war das Ergebnis? Ein Entscheidungsgerüst, das beide Produktfronten trägt, und ein Prototyp, der aus einer Produktvision eine MVP-Referenz machte.
| Aspekt | Vorher | Nachher |
|---|---|---|
| Einen Report unter Tausenden finden | Listen durchscrollen, Screens und Tabs wechseln, Kontext verlieren | Filter nach Periode, Kunde, Land, ISIN, Status, SLA und Bearbeitungsstand |
| Validierungsfehler erkennen | Unklare Fehlermeldung — „Was mache ich jetzt?“ | Ampelstatus, Warnungen, Fehlerzähler und die nächste Aktion |
| Reports freigeben | Einzelaktionen, Vier-Augen-Prinzip nur im Kopf der Beteiligten | Bulk-Freigabe, -Ablehnung und -Revalidierung mit Rollen und Audit-Trail |
| SLA-Risiko sehen | Erst sichtbar, wenn die Frist bereits gerissen ist | Fortschritts-Widgets, Statusverteilung, SLA-Indikatoren, Filter nach Frist und Risiko |
| Übermittlung nachweisen | Black Box zwischen Freigabe und BZSt | Übertragungslogs, XML-Ansicht, Quittung und Statusinformation |
| UX-Entscheidungen begründen | Meinung gegen Meinung, pro Screen neu | Rückverfolgbar auf Persona, Prozess, kritischen Moment und Prinzip |
Kommerzielle Wirkung
Der TypeScript-Prototyp machte die MiKaDiv-Vision greifbar genug, dass Stakeholder von Tier-1-Banken ihn für fertige Software hielten. Er wurde zum kommerziellen und strategischen Referenzpunkt des Herstellers in Bankgesprächen.
Produkt- und Engineering-Wirkung
Manage Reports wurde die konkrete Referenz für MVP-Umfang und erwartetes Produktverhalten. Entwickler hatten ein greifbares Modell für Filter, Validierung, Bulk-Aktionen, Audit-Trails und die Struktur des Report-Details — statt einer Liste von Anforderungen.
UX-Wirkung
UI-Entscheidungen ließen sich auf Persona-Bedürfnisse, Risikoszenarien, Prozess-Mapping und Design-Prinzipien zurückführen. Statt pro Screen neu zu verhandeln, gab es wiederverwendbare Regeln — für das neue Modul und für die Modernisierung der bestehenden Plattform.
Fortsetzung des Mandats
Nachdem Tier-1-Banken sich mit der Vision auseinandergesetzt hatten, blieb Beabstracto in einer breiteren UX-Lead-Rolle: von den Fundamenten über die Produktrichtung bis zur MVP-Definition für MiKaDiv, parallel zur Modernisierung der RAQUEST-Plattform.
Was noch nicht gemessen ist
Diese Phase hat Erfolgsindikatoren definiert, keine Ergebnisse gemessen: Zeit bis zum richtigen Report, Zeit bis zur Erkennung blockierender Fehler, Kontextwechsel pro Report, Erfolgsquote der Fehlerbehebung, Durchsatz pro Meldeperiode, Nacharbeit und Support-Bedarf im Onboarding. Sie werden mit den Stakeholdern auf dem Weg in die Umsetzung erhoben.
„Warten Sie … das ist nur ein Prototyp? Ich dachte, das sei ein echtes Produkt.“
Stakeholder einer Tier-1-Bank · in einer Produktdemo des Herstellers
Was wir gelernt haben
Übertragbar auf andere Hersteller regulierter Software — ohne vertrauliche Details.
- 01
Erst die gemeinsame Sprache, dann die Screens
In Organisationen mit viel Fachwissen scheitern UX-Diskussionen selten am Wissen, sondern an Begriffen. Ein Glossar, das Antrag, Claim, Ertrag und Approver eindeutig macht, kostet wenige Stunden und spart Wochen an Missverständnissen zwischen Engineering, Produkt und Geschäftsführung. Alles Weitere — Personas, Prozesse, Prinzipien — baut darauf auf.
- 02
Tensions abstimmen lassen, bevor jemand über ein UI streitet
Sicherheit oder Geschwindigkeit, Führung oder Exploration: In regulierten Systemen sind das Geschäftsentscheidungen. Wer sie als Gegensatzpaare benennt und das Team per Voting entscheiden lässt, bekommt Prinzipien, die niemand mehr pro Screen anzweifelt. Das ist der Unterschied zwischen Meinung und Regel.
- 03
Vom passiven zum informativen System
Der wertvollste Satz des Projekts kam aus der Prozessaufnahme: „Erledige das bis Datum X, weil SLA Y gilt.“ Ein Fachsystem, das Fristen, Blockaden und nächste Schritte zeigt, statt auf die Suche nach Aufgaben zu warten, senkt Schulungsaufwand und Fehlerquote zugleich. Das gilt für jedes Meldeverfahren mit Stichtag.
- 04
Ein Prototyp in Code ist Entscheidungsinfrastruktur
Wenn das Verhalten das Produkt ist — Filter, Zustände, Bulk-Aktionen, Logs —, zeigt ein Klick-Dummy zu wenig. Ein Prototyp in TypeScript mit realistischen Daten lässt Engineering, Geschäftsführung und Interessenten dasselbe Produkt erleben. Er ersetzt keine Umsetzung, aber er ersetzt Monate an abstrakten Anforderungsdiskussionen.
- 05
Messgrößen vor der Umsetzung definieren, keine Ergebnisse behaupten
Eine Strategie- und Prototyp-Phase liefert keine SLA-Quoten. Sie liefert die Indikatoren, mit denen die Umsetzung später bewertet wird: Zeit bis zum Report, Kontextwechsel, Nacharbeit, Support-Bedarf. Wer das vorher festlegt, kann nach dem Go-live ehrlich messen — und muss im Case nichts erfinden.
Was wir geliefert haben
- Glossar und Taxonomie inklusive regulatorischem Mapping (MiKaDiv, BZSt/ELMA, Fristen, SLAs)
- Personas und Kundentypen mit Priorisierung nach Nutzung × Auswirkung
- RACI-artige Berechtigungslogik für rollenbasierte Aktionen und Vier-Augen-Freigaben
- Geschäftsprozess-Cluster und Haupt-Journeys
- Kritische Momente, Fehler-Mapping und Fallback-Logik
- UX-Tensions mit Team-Voting und acht Design-Prinzipien
- Informationsarchitektur mit rollenbasierten Einstiegen
- Erfolgsindikatoren und KPI-Rahmen für die Umsetzungsphase
- User Flows und Interaktionsmuster für Manage Reports
- High-Fidelity-Prototyp in TypeScript (Manage Reports) mit realistischen Daten
- MVP-Referenzflows für das MiKaDiv-Modul
- Design-Richtung für die Modernisierung der bestehenden Plattform
Häufige Fragen
- Arbeiten Sie für den Hersteller oder für uns?
- In diesem Case war Beabstracto externe UX-Beratung für den Hersteller einer Software zur Quellensteuer-Erstattung. Wir sind kein Partner, kein Vertriebskanal und kein Teil des Herstellers. Wenn eine KVG, eine Verwahrstelle oder eine Bank uns beauftragt, arbeiten wir auf Kundenseite — Ist-Analyse, Fachkonzept, Usability-Test, UAT und Einführungsbegleitung — und bleiben gegenüber jedem Hersteller unabhängig.
- Ist RAQUEST ein Produkt von Beabstracto?
- Nein. RAQUEST ist die Software eines eigenständigen Herstellers. Beabstracto wurde für die UX-Führung engagiert; der Name erscheint hier, weil die Arbeit öffentlich dokumentiert ist, nicht weil wir das Produkt vertreten.
- Werden Banken, KVGs oder Kunden des Herstellers genannt?
- Nein. Aus Vertraulichkeit nennen wir keine Bank-, Depotbank- oder Kundennamen, zeigen keine Produkt-Screenshots mit echten Daten und keine internen Produkt-Erkenntnisse jenseits dessen, was im Portfolio veröffentlicht ist. Der Prototyp selbst ist nicht mehr öffentlich zugänglich.
- Gibt es gemessene Ergebnisse?
- Nicht in dieser Phase. Der Case dokumentiert Strategie, Fundamente und Prototyp. Die Erfolgsindikatoren — Zeit bis zum Report, Kontextwechsel, Nacharbeit, SLA-Sichtbarkeit — wurden definiert und werden mit den Stakeholdern auf dem Weg in die Umsetzung erhoben. Zahlen, die wir nicht haben, behaupten wir nicht.
- Warum ein Prototyp in TypeScript und nicht in Figma?
- Weil das Verhalten das Produkt war. Filter über Tausende Meldungen, Ampel-Validierung, Bulk-Freigaben, Übertragungslogs und ein Report-Detail mit zehn Tabs lassen sich in Figma zeigen, aber nicht erleben. Der Code-Prototyp mit realistischen Daten gab Engineering ein konkretes Modell und machte die Vision in Bankgesprächen glaubwürdig.
- Was lässt sich auf eine MiKaDiv-Einführung ab 2027 übertragen?
- Die Methode, nicht die Lösung: gemeinsame Sprache, priorisierte Personas im Fachbereich, Prozessaufnahme Ende-zu-Ende, kritische Momente und Fristen explizit im Interface, ein Kontrollpunkt vor dem Versand. Ob auf Herstellerseite als Modul oder auf Kundenseite als Einführung — die Reihenfolge Datenbasis, Prozess, Oberfläche bleibt dieselbe.
Ein neues Reporting-Modul, das der Fachbereich ohne lange Schulung bedienen soll?
Wir sprechen mit Herstellern von Banking- und Steuer-Software über Glossar, Personas, Prinzipien und Prototypen — und mit KVGs, Verwahrstellen und Banken über die Einführung auf Kundenseite.
Erstgespräch vereinbaren