SYNCPILOT — Digitale Beratung

5,5 Jahre Product Design für ein B2B-Ökosystem, das persönliche Beratung und rechtsverbindliche Vertragsabschlüsse ins Digitale bringt.

Kontext: Festanstellung als Product Designerin bei der SYNCPILOT Group (Augsburg) · Branche: B2B-SaaS für Public, Energy, Health, Insurance und weitere · Meine Arbeit: UX, UI und Konzeption über mehrere zusammenhängende Produkte · Tools: Figma, FigJam, Adobe XD

Hinweis zur Vertraulichkeit und zur Darstellung: Die hier genannten Produkte und ihr Zusammenspiel sind vom Unternehmen öffentlich dokumentiert, interne Details und echte Oberflächen nicht. Diese Case Study bleibt deshalb auf der Ebene von Konzept, Vorgehen und Entscheidungslogik und nennt keine Betriebskennzahlen.

Wichtig für das Verständnis der Abbildungen: Der beschriebene Beratungs- und Abschlussprozess verteilt sich in der Realität auf mehrere eigenständige Produkte. Es gibt kein einzelnes Produkt, das ihn von Anfang bis Ende in einer Oberfläche abbildet. Alle gezeigten Oberflächen sind Darstellungen, die ich eigens für diese Case Study entworfen habe, um den Prozess in einem Bild erzählen zu können, ergänzt um einen fiktiven Kunden („Stadtwerke Musterstadt"). Sie geben weder eine reale Produktoberfläche wieder noch eine geplante.

Wie schließt man einen Vertrag mit einer Behörde, einem Energieversorger oder einer Krankenkasse ab, ohne vor Ort zu erscheinen, aber trotzdem persönlich beraten und rechtssicher? Genau daran habe ich fast sechs Jahre lang als UI/UX Designerin gearbeitet.

Diese Case Study ist deshalb kein einzelnes Projekt mit Anfang und Ende. Sie zeigt, wie ich in einem gewachsenen Produktökosystem gearbeitet habe: mehrere Produkte, die denselben Prozess an unterschiedlichen Stellen bedienen, zwei sehr verschiedene Nutzergruppen im selben Vorgang und ein regulatorischer Rahmen, der nicht verhandelbar ist. Ich beschreibe hier den roten Faden, an dem ich über die Jahre gearbeitet habe, und die Entscheidungen, die ihn geprägt haben.

Seit 2015 digitalisiert das Unternehmen beratungsintensive Vertragsabschlüsse und Services für Branchen wie Public, Energy, Finance, Healthcare, Insurance, Mobility, Retail, Social Insurance und Telecommunications. Die Kundschaft besteht nicht aus Endverbraucher:innen, sondern aus Organisationen mit den höchsten Anforderungen an Datenschutz und Rechtssicherheit: Ministerien, Kommunen, Energieunternehmen, Krankenkassen und Versicherungen. Das Kernprodukt LIVE CONTRACT ist unter anderem als SAP endorsed app zertifiziert.

Zwei Eigenheiten prägen jede Designentscheidung in diesem Umfeld:

Die zahlende Kundschaft ist nicht die Endnutzerschaft. Entschieden wird im Fachbereich einer Behörde oder eines Versorgers, benutzt wird das Produkt von Berater:innen im Tagesgeschäft und von Bürger:innen, die es genau einmal im Leben sehen. Wer nur auf die Anforderungsliste aus dem Vertrieb hört, baut an dieser zweiten Gruppe vorbei.

Die Software ist mandantenfähig. Dieselbe Oberfläche erscheint im Branding eines Ministeriums, einer Krankenkasse und eines Stadtwerks. Design muss also nicht nur einmal funktionieren, sondern in vielen Farbwelten und mit unterschiedlich langen Fachbegriffen.

Ein Vorgang, der in der physischen Welt aus Gespräch, Papierdokument, Unterschrift und Zahlung besteht, muss digital so ablaufen, dass er sich für beide Seiten sicher und verständlich anfühlt und rechtlich wasserdicht bleibt. Daraus ergeben sich drei Designanforderungen:

Ich habe UX und UI über mehrere Produkte hinweg mitgestaltet und Konzepte für neue Funktionen und Produktideen entwickelt. Der Bogen reichte von grober Architektur und ersten MVP-Richtungen als Grundlage für Konzeptrunden mit Stakeholdern bis zur detaillierten Ausgestaltung einzelner Abläufe, immer in enger Abstimmung mit Entwicklung und Produkt.

Konkret habe ich an diesen öffentlich dokumentierten Produktbereichen gearbeitet:

Live-Beratung (LIVE CONTRACT). Die Echtzeit-Session, in der Berater:in und Kund:in gemeinsam Dokumente ansehen, besprechen und unterschreiben, inklusive Video, Whiteboard-Interaktion und geführtem Prozess bis zum Abschluss.

Asynchrone Vorgänge (SYNCDOX). Ein Aufgaben- und Dokumentenfluss, in dem Berater:innen Aufgaben anlegen (Dokument lesen, hochladen, unterschreiben), die Kund:innen zeitunabhängig erledigen. Vom Prinzip her ein Dokumententool mit digitaler Signatur.

Terminierung (Booking und Scheduling). Das Anlegen von Terminen und Buchungsslots, aus denen heraus Kund:innen buchen und direkt in die passende Beratungs- oder Dokumentenstrecke geleitet werden.

Dazu kamen weitere interne Produktflächen, über die ich hier nichts sagen kann. Für meine Arbeit daran habe ich stets positives Feedback bekommen.

In einem Enterprise-Produkt für den öffentlichen Sektor kann man nicht mal eben zehn Bürger:innen für einen Usability-Test einladen, während sie einen echten Vertrag abschließen. Verlässliches Wissen entsteht hier aus anderen Quellen, und ich habe über die Jahre vor allem aus vier geschöpft.

Die Menschen, die täglich mit den Kund:innen sprechen. Support, Customer Success, Consulting und Vertrieb sind in einem B2B-Haus die beste dauerhafte Forschungsquelle. Ich habe wiederkehrende Rückfragen und Beschwerden gesammelt und nach Aufgaben und Rollen sortiert statt nach Produkt. So wurde sichtbar, welche Stellen im Ablauf immer wieder erklärt werden mussten. Alles, was regelmäßig erklärt werden muss, ist ein Designproblem und keine Schulungsfrage.

Beobachtung echter Abläufe. Vorführungen, Pilotphasen und Abstimmungen mit den Fachbereichen der Kundenorganisationen zeigen, wie Berater:innen tatsächlich arbeiten: mit mehreren offenen Vorgängen, unter Zeitdruck, oft mit einem Telefonat parallel. Diese Beobachtungen haben mehr über die nötige Informationsdichte im Beraterinterface verraten als jede Featureliste.

Der regulatorische Rahmen als Rechercheobjekt. Anforderungen an elektronische Signaturen, Datenschutz und Barrierefreiheit sind in diesem Umfeld keine Nebenbedingung, sondern Ausgangsmaterial. Ich habe sie früh gelesen und in Designkonsequenzen übersetzt, zum Beispiel: Wenn Nachvollziehbarkeit rechtlich gefordert ist, muss der Status eines Vorgangs für beide Seiten sichtbar sein und nicht nur im Log stehen.

Blick nach außen. Videokonferenz- und Signaturwerkzeuge setzen die Erwartungshaltung, die Bürger:innen mitbringen, auch wenn sie fachlich etwas anderes tun. Behördenlösungen wiederum können komplexe Prozesse abbilden, sind aber selten angenehm zu bedienen. Zwischen diesen beiden Polen musste unsere Lösung liegen: die Erwartbarkeit der Consumer-Tools mit der Tiefe der Verwaltungssoftware.

Entscheidung. Der Ablauf wird auf beiden Seiten durch dieselbe Schrittlogik geführt, sichtbar als benannter aktueller Schritt mit dem, was als Nächstes kommt.

Warum. Beide Beteiligten müssen jederzeit dieselbe Antwort auf die Frage „Wo stehen wir gerade?" geben können. Ohne dieses gemeinsame Gerüst moderieren Berater:innen den Ablauf mündlich, und jede Session verläuft anders.

Der Preis. Weniger Freiheit für erfahrene Berater:innen, die gern zwischen Schritten springen. Dafür braucht es bewusste Ausnahmen statt eines offenen Systems.

Entscheidung. Die Beraterseite darf dicht sein, die Kundenseite zeigt pro Moment genau eine Aufgabe.

Warum. Berater:innen nutzen das Werkzeug täglich und gewinnen durch Übersicht. Bürger:innen sehen es einmal und verlieren durch jede zusätzliche Option Sicherheit. Ein einheitliches Interface hätte beide Gruppen benachteiligt.

Der Preis. Zwei Oberflächen mit gemeinsamen Bausteinen, aber unterschiedlicher Logik. Das kostet mehr Pflege und verlangt klare Regeln, welche Komponente wo wie auftritt.

Entscheidung. Der asynchrone Weg über Aufgaben und Dokumente ist ein gleichwertiger Pfad, in den eine Live-Session jederzeit übergehen kann.

Warum. In der Praxis scheitern Abschlüsse selten am Willen, sondern an fehlenden Unterlagen oder Zeit. Wenn ein Vorgang an dieser Stelle abbricht, statt sich in Aufgaben zu verwandeln, beginnt alles von vorn.

Der Preis. Der Zustand eines Vorgangs wird komplexer, weil er über Tage in verschiedenen Stadien liegen kann. Das musste im Beraterdashboard erst sauber darstellbar werden.

Konzepte sind in diesem Umfeld selten beim ersten Entwurf richtig, weil die Rückmeldung aus drei Richtungen gleichzeitig kommt: Fachlichkeit, Technik und Recht. Zwei Beispiele, wie sich Entwürfe dadurch verändert haben.

Vom Kachelraster zur priorisierten Liste. Eine frühe Fassung des Beraterdashboards zeigte alle offenen Vorgänge als gleichwertige Kacheln. Im Gespräch mit Menschen aus der Praxis zeigte sich, dass die eigentliche Frage nicht „Was ist offen?" lautet, sondern „Was ist als Nächstes dran?". Aus dem Raster wurde eine nach Dringlichkeit sortierte Liste, in der Wartende oder auch die zuletzt bearbeiteten Vorgänge immer oben stehen.

Vom festen Videofenster zur flexiblen und kontrollierbaren. In den ersten Fassungen lag das Video der Gegenseite an einer festen Position. Aus dem Feedback der Kundenorganisationen kam ein Muster: In bestimmten Momenten der Beratung stört das Bild, weil es genau die Stelle verdeckt.

Das Gesicht der Gegenseite ist in einer rechtsverbindlichen Situation ein Vertrauensanker. Wer es einmal wegklickt, verhandelt den Rest des Vorgangs mit einer anonymen Oberfläche. Das möchte weder der Berater noch der Kunde.

Das Fenster haben wir deshalb so umgesetzt dass es sich frei auf der Fläche verschieben und bei Bedarf an der Seitenleiste andocken lässt, wo es klein und unaufdringlich präsent bleibt. Die Person verschwindet nie ganz, sie tritt nur zurück.

Warum ich dieses Beispiel hier zeige. Die eigentliche Anforderung war nicht „weg damit", sondern Kontrolle über die eigene Arbeitsfläche. Genau darin liegt in meiner Erfahrung der Unterschied zwischen einer Feature-Anfrage und dem dahinterliegenden Bedürfnis. Wer die Anfrage wörtlich umsetzt, löst das Symptom und verliert nebenbei etwas, das niemand explizit eingefordert hatte.

Aus Sicht der Kund:innen ist das hier ein einziger Vorgang. Aus Sicht der Software sind es mehrere: eine Terminierung, eine Live-Beratungsplattform und ein Dokumentencenter, das sowohl eigenständig als auch als Erweiterung der Beratungsplattform arbeitet. Genau darin lag die eigentliche Aufgabe. Nicht in der Gestaltung einer Oberfläche, sondern in den Übergängen dazwischen.

Vereinfacht und abstrahiert sieht der Ablauf so aus: Ein:e Interessent:in kommt über einen gebuchten Termin oder als spontane Anfrage in einen digitalen Wartebereich. Die Berater:in sieht alle Wartenden in ihrem Dashboard, kennt bei terminierten Fällen den Kontext bereits aus dem Kalender und holt die Person in die Session. Dort läuft der eigentliche Vorgang: Dokumente gemeinsam ansehen, bei Bedarf zahlen, unterschreiben (live oder als asynchron gestellte Aufgabe) und abschließen.

Jeder Sprung zwischen diesen Produkten ist ein Moment, in dem Vertrauen verloren gehen kann: eine neue Oberfläche, ein neuer Link, manchmal ein neuer Absender im Postfach. Für die Kund:innenseite unsichtbar zu machen, dass hier mehrere Systeme zusammenarbeiten, war eine der wiederkehrenden Fragestellungen meiner Arbeit.

Damit mehrere Produkte wie eines wirken können, brauchen sie dieselben Bausteine. Ich habe dafür das Design System aufgebaut, das alle Produkte gemeinsam nutzen: Komponenten, Muster und die Regeln dazu, wann welches Element eingesetzt wird.

Es hat zwei Dinge gelöst, die vorher jedes Mal neu verhandelt wurden. Innerhalb des Designteams gab es eine gemeinsame Grundlage, sodass Entwürfe für verschiedene Produkte nicht auseinanderliefen. Und in der Übergabe an die Entwicklung wurde aus Diskussionen über Abstände und Zustände eine Referenz, auf die beide Seiten zeigen konnten. Gerade bei einer mandantenfähigen Anwendung, die im Branding vieler Organisationen erscheint, entscheidet sich genau hier, was variabel sein darf und was nicht.

Mehr dazu in einer eigenen Case Study: SYNCPILOT Design System: ein Fundament für mehrere Produkte

Weil sich ein Ablauf, der über mehrere Produkte läuft, schwer zeigen lässt, habe ich ihn für diese Case Study in einer durchgehenden Oberfläche durchgespielt: eine Session, ein Schrittgerüst, dahinter dieselben fachlichen Stationen. Das ist ausdrücklich meine eigene Darstellung und kein Produkt, weder ein bestehendes noch ein geplantes. Der Nutzen liegt darin, dass sichtbar wird, wovon Kund:innen im Idealfall nichts merken sollen: dass hier mehrere Systeme ineinandergreifen.

Der geradlinige Ablauf ist der seltenere Fall. Ein großer Teil meiner Arbeit lag in den Zuständen daneben: Die Kund:in erscheint nicht zum Termin. Die Verbindung bricht während der Signatur ab. Ein Dokument fehlt. Die Zahlung schlägt fehl. Die Berater:in muss den Vorgang an eine Kollegin übergeben.

Für rechtsverbindliche Prozesse ist das keine Randnotiz, denn jeder dieser Zustände muss für beide Seiten eindeutig, nachvollziehbar und ohne Datenverlust sein. Ich habe diese Fälle systematisch als Zustandsmatrix erfasst, statt sie einzeln im Ticketverlauf zu klären.

Betriebszahlen der Kundenprojekte kann ich nicht nennen. Was ich beschreiben kann, ist die Wirkung im Produkt und im Team.

Neben den Freelance-Projekten in meinem Portfolio steht diese Case Study für eine andere Seite meiner Arbeit: reguliertes Enterprise-Produktdesign im Team, über fünf Jahre und mehrere Produkte hinweg, unter echten Bedingungen mit Datenschutz, Rechtssicherheit und Systemintegrationen wie SAP. Was hier zählt, ist nicht die auffällige Oberfläche, sondern strukturiertes Denken in Systemen, das Ableiten von Entscheidungen aus indirekten Erkenntnisquellen und die Fähigkeit, zwei sehr unterschiedliche Nutzergruppen in einem Prozess zusammenzubringen.

Die Kunst in dieser Art von Software liegt darin, Komplexität unsichtbar zu machen. Wer online eine Ummeldung erledigt oder einen Vertrag abschließt, soll nichts von der Orchestrierung aus Video, Dokumenten, Signatur, Zahlung und Systemintegrationen merken, sondern sich gut geführt fühlen. Fast sechs Jahre an dieser Art von Problem haben mein Gespür dafür geschärft, wie man große, regulierte Systeme menschlich macht. Und sie haben mich gelehrt, dass Vertrauen im Interface fast immer aus denselben zwei Dingen entsteht: sagen, was gerade passiert, und sagen, was als Nächstes kommt.