CADS GmbH

Etablierte Firma

Alle Videos anzeigen

From Figma to Implementation

Julian Zauner von CADS zeigt in seinem devjobs.at TechTalk welche Überlegungen hinter den grundlegenden Design Elementen in der Software stecken.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In „From Figma to Implementation“ zeigt Julian Zauner (CADS GmbH), wie man die Lücke zwischen Design, Entwicklung und Kunde beim Bau von UI‑Komponenten schließt, basierend auf Affordances und einer konsistenten Designsprache (z. B. aktive Farben). An Demos wie einem Toggle mit 200‑ms‑Bewegungs‑ und Farbanimationen sowie einem Kontextmenü mit unterschiedlich persistierendem Verhalten verdeutlicht er, warum Mikrobewegungen und feedbackreiche Zustandswechsel wichtig sind und wie Plattformgrenzen (Qt Quick/C++ Desktop vs. Angular/Browser, schwache Hardware) die Umsetzung prägen. Praktisch mitnehmbar sind ein iterativer Agile‑Feedback‑Loop mit allen Beteiligten, das Festschreiben einer gemeinsamen Designsprache und das Abwägen von Aufwand, Performance und „Feels right“, um gezielt zu investieren.

Von Figma zur Implementierung bei CADS GmbH: Wie aus UI-Designs robuste Komponenten für Chirurgiesoftware werden

Kontext: Warum diese Session relevant ist

In „From Figma to Implementation“ zeigt Julian Zauner (CADS GmbH) sehr konkret, wie der Weg vom UI-Entwurf zur fertigen Komponente in einer hochsensiblen Domäne funktioniert: chirurgische Planungssoftware. Wir bei DevJobs.at haben besonders genau hingehört, weil hier drei Welten aufeinander treffen, die in der Praxis oft Reibung erzeugen: Design, Entwicklung und echte Nutzerinnen und Nutzer – in diesem Fall Chirurginnen, Chirurgen und Patienten.

CADS entwickelt 3D-Bildgebungssoftware, die Bilddaten aus MRT- und CT-Scans aufbereitet, Planungsschritte ermöglicht und damit Operationsabläufe unterstützt. Zauner arbeitet als aktiver Softwareentwickler an 2D- und 3D-Features, verantwortet eine interne UI-Component-Lab-Initative und bringt damit eine Perspektive mit, die gleichermaßen gestalterisch, technisch und nutzerzentriert ist.

Die zentrale Klammer: Designer → Entwickler → Kunde

Zauner rahmt die gesamte Reise als Dreiklang:

Designerin/Designer
Entwicklerin/Entwickler
Kundin/Kunde (als finales Glied der Kette)

Zwischen diesen Stationen entsteht Reibung. Die Aufgabe besteht darin, diese Lücken gezielt zu überbrücken. Das beginnt bei der klaren Sprache im Design, geht über saubere Implementierung inklusive Zuständen und Interaktionsfeedback und endet bei sichtbarer, spürbarer Qualität im Produkt, die beim Kunden ankommt.

Affordanz und Designsprache: Was gute Komponenten implizit kommunizieren

Ein Kernbegriff der Session ist die „Affordanz“. Angelehnt an Don Norman („The Design of Everyday Things“) beschreibt Zauner, wie gutes Design dem Nutzer nonverbal klar macht, was möglich ist – und was als Nächstes passieren wird. Ein simples Beispiel: der Toggle-Schalter.

Ein runder Griff, der in einer Schiene liegt, signalisiert akut: „Das lässt sich nach links und rechts bewegen.“
Ein aktiver Farbzustand (z. B. Rot oder – in einer anderen CADS-Designvariante – Blau) vermittelt: „Dies ist eingeschaltet/aktiv.“
Diese Semantik wird nicht per Tooltip erklärt, sondern durch konsequente Wiederholung gelernt – eine Designsprache, die sich durch die gesamte Anwendung zieht.

Die Botschaft: Gute Affordanz reduziert kognitive Last. Aber damit ist die Arbeit noch nicht getan. Zwischen Figma-Mockups und laufender Software klafft ein Raum, der sich erst in der Implementierung schließt: Übergänge, Zustandswechsel, Rückmeldungen und Leistungsgrenzen.

Vom Mockup zum Gefühl: Warum 200 ms Animation den Unterschied machen

Zauner führt das am Toggle vor – in mehreren Implementierungsvarianten:

1) Instant-Umschaltung: Der Schalter springt sofort in den neuen Zustand. Funktional korrekt, schnell, aber ohne fühlbare Rückmeldung.

2) Animierte Bewegung (ca. 200 ms): Eine kurze, flüssige Bewegung vermittelt: „Etwas passiert gerade.“ Obwohl die reine Umschaltzeit theoretisch länger ist, fühlt sich die Interaktion „snappier“ an. Nutzer bevorzugen diesen Verlauf oft, weil er ihr mentales Modell bestätigt.

3) Animierte Bewegung + Farbverlauf: Zusätzlich zur Bewegung wird der Farbzustand über die Dauer weich überführt. Zauner zeigt auch eine verlangsamte Variante, um die Wirkung sichtbar zu machen: Es „fühlt sich richtig“ an – ohne dass Nutzer genau beschreiben könnten, warum.

Die Reaktion beim Kunden war eindeutig positiv – und löst zugleich eine realistische Projektfrage aus: Wie viel Animationsfeinschliff ist wirtschaftlich darstellbar? Zauner bringt es auf den Punkt: „Es sieht gut aus nach zwei Stunden – und großartig nach drei Tagen.“ Das Projektmanagement muss also bewusst entscheiden, wann „gut genug“ auch wirklich gut genug ist und wo Premium-Veredelung den Mehrwert rechtfertigt.

Leitplanken für den Toggle-Case

Feedback ist Pflicht: Nutzer brauchen spürbare Rückmeldung auf Eingaben.
Zeitkonstante definieren: 200 ms sind ein plausibler Startpunkt – wichtiger als die exakte Zahl ist die Konsistenz über alle Komponenten hinweg.
Farbe ist Semantik: Die aktive Farbe (in einer CADS-Variante Rot, in einer anderen Blau) muss in der gesamten Designsprache verankert bleiben.
Performance-Ziele mitdenken: Animationen sind wertvoll – aber nicht um jeden Preis. Auf schwächerer Hardware oder im Browser kann „weniger“ die bessere UX sein.

Kontextmenü vs. „persistence“: Verhalten ist Teil des Designs

Ein zweites, nur scheinbar kleines Beispiel macht die Lücke zwischen Entwurf und Nutzung deutlich: das Kontextmenü. Auf den ersten Blick ist alles klar: Ein Button aktiviert ein Menü, eine Liste erscheint, ein Eintrag ist hervorgehoben (aktueller Fokus oder aktuelle Auswahl). Die aktive Farbe des Buttons auf der linken Seite zeigt: „Ich bin an/aktiv.“

Doch die kniffligen Fragen lauern im Verhalten:

Was passiert, wenn ich den bereits ausgewählten Eintrag erneut klicke? – Naheliegend: Menü schließen, Button ist wieder inaktiv.
Was, wenn mehrere Aktionen in Serie aus demselben Menü getätigt werden sollen (z. B. mehrere Checkboxen an/aus)? – Dann sollte das Menü offen bleiben.

Damit sind wir bei der Kernfrage: Wie kommunizieren wir Nutzerinnen und Nutzern, dass dieses Menü „persistent“ ist – also nicht sofort wieder verschwindet? Zauner nennt mehrere visuelle Mittel:

Ein Rahmen oder eine klarere Panel-Optik
Ein sanfter Drop-Shadow, der das Menü „greifbarer“ vor die Fläche holt
Optional ein Close-Icon oben rechts

Wichtig ist, dass diese Entscheidungen nicht isoliert im Figma-Frame, sondern in der laufenden Anwendung validiert werden. Der Entwurf zeigt, „wie es aussehen soll“. Die Implementierung zeigt, „wie es sich verhält“. Erst beides zusammen ergibt eine verständliche Interaktion.

Zwei Welten, eine Designsprache: Qt Quick/C++ auf Desktop, Angular im Browser

CADS pflegt zwei UI-Component-Libraries:

Desktop (Windows/Linux): C++ mit Qt Quick
Browser: Angular-Library

Die Designsprache ist in beiden Welten identisch – die technischen Möglichkeiten jedoch nicht. Und genau dort entsteht Reibung:

Manche UI-Idee ist im Browser leicht (bestehende Komponenten, CSS-Transitions), in Qt Quick aber aufwendiger – oder umgekehrt.
Performance unterscheidet sich stark:
Desktop-Anwendungen bei CADS laufen auf leistungsfähigen Rechnern (GPU verfügbar, starke CPUs). Anspruchsvollere UI-Effekte sind dadurch oft realistisch.
Viele Browser-Clients in Kliniken laufen auf alten PCs. Aufwendige Animationen und rechenintensive UI-Logik fühlen sich dort zäh an – trotz „gleicher“ Designsprache.

Zauners Fazit: Man kann nicht jede UI-Implementierung 1:1 zwischen Frontend und Desktop übertragen. Dort, wo das Look-and-Feel leicht divergiert, muss die Designsprache den Rahmen vorgeben und die Implementierung für die Plattform angepasst werden – ohne die Semantik (Aktivfarben, Zustände, Rückmeldungen) zu brechen.

Komplexe UI-Zustände: Arbeiten im Hintergrund sichtbar machen

Ein drittes Feld betrifft asynchrone, rechenintensive Vorgänge – typisch in der 3D-Bildverarbeitung. Hier stellt sich die Frage: Wie zeigen wir „Es passiert gerade etwas“ – ohne die gesamte Anwendung zu blockieren?

Blockierende Vollbild-Progress-Dialoge sind unerwünscht.
Besser: dezente Indikatoren („Wir arbeiten daran“) – z. B. ein subtiler Fortschritts-Hinweis am Rand.
Nicht immer gibt es eine prozentgenaue Fortschrittsinformation; manchmal ist nur „läuft noch“ verfügbar.

Die Quintessenz: Design und Entwicklung müssen die Semantik von „busy“ gemeinsam ausbuchstabieren – auf Basis dessen, was der Algorithmus tatsächlich liefern kann. Sonst entsteht eine UX, die Erwartungen weckt, die das System nicht erfüllen kann.

Kommunikation ist die Brücke – Iteration ist Pflicht

Zauners Lösungsansatz ist glasklar: Alle relevanten Rollen (Design, Entwicklung, Kunde) müssen laufend miteinander sprechen. Einmalige Übergaben funktionieren nicht. Stattdessen braucht es Varianten, frühes Testen und Feedback-Schleifen – kurz: gelebte Agilität.

„Du musst es ihnen wieder und wieder zeigen. Zeige Varianten.“

Das gezeigte Toggle-Beispiel entstand genau so: Eine Basisversion funktionierte. Ein Entwickler investierte zwei Stunden in Animation – und plötzlich fühlte es sich richtig an. Der Kunde reagierte begeistert. Diese kleinen, spürbaren Verbesserungen zahlen direkt auf Produktwahrnehmung und Vertrauen ein.

Die „Shared Language“: Konsistenz, die das Gehirn erwartet

Zauner spricht von einer „Shared Language“ – im Kern eine definierte Designsprache, die über die gesamte Anwendung konsistent bleibt:

Aktiv ist aktiv: Wenn eine aktive Farbe (z. B. Rot/Blau) etabliert ist, gilt sie überall – Buttons, Toggles, Menüs.
Gleiche Zeitkonstanten: Wenn Quellkomponenten mit 200 ms animiert werden, dann sollte diese Zahl für ähnliche Übergänge im ganzen System gelten.
Gleiche Regeln für Zustände: Hover, Focus, Active, Disabled – die Semantik muss eindeutig sein und überall gleich umgesetzt werden.

Diese Prinzipien sind in der Designausbildung Standard – in der Entwicklung aber nicht automatisch präsent. Deshalb ist Austausch so wichtig: Entwicklerinnen und Entwickler müssen die Intentionslage hinter einem Entwurf verstehen, um sie treffsicher umzusetzen.

Praktische Checkliste für Teams (basierend auf der Session)

Kontext definieren:
Wo läuft die Komponente (Desktop mit Qt Quick vs. Browser mit Angular)?
Welche Leistungsgrenzen gelten (alter Klinik-PC vs. Workstation mit GPU)?
Semantik festlegen:
Welche aktive Farbe steht für „an/aktiv“ – und wo gilt sie überall?
Welche Zustände (Hover/Focus/Active/Disabled) existieren mit welchen sichtbaren Merkmalen?
Animationen vereinheitlichen:
Standard-Dauer (z. B. 200 ms) und Kurven pro Zustandswechsel definieren.
Gilt die Animation auch für Farben? Für Größe? Für Opazität?
Verhalten spezifizieren:
Für jeden UI-Typ (z. B. Kontextmenü): Ist es transient oder persistent?
Wie wird Persistenz visualisiert (Rahmen, Schatten, Close-Icon)?
Was passiert beim Klick auf den aktuell gewählten Eintrag?
Asynchronität planen:
Welche Rückmeldearten sind verfügbar (Prozent, Spinner, „busy“-Hinweis)?
Wo im UI erscheint die Rückmeldung, ohne den Flow zu stören?
Plattform-Parität realistisch halten:
Was muss visuell konsistent sein (Designsprache)?
Wo ist abweichendes Verhalten akzeptabel (Performance, Framework-Grenzen)?
Nutzerfeedback einbauen:
Varianten früh zeigen, kurze Feedbackzyklen etablieren.
Entscheide bewusst: „2 Stunden gut“ vs. „3 Tage großartig“ – und kommuniziere die Trade-offs.

Was wir als Redaktion mitgenommen haben

Affordanz ist mehr als Optik: Sie ist psychologische Stützstruktur für korrekte Interaktion.
„Schneller“ fühlt sich nicht immer schneller an: 200 ms sinnvoller Animation schlagen Instant-Sprünge oft klar in der Wahrnehmung.
Verhalten ist Design: Persistente Menüs brauchen sichtbare Hinweise auf ihre Langlebigkeit – sonst kollidieren sie mit gelernter Erwartung.
Ein System, zwei Frameworks: Qt Quick/C++ und Angular verlangen unterschiedliche technische Wege – die gemeinsame Klammer ist die Designsprache.
Asynchronität ist ein UX-Thema: Rückmeldungen müssen zur realen Algorithmik passen; falsche Präzision ist schlechter als ehrliches „wir arbeiten daran“.
Agil heißt: Varianten zeigen, Nutzer einbinden, konsistent bleiben – und bewusst in „Qualität, die man fühlt“ investieren.

Ausblick: Designliteratur als Fundament, Praxis als Prüfstein

Zauner verweist auf Don Normans „The Design of Everyday Things“ – ein älteres Werk, das in der Produktpraxis bis heute trägt. Die Session zeigt, wie diese Prinzipien in einer medizinischen Anwendung konkret werden: Ein Toggle, ein Menü, eine Ladeanzeige – jede Kleinigkeit ist potenziell sicherheitskritisch, weil sie Entscheidungen und Handgriffe beeinflusst. Gute Software in diesem Umfeld bedeutet, dass die Summe kleiner Richtungen und Rückmeldungen ein Gesamtgefühl von Sicherheit und Kontrolle erzeugt.

Konkrete Handlungsimpulse für Engineering-Teams

Definiere eine verbindliche Designsprache (Farben, Zustände, Animationen) – und mache sie in beiden Welten (Qt Quick/C++ und Angular) anwendbar.
Priorisiere Wahrnehmungsqualität: Animationen und Farbverläufe mit Augenmaß – konsistent, dezent, spürbar.
Beschreibe Verhalten, nicht nur Aussehen: Für Menüs, Dialoge, Toggles, Indikatoren – inklusive Randfälle (z. B. Re-Klick auf aktive Option).
Plane für schwache Hardware im Web: Fallbacks, reduzierte Effekte, Performance-Budgets. Teste realistisch auf älteren Klinikrechnern.
Nutze agile Zyklen, um Mikroentscheidungen zu validieren: Eine „kleine“ 200-ms-Entscheidung kann die Produktwahrnehmung deutlich heben.
Baue Brücken zwischen Design und Entwicklung: Gemeinsame Reviews, geteilte Begriffe, kurze Wege. Intent vor Implementierung.

Schlussgedanke

„From Figma to Implementation“ mit Julian Zauner (CADS GmbH) ist ein Lehrstück darüber, dass UX-Qualität im Detail entsteht – und dass genau diese Details nur im Schulterschluss von Design, Entwicklung und Nutzern gelingen. Ein Toggle, ein Kontextmenü, ein Ladehinweis: Wenn Affordanz, Semantik und Verhalten zusammenfinden, entsteht Interaktion, die sich „richtig“ anfühlt – und in kritischen Anwendungsszenarien den Unterschied macht.

Weitere Tech Talks

Weitere Tech Lead Stories

Weitere Dev Stories