War das ein Projekt von Beabstracto?

Nein. Thiago Andrade war von Oktober 2021 bis Februar 2023 bei izz.ai in München als UX/UI Designer fest angestellt. Der Case beschreibt diese Tätigkeit; Beabstracto nimmt daraus Methode und Haltung mit, nicht Kundenbeziehungen oder Produkte.

Welche Produkte oder Kunden werden genannt?

Keine. Kundenprojekte und Produkte von izz.ai bleiben vertraulich. Der Case beschreibt die Art der Arbeit — B2B-SaaS-Oberflächen, Dashboards, KI-gestützte Produktkonzepte —, ohne einzelne Produkte zu nennen oder Screens zu zeigen.

Gibt es belegte Kennzahlen?

Nein. Aus dieser Zeit liegen keine freigegebenen Zahlen zu Nutzung, Umsatz oder Zeitersparnis vor. Wir nennen keine Werte, die wir nicht belegen können; das Ergebnis ist deshalb qualitativ beschrieben.

Was hat SaaS- und KI-Produktdesign mit Fachsystemen in Banking und Industrie zu tun?

Die Situation ist dieselbe: Eine neue Funktion oder ein neues Modul soll schnell zum Nutzer, aber die Anforderungen sind unreif und die Stakeholder haben kein gemeinsames Bild. Flows, Prototypen und eine umsetzungsreife Übergabe lösen das bei einer Kapitalverwaltungsgesellschaft, einem Softwarehersteller oder in einer Leitwarte genauso wie bei einem SaaS-Produkt.

Wie lief die Zusammenarbeit mit der Entwicklung?

Direkt und laufend. Thiago arbeitete mit Entwicklern und Product Ownern an Flows, Verhalten und Zuständen und übergab High-Fidelity-Designs mit Handoff-Dateien und UI-Spezifikationen. Ziel war, dass in kurzen Lieferzyklen niemand Verhalten raten muss.

Für welche Rollen ist dieser Case relevant?

Für Head of Product, Produktmanagement und Projektleitung bei Softwareherstellern, die eine Funktion — oft mit KI — vom Konzept bis zur Übergabe begleitet haben wollen. Und für Vermittler, die einen UX/UI Designer oder Product Designer suchen, der Discovery, Anforderungsklärung und umsetzungsreifes Design in einer Person abdeckt.

SaaS & KI · B2B-Produkte · 2021–2023

Vage Produktideen in nutzbare SaaS-Oberflächen übersetzen — als einziger Designer.

Bei izz.ai in München hat Thiago Andrade von Oktober 2021 bis Februar 2023 als angestellter UX/UI Designer SaaS-Lösungen für KMU und Enterprise-Kunden in Europa gestaltet. Aus unreifen Anforderungen und frühen Produktideen wurden User Flows, High-Fidelity-Prototypen und umsetzungsreife Designs. Dieser Case zeigt, wie das ohne großes Designteam gelingt — und was Beabstracto daraus für seine Kunden mitnimmt.

Erstgespräch vereinbaren Wie wir vorgegangen sind

Kunde: izz.ai (Arbeitgeber, München)
Branche: Digitale Produkte, SaaS und KI-Initiativen für KMU und Enterprise-Kunden in Europa
Rolle: UX/UI Designer in Festanstellung — einziger Designer
Zeitraum: Oktober 2021 – Februar 2023
Systeme: B2B-SaaS-Oberflächen, SaaS-Dashboards, KI-gestützte Produktkonzepte
Team: Gründer, Stakeholder, Product Owner und Entwickler; Design in einer Hand

Kurz gesagt

izz.ai ist ein Münchner Unternehmen, das für verschiedene Kunden digitale Produkte, SaaS-Lösungen und KI-Initiativen entwickelt hat. Thiago Andrade war dort von Oktober 2021 bis Februar 2023 als angestellter UX/UI Designer der einzige Designer. Das Problem: Produktentscheidungen mussten fallen, bevor die Anforderungen reif waren — in einem schnellen, kundennahen Umfeld ohne gewachsene Produktstruktur. Seine Aufgabe war, Geschäftsideen, Kundenbedarfe und Produktkonzepte in nutzbare B2B-SaaS-Oberflächen, interaktive Prototypen und umsetzungsreife Designs zu übersetzen. Ergebnis: Aus vagen Ideen wurden konkrete Oberflächen, Stakeholder konnten am Prototyp entscheiden, Entwickler erhielten Handoff-Dateien und UI-Spezifikationen. Belegte Kennzahlen liegen nicht vor und werden nicht geschätzt.

Für Leser aus Produktmanagement und Fachbereich ist das relevant, weil die Situation vertraut ist: Eine neue Funktion — oft mit KI — soll schnell zum Kunden, aber niemand hat sie bisher in Flows und Bildschirmen durchdacht. Genau diese Übersetzungsarbeit bringt Beabstracto heute in Projekte mit Softwareherstellern, Banken und Industrieunternehmen.

Ausgangslage

Die Ausgangslage war ein kleines, schnelles und kundennahes Produktumfeld, in dem Design nicht auf fertige Anforderungen warten konnte.

izz.ai arbeitete mit unterschiedlichen Kunden an digitalen Produkten, SaaS-Lösungen und KI-getriebenen Initiativen — für kleine und mittlere Unternehmen ebenso wie für Enterprise-Kunden in Europa.

Thiago kam im Oktober 2021 als UX/UI Designer dazu und war in dieser Rolle der zentrale und meist einzige Designer. Es gab kein großes Designteam und keine ausgereifte Produktstruktur, auf die er sich stützen konnte. Design-Entscheidungen, Nutzerflüsse und Oberflächenverhalten lagen in einer Hand — von der ersten Idee bis zur Übergabe an die Entwicklung.

Die Nutzer der entstandenen Oberflächen waren Geschäftsanwender bei den Kunden: Menschen, die mit SaaS-Dashboards und B2B-Oberflächen arbeiten und von einer KI-Funktion vor allem erwarten, dass sie verständlich und im Arbeitsalltag brauchbar ist. Auf der anderen Seite standen Gründer, Stakeholder, Product Owner und Entwickler, die eine Produktrichtung brauchten, mit der sie planen, bauen und verkaufen konnten.

Vor dieser Arbeit lebten Produktideen überwiegend in Gesprächen, Präsentationen und technischen Überlegungen. Was auf dem Spiel stand: Ein Kunde kauft kein Konzept, das er sich nicht vorstellen kann, und ein Entwickler baut nichts Belastbares aus einer Idee, deren Verhalten niemand festgelegt hat. Design musste beides leisten — schnell genug für das Geschäft, strukturiert genug für die Umsetzung.

Das Problem

Das Problem war, dass Produktentscheidungen vor den Anforderungen fielen — und niemand die Lücke zwischen Geschäftsidee und bedienbarer Oberfläche schloss.

Anforderungen nicht reif
Projekte starteten mit einem Ziel, einer Geschäftslogik und viel Offenem. Welche Schritte ein Nutzer wirklich durchläuft, welche Daten er sieht und was im Fehlerfall passiert, war oft nicht definiert, wenn die erste Oberfläche gebraucht wurde.
Kein Designteam im Rücken
Als einziger Designer gab es keine Review-Runde, keine Research-Kollegin und keine ausgereifte Produktstruktur. Jede Entscheidung über Flows, Komponenten und Zustände musste getroffen, begründet und dokumentiert werden — allein.
KI-Fähigkeit ohne Nutzerbild
Bei KI-getriebenen Initiativen lag der Ausgangspunkt bei den technischen Möglichkeiten. Für Endnutzer war offen, was das System tut, was sie eingeben, was zurückkommt und wie weit sie dem Ergebnis trauen können. Ohne diese Übersetzung bleibt eine KI-Funktion ein Punkt auf einer Folie.
Stakeholder ohne gemeinsames Bild
Gründer, Kunden und Product Owner sprachen über dasselbe Produkt und meinten unterschiedliche Dinge. Ohne etwas Greifbares ließ sich weder intern abstimmen noch gegenüber Kunden überzeugend zeigen, wohin das Produkt geht.
Tempo gegen Produktlogik
Die Lieferzyklen waren kurz. Die Gefahr: Oberflächen, die schnell fertig aussehen, aber keine konsistente Logik haben — und Entwickler, die Verhalten raten müssen, weil die Übergabe lückenhaft ist.

Wie wir vorgegangen sind

Vorgegangen ist Thiago so: früh die richtigen Fragen stellen, Unklarheit schnell in Flows und Prototypen sichtbar machen und jede Entscheidung bis zur Übergabe an die Entwicklung tragen. Es war Arbeit in Festanstellung — die Methode ist dieselbe, mit der Beabstracto heute als externer Partner arbeitet.

1
Produkt-Discovery mit Stakeholdern
Jedes Projekt begann im direkten Gespräch mit Gründern, Kunden, Product Ownern und Entwicklern: Was ist das Ziel, welche Einschränkungen gibt es, welche Geschäftslogik steckt dahinter, welches Ergebnis wird erwartet? Weil Zeit knapp war, mussten die Fragen früh und präzise sein. Ergebnis war ein geteiltes Verständnis von Zweck, Zielgruppe und Grenzen — die Grundlage, auf der Anforderungen überhaupt erst geklärt werden konnten.
2
Anforderungen in User Flows übersetzen
Aus dem Gesprochenen wurden User Flows und Wireframes. Dieser Schritt machte Lücken sichtbar: fehlende Zustände, unklare Entscheidungen, Schritte, die niemand bedacht hatte. So wurden Produktanforderungen, Nutzerflüsse und Oberflächenverhalten gemeinsam mit den Stakeholdern geschärft, statt sie erst in der Entwicklung zu entdecken.
3
High-Fidelity-Prototyp als Entscheidungsgrundlage
Für die Abstimmung zählte, was man anfassen kann. Thiago baute interaktive High-Fidelity-Prototypen, mit denen Stakeholder die Produktrichtung verstehen, Annahmen prüfen und Ideen gegenüber Kunden vertreten konnten. Der Prototyp war damit zugleich Validierungs- und Verkaufsinstrument — vor der ersten Zeile Code.
4
KI-Fähigkeiten nutzbar machen
Bei KI-getriebenen Produktkonzepten ging es darum, aufkommende technische Ideen in Oberflächen und Workflows zu übersetzen, die Endnutzer verstehen und denen sie einen Nutzen zuschreiben. Was gibt der Nutzer ein, was liefert das System zurück, wie wird das Ergebnis dargestellt — diese Fragen wurden in Produktkonzepten und Prototypen beantwortet, nicht in Spezifikationen allein.
5
Umsetzungsreife Übergabe
Zum Abschluss wurden Designs, Flows und Spezifikationen für die Entwicklung aufbereitet: High-Fidelity-UI, Handoff-Dateien und UI-Spezifikationen zu Verhalten und Zuständen. Ziel war, dass Entwickler in kurzen Lieferzyklen bauen konnten, ohne Verhalten zu raten — und dass die Produktlogik beim Übergang vom Design in den Code erhalten blieb.
6
Wiederholen über Projekte und Domänen
Dieser Ablauf lief parallel über mehrere Kundenprojekte mit unterschiedlichen Domänen. Der Wechsel zwischen Kontexten zwang zu einer Arbeitsweise, die nicht auf Vorwissen im jeweiligen Fachgebiet baut, sondern auf schnelle Orientierung: Wer nutzt das, was muss am Ende herauskommen, welche Entscheidung blockiert gerade?

Ergebnis

Das Ergebnis war, dass aus vagen Produktideen konkrete SaaS-Oberflächen wurden, über die sich Stakeholder abstimmen und die Entwickler bauen konnten. Zahlen zu Nutzung oder Umsatz liegen aus dieser Zeit nicht belegt vor und werden deshalb nicht genannt.

Aspekt	Vorher	Nachher
Produktidee	Lebte in Gesprächen, Folien und technischen Überlegungen	Als User Flow, Wireframe und High-Fidelity-Oberfläche greifbar
Anforderungen	Unvollständig; Lücken fielen erst in der Entwicklung auf	Lücken wurden in Flows und Prototypen sichtbar und mit Stakeholdern geschlossen
Stakeholder-Abstimmung	Diskussion über Begriffe, jeder mit eigenem Bild	Entscheidung am interaktiven Prototyp
KI-Funktion	Technische Möglichkeit ohne Nutzersicht	Verständlicher Workflow mit klarer Ein- und Ausgabe
Übergabe an Entwicklung	Interpretationsspielraum, Rückfragen in kurzen Zyklen	Handoff-Dateien und UI-Spezifikationen zu Verhalten und Zuständen

Von der vagen Idee zur konkreten Oberfläche
Thiago hat über mehrere Kundenprojekte hinweg Designarbeit in einem schnellen Umfeld geliefert und dabei geholfen, unscharfe Produktideen in konkrete B2B-SaaS-Oberflächen und Dashboards zu verwandeln. Die Oberflächen balancierten Klarheit für Geschäftsanwender, Tempo in der Lieferung und technische Machbarkeit.
Abstimmung durch Prototypen statt durch Meetings
Prototypen und umsetzungsreife Designs gaben Stakeholdern etwas, worüber sie entscheiden konnten. Die Produktrichtung wurde vor der Implementierung festgelegt, nicht währenddessen.
Autonomie als Designer
Ohne großes Designteam entstand eine belastbare Selbstständigkeit: Verantwortung für Flows, Oberflächenverhalten und Übergabe in einer Hand, in direkter Zusammenarbeit mit Gründern, Product Ownern und Entwicklern.
Was dieser Case belegt
Dass Design end-to-end in unklaren Umgebungen verantwortet werden kann, dass Tempo nicht Produktlogik kosten muss und dass sich Geschäftsideen in nutzbare SaaS-Erlebnisse übersetzen lassen — auch wenn KI im Spiel ist.

Was wir gelernt haben

01
Früh fragen schlägt spät korrigieren
Wenn Anforderungen nicht reif sind, ist die wichtigste Designleistung nicht der Bildschirm, sondern die Frage: Wer nutzt das, was muss herauskommen, was passiert im Fehlerfall? Je früher diese Fragen gestellt werden, desto günstiger die Antwort. Bei Beabstracto ist das heute die Ist-Analyse am Anfang jedes Mandats — bei einem Softwarehersteller ebenso wie bei einem Fachbereich in Bank oder Industrie, der ein neues System einführt.
02
Der Prototyp ist das Fachkonzept, das alle lesen
Ein Anforderungsdokument lesen wenige; einen klickbaren Prototyp verstehen alle — Gründer, Product Owner, Fachbereich, Entwicklung. Bei izz.ai hat der Prototyp entschieden und verkauft. In Einführungsprojekten übernimmt er dieselbe Rolle: Der Fachbereich sieht vor dem Go-live, was auf ihn zukommt, und die Entwicklung baut gegen etwas Konkretes.
03
KI ist erst Produkt, wenn der Nutzer weiß, was sie tut
Technische Möglichkeiten werden erst wertvoll, wenn Eingabe, Ausgabe und Verlässlichkeit für den Nutzer verständlich sind. Das gilt für ein junges SaaS-Produkt wie für ein KI-Modul in einem Bank- oder Industriesystem: Ohne diese Übersetzung bleibt die Funktion unbenutzt, egal wie gut das Modell ist.
04
Tempo braucht Struktur, nicht weniger davon
Kurze Lieferzyklen verführen dazu, Spezifikation wegzulassen. Nötig war das Gegenteil: Flows, Zustände und Verhalten so festhalten, dass Entwickler nicht raten. Umsetzungsreife Übergabe ist bei Beabstracto deshalb Teil jedes Prototyps — kein Extra nach dem Design.
05
Ohne großes Team wirksam sein
Als einziger Designer deckt man Rollen ab, die sonst verteilt sind: Discovery, Konzeption, Gestaltung, Übergabe. Für Kunden heißt das: Beabstracto braucht kein eingespieltes Designteam auf der Gegenseite, um Wirkung zu erzielen, und fügt sich in bestehende Produkt- und Projektteams ein, statt eine eigene Struktur zu verlangen.

Was wir geliefert haben

User Flows
Wireframes
High-Fidelity-UI-Designs
Interaktive Prototypen
SaaS-Dashboards
Produktkonzepte für KI-getriebene Initiativen
Design-Handoff-Dateien
UI-Spezifikationen
Präsentationsmaterial für Stakeholder

Häufige Fragen

War das ein Projekt von Beabstracto?: Nein. Thiago Andrade war von Oktober 2021 bis Februar 2023 bei izz.ai in München als UX/UI Designer fest angestellt. Der Case beschreibt diese Tätigkeit; Beabstracto nimmt daraus Methode und Haltung mit, nicht Kundenbeziehungen oder Produkte.
Welche Produkte oder Kunden werden genannt?: Keine. Kundenprojekte und Produkte von izz.ai bleiben vertraulich. Der Case beschreibt die Art der Arbeit — B2B-SaaS-Oberflächen, Dashboards, KI-gestützte Produktkonzepte —, ohne einzelne Produkte zu nennen oder Screens zu zeigen.
Gibt es belegte Kennzahlen?: Nein. Aus dieser Zeit liegen keine freigegebenen Zahlen zu Nutzung, Umsatz oder Zeitersparnis vor. Wir nennen keine Werte, die wir nicht belegen können; das Ergebnis ist deshalb qualitativ beschrieben.
Was hat SaaS- und KI-Produktdesign mit Fachsystemen in Banking und Industrie zu tun?: Die Situation ist dieselbe: Eine neue Funktion oder ein neues Modul soll schnell zum Nutzer, aber die Anforderungen sind unreif und die Stakeholder haben kein gemeinsames Bild. Flows, Prototypen und eine umsetzungsreife Übergabe lösen das bei einer Kapitalverwaltungsgesellschaft, einem Softwarehersteller oder in einer Leitwarte genauso wie bei einem SaaS-Produkt.
Wie lief die Zusammenarbeit mit der Entwicklung?: Direkt und laufend. Thiago arbeitete mit Entwicklern und Product Ownern an Flows, Verhalten und Zuständen und übergab High-Fidelity-Designs mit Handoff-Dateien und UI-Spezifikationen. Ziel war, dass in kurzen Lieferzyklen niemand Verhalten raten muss.
Für welche Rollen ist dieser Case relevant?: Für Head of Product, Produktmanagement und Projektleitung bei Softwareherstellern, die eine Funktion — oft mit KI — vom Konzept bis zur Übergabe begleitet haben wollen. Und für Vermittler, die einen UX/UI Designer oder Product Designer suchen, der Discovery, Anforderungsklärung und umsetzungsreifes Design in einer Person abdeckt.