From Figma to Implementation at CADS GmbH: Engineering UI components that surgeons can trust

Why this session matters

In “From Figma to Implementation,” Julian Zauner of CADS GmbH offers a grounded, engineering-first look at how a UI design becomes a reliable, feel-right component in the high-stakes world of surgical planning software. At DevJobs.at, we listened for the connective tissue between design intent, implementation details, and the practical realities customers face in the operating room or clinic.

CADS builds 3D imaging and planning software: MRI/CT data is presented to surgeons to plan procedures before they operate. Zauner develops 2D and 3D features, helps maintain a UI component lab, and works hands-on across design fidelity, implementation constraints, and the day-to-day expectations of clinical users.

The core chain: Designer → Developer → Customer

Zauner frames the journey from UI mockups to production around three links:

• Designer
• Developer
• Customer (as the final link)

Friction emerges wherever information, intent, or constraints are lost between these links. The job is to close those gaps: bring design language to life in code, expose behavioral nuances, and ensure the end user experiences clarity, feedback, and speed where it matters.

Affordances and design language: When the UI tells you what it does

Zauner anchors the discussion in the concept of “affordance,” referencing Don Norman’s “The Design of Everyday Things.” A good interface element signals, without instruction, what it is and how to use it. Consider the humble toggle:

• A circular handle sitting within a track silently communicates “this moves left/right.”
• An active color (in one CADS design set, red; in another, blue) communicates “on/active.”
• This semantics is learned not through tooltips but through repetition and consistency across the application – a design language users internalize.

Affordance reduces mental friction. But it’s not the whole story. Between Figma and an actual application live the crucial details of state transitions, micro-feedback, and performance constraints.

From mockup to feel: Why 200 ms of motion can beat “instant”

Zauner demonstrates several toggle implementations, each adding a layer of feedback:

1) Instant switch: Tapping flips state immediately. It works and is fast, but lacks perceptible feedback.

2) Animated movement (~200 ms): A short, fluid motion confirms “something is happening.” Despite taking longer in theory, it often feels snappier, because the visual behavior matches the mental model of cause and effect.

3) Movement plus color animation: Blending the color transition with the positional animation adds a subtle layer that many users can’t name but can feel. A slowed-down demo makes the under-the-hood changes visible; at normal speed, it just “feels right.”

Customers responded enthusiastically. And then came the pragmatic question: How far do you take it? As Zauner notes, “It looks good in two hours, and great in three days.” Project management must choose where on that curve to land. In short: invest where the polish pays off most; don’t gold-plate every component.

Guardrails for the toggle case

• Feedback is non-negotiable: Users need visible, tactile confirmation.
• Pick a time constant: 200 ms is a sensible starting point; the critical part is consistency across the system.
• Color conveys meaning: If red (or blue) equals “active,” keep it consistent everywhere.
• Respect performance budgets: Motion is valuable, but not at the cost of responsiveness on weak machines.

Context menus and persistence: Behavior is part of the design

A second example reveals how subtle behavior can diverge from static mocks: the context menu. At first glance it’s straightforward: press a button, a list appears, one item is highlighted to indicate the current selection, and the button shows an active state in the design’s active color.

But the real questions are behavioral:

• What happens when you click the currently selected item? A reasonable default: close the menu and return the button to its inactive state.
• What if you want to perform multiple actions in sequence (e.g., toggle several checkboxes from the same menu)? In that case the menu should remain open – it’s persistent.

How do you signal that persistence so it doesn’t conflict with learned expectations of “transient” menus? Zauner suggests a few cues:

• Add a frame or more panel-like styling
• Use a subtle drop shadow that brings the menu visually above the canvas
• Optionally add a close icon in the top-right corner

The point is that static design artifacts capture “how it should look,” while implementation clarifies “how it behaves.” Only together do users form a correct mental model.

Two frameworks, one language: Qt Quick/C++ on desktop, Angular on the web

CADS maintains two UI component libraries:

• Desktop (Windows/Linux): C++ with Qt Quick
• Browser: Angular-based component library

Both implement the same design language, but the underlying platforms differ significantly:

• Some interactions are trivial on the web (existing components, CSS transitions) yet require bespoke work in Qt Quick – and vice versa.
• Performance profiles aren’t the same:
• Desktop applications run on powerful machines with GPUs; more sophisticated effects are viable.
• Many web clients in clinics run on old PCs; heavy animations and costly UI logic can feel sluggish.

The upshot: You can’t always implement a UI identically across platforms. Keep the semantics and design language consistent, then adapt implementation details to the strengths and limits of each stack.

Complex UI states: Making background work visible without blocking flow

3D imaging brings computationally heavy operations. The UX challenge: show progress without freezing the app.

• Full-screen blocking progress bars are undesirable.
• Prefer subtle indicators that signal “we’re working on it” without derailing the task.
• Sometimes you have precise percentages; sometimes you don’t. The design must match what the underlying algorithm can report.

If design promises feedback the system can’t deliver, the interaction quickly feels broken. Engineering and design need to align on what “busy” truly means and how to show it.

The cure for friction: Talk early, iterate often

Zauner’s remedy is straightforward: involve everyone who matters, keep the loop tight, and show variants. One-and-done handoffs rarely work in practice.

The toggle story is emblematic: a functional version shipped, a developer invested two extra hours into animation, and the component suddenly felt right. Customers noticed immediately. These micro-upgrades shape the overall perception of quality.

Shared language: Consistency your brain expects

Zauner calls it a “shared language.” We’d describe it as the non-negotiable grammar of your design system:

• Active means active: If the active color is red or blue, apply it everywhere – buttons, toggles, menus.
• Match time constants: If 200 ms is the chosen duration for similar state changes, keep it consistent.
• Normalize state semantics: Hover, focus, active, disabled – define them clearly and implement them uniformly.

Design education covers this by default; engineering teams don’t always do the same. That’s why cross-functional discussion is critical: developers must internalize design intent to implement the right behavior.

A pragmatic checklist for teams (based on the session)

• Define context:
• Which platform are you targeting (Qt Quick desktop vs. Angular web)?
• What are the performance constraints (old clinic PCs vs. workstation with GPU)?
• Nail the semantics:
• What color means “on/active,” and where must it appear?
• Which states exist (hover/focus/active/disabled), and what does each look like?
• Unify animation:
• Choose standard durations (e.g., 200 ms) and curves per transition type.
• Decide which properties animate (position, color, opacity).
• Specify behavior, not just visuals:
• For menus: is it transient or persistent?
• How do you visualize persistence (frame, shadow, close icon)?
• What happens when clicking the currently selected item?
• Plan for asynchrony:
• What progress signals are available (percentages, spinner, “working” indicator)?
• Where should they appear to avoid blocking core flow?
• Keep platform parity realistic:
• What must remain visually consistent (design language)?
• Where is divergence acceptable (performance, framework limitations)?
• Close the loop with customers:
• Show variants early and often.
• Make explicit trade-offs: “good in two hours” vs. “great in three days.”

What stood out to us

• Affordance is not just aesthetics; it’s the psychology that guides correct action.
• Perceived speed can beat raw speed: 200 ms of purposeful motion can feel faster than an instant jump.
• Behavior is design: Persistent menus need visual reinforcement, or they’ll fight with expectations formed elsewhere.
• Same language, different stacks: Qt Quick/C++ and Angular require different approaches; the design language is the invariant.
• Asynchrony is a UX concern: Feedback must reflect what the algorithm can truthfully tell us.
• Agility is real when you show variants, invite feedback, and invest in consistency that users can feel.

Standing on shoulders: Literature that still holds up

Zauner tips his hat to Don Norman’s “The Design of Everyday Things,” noting its age and continued relevance. The talk shows how those principles land in a medical setting: toggles, menus, and progress indicators shape trust and flow. In such environments, small decisions about color, motion, and state communicate safety and control.

Actionable moves for engineering teams

• Establish a binding design language (colors, states, animations) and make it consumable in both worlds (Qt Quick/C++ and Angular).
• Prioritize perceptual quality: small, consistent animations and color transitions that reinforce meaning.
• Specify behavior as thoroughly as visuals: include edge cases such as clicking the currently selected menu item.
• Budget for the web’s weakest machines: reduce effect complexity, and test on old clinic PCs.
• Use agile loops to validate micro-decisions: a “minor” 200 ms choice can meaningfully shift user perception.
• Build bridges between design and dev: shared reviews, common vocabulary, and short feedback cycles.

Closing

“From Figma to Implementation” with Julian Zauner (CADS GmbH) is a precise demonstration that UX quality is forged in details – and those details only come together when designers, developers, and customers work in tight orbit. A toggle, a context menu, a progress hint: when affordance, semantics, and behavior align, interactions feel “right” – which is exactly what you want when your users are planning surgery.

• 

  

  Data Oriented Design

  Florian Putz von CADS zeigt in seinem devjobs.at TechTalk, wie trotz großer Datenmengen mithilfe von Data Oriented Design doch schnelle Performance von Software erreicht werden kann.

  Watch now
• 

  

  Building Products with Purpose

  Lukas Reinauer von CADS spricht in seinem devjobs.at TechTalk wie das Unternehmen das Thema der Produktentwicklung organisatorisch angeht.

  Watch now

• 

  

  Dominic Koch, Product Manager bei CADS

  Product Manager bei CADS Dominic Koch erzählt im Interview über die Abläufe im Unternehmen, was Neueinsteiger erwartet und mit welchen Technologien gearbeitet wird.

  Watch now
• 

  

  Lukas Windner, Division Manager Quality Engineering bei CADS

  Division Manager Quality Engineering bei CADS Lukas Windner gibt im Interview einen Überblick über das Recruiting sowie Onboarding und spricht über den Aufbau der Teams und mit welchen Technologien gearbeitet wird.

  Watch now

• 

  

  Katharina Freinschlag, 3D Software Entwicklerin bei CADS

  Katharina Freinschlag von CADS spricht im Interview über ihren Weg zur Software Entwicklung, welche Challenges im 3D Development gibt und was ihrer Meinung nach Wichtig für Beginner ist.

  Watch now
• 

  

  Claudia Wittner, Researcher bei CADS

  Claudia Wittner von CADS redet in ihrem Interview über die ersten Berührungspunkte mit dem Programmieren bis hin zur aktuellen Arbeit, wie ihr Alltag als Researcher aussieht und gibt Tipps für Anfänger.

  Watch now