Geht das, ohne alles neu zu bauen?

Ja — und meistens ist das der bessere Weg. Wir arbeiten mit einer Zielarchitektur und einem Migrationspfad: zuerst klären, wie das Produkt aufgebaut sein soll, dann die Kernabläufe als Flows und Konzepte, dann in der Reihenfolge umsetzen, die für Entwicklung und Bestandskunden tragbar ist. Ein kompletter Neubau ist eine Option, keine Voraussetzung.

Arbeiten Sie mit unserem Engineering zusammen?

Ja, das ist der Normalfall. Bei diesem Projekt haben wir mit Stakeholdern und Entwicklern des Herstellers gearbeitet und Konzepte, Interaktionsmuster und UX-Dokumentation so übergeben, dass die Entwicklung damit bauen kann. Wir programmieren die Software nicht selbst, reviewen aber Zwischenstände, damit in der Umsetzung nichts verloren geht.

Wie gehen Sie mit unseren Fachbegriffen und erfahrenen Nutzern um?

Wir behalten sie. Die Terminologie und die Arbeitsweise der Fachnutzer sind Anforderungen, keine Hindernisse. Modernisiert werden Struktur, Reihenfolge und Darstellung; was fachlich nötig ist, bleibt vollständig. Erfahrene Nutzer sollen sich im neuen Produkt wiederfinden und schneller zum Ziel kommen, nicht neu lernen müssen.

Wie lange dauert so eine Modernisierung?

Dieses Mandat lief von Dezember 2024 bis Juni 2025 und umfasste Architektur, Flows, High-Fidelity-Konzepte, Design-System-Richtung und Design-Führung. Die Dauer hängt vom Funktionsumfang der bestehenden Software und davon ab, wie viel Umsetzungsbegleitung gewünscht ist. Nach einem Erstgespräch nennen wir einen realistischen Rahmen.

Können Sie auch unsere eigenen Designer führen oder ergänzen?

Ja. In diesem Projekt haben wir die Arbeit eines weiteren Designers angeleitet und reviewt und die Produktrichtung über Personen hinweg gehalten. Wir arbeiten als Lead im Team des Herstellers, als Studio oder als einzelne Rolle — auch über Personaldienstleister.

Industrie · Legacy-Software für Industrieöfen · Dez 2024 – Jun 2025

Eine gewachsene Industriesoftware neu strukturiert — ohne die Tiefe des Fachgebiets zu verlieren.

Für Ebner Industrieofenbau haben wir als UX/Product Design Lead die Modernisierung einer Legacy-Software für Fachnutzer geführt: erst Produkt- und Informationsarchitektur, dann User Flows, High-Fidelity-Konzepte und die Richtung für ein Design-System. Herausgekommen sind umsetzungsreife Konzepte, in denen sich erfahrene Nutzer wiederfinden — statt einer Oberfläche, die nur neuer aussieht.

Erstgespräch vereinbaren Wie wir vorgegangen sind

Kunde: Ebner Industrieofenbau, Leonding (Österreich)
Branche: Industrieofenbau · Wärmebehandlung von Metallen
Rolle: UX/Product Design Lead — extern, als Beabstracto
Zeitraum: Dezember 2024 – Juni 2025
Systeme: B. Figma — bestätigen]]
Team: Stakeholder und Entwickler des Herstellers; ein weiterer Designer, dessen Arbeit wir geführt und reviewt haben

Kurz gesagt

Ebner Industrieofenbau, Hersteller von Industrieöfen für die Wärmebehandlung von Metallen mit Sitz in Leonding (Österreich), betreibt eine über Jahre gewachsene Fachsoftware für technische Expertennutzer. Von Dezember 2024 bis Juni 2025 hat Beabstracto als UX/Product Design Lead die Modernisierung dieser Legacy-Software geführt: Produktarchitektur, Informationsarchitektur und User Flows für komplexe operative Abläufe, High-Fidelity-Konzepte, Interaktionsmuster und die Richtung für ein Design-System — dazu die fachliche Führung eines weiteren Designers. Das Ergebnis sind umsetzungsreife Konzepte, die klarer und konsistenter sind, ohne die fachliche Tiefe, die Terminologie und die Arbeitsweise der Nutzer zu verlieren.

Für Maschinen- und Anlagenbauer ist das die typische Ausgangslage: Die Software ist fachlich richtig, aber schwer zu überblicken, und ein Neubau ohne Rücksicht auf die Nutzer wäre teuer und für Bestandskunden riskant. Dieser Case zeigt, wie Modernisierung gelingt, wenn Struktur vor Screens kommt und das Expertenwissen der Nutzer als Anforderung gilt, nicht als Hindernis.

Ausgangslage

Wo stand das Produkt? Bei einer Software, die fachlich trägt und über Jahre mit den Anlagen gewachsen ist — und genau deshalb schwer zu modernisieren war.

Ebner Industrieofenbau baut Industrieöfen für die Wärmebehandlung von Metallen. Diese Software ist ein B2B-Produkt für Experten: Wer damit arbeitet, kennt den Prozess, die Begriffe und die Konsequenzen einer falschen Eingabe.

Die Nutzer sind keine Gelegenheitsanwender. Es sind Fachleute mit Erfahrung an der Anlage und im Prozess, für die die Software ein Arbeitswerkzeug ist, kein Erlebnis. B. Anlagenbediener, Inbetriebnahme, Service, Prozessingenieure — mit Thiago bestätigen]]

Die Software war über Jahre gewachsen. Funktionen kamen dort hinzu, wo sie gebraucht wurden; die Struktur ergab sich aus der Historie, nicht aus einem Entwurf. Für erfahrene Nutzer funktionierte das, weil sie wussten, wo etwas liegt. Für den Hersteller wurde es schwieriger: Jede neue Funktion warf die Frage auf, wo sie hingehört, die Oberfläche war je nach Entstehungszeit unterschiedlich, und eine Modernisierung konnte nicht einfach „neues Design über alte Struktur“ bedeuten.

Auf dem Spiel stand mehr als Optik. Eine Modernisierung, die die Erwartungen der Fachnutzer verfehlt, kostet Vertrauen bei genau den Kunden, die die Anlagen betreiben. Deshalb lautete der Auftrag an Beabstracto nicht „Screens neu zeichnen“, sondern: die Richtung für die Modernisierung definieren, die Struktur des Produkts klären, High-Fidelity-Konzepte liefern, zur Produktarchitektur beitragen, die Design-System-Arbeit führen — und die Arbeit eines weiteren Designers im Projekt anleiten und reviewen.

Das Problem

Was war das Problem? Nicht fehlende Funktionen, sondern eine Struktur, die man sich merken musste, statt sie zu sehen — und die Gefahr, bei der Modernisierung genau das zu verlieren, was die Software für Experten wertvoll macht.

Struktur aus der Historie, nicht aus dem Entwurf
Das Produkt war dort gewachsen, wo Bedarf entstand. Es gab keine explizite Antwort auf die Frage, welche Bereiche, Objekte und Begriffe das Produkt tragen. Erfahrene Nutzer kompensierten das mit Gewohnheit; für neue Kollegen und für jede neue Funktion fehlte der Ort, an dem sie hingehören.
Operative Abläufe mit Reibung
Komplexe operative Workflows liefen quer durch das Produkt. Nutzer kamen ans Ziel, aber über Wege, die Vorwissen voraussetzten. Jeder Schritt, der nur mit Erfahrung funktioniert, ist eine Hürde in der Einarbeitung und eine Fehlerquelle unter Zeitdruck.
Uneinheitliche Oberfläche
Gleiche Dinge sahen an verschiedenen Stellen unterschiedlich aus, weil sie zu verschiedenen Zeiten entstanden waren. Für Nutzer heißt das, an jeder Stelle neu zu lernen, wie das Produkt reagiert. Für die Entwicklung heißt es: kein wiederverwendbares Vokabular, jede Komponente eine Einzelentscheidung.
Modernisierung als Risiko für Expertenwissen
Jede Modernisierung hat die Versuchung, zu vereinfachen. Für Fachnutzer, die die Tiefe brauchen, ist eine „aufgeräumte“ Oberfläche ohne ihre Begriffe und Sonderfälle keine Verbesserung, sondern ein Verlust. Die eigentliche Frage lautete, wie moderner Aufbau und fachliche Vollständigkeit zusammenpassen.
Richtung musste greifbar werden
Stakeholder und Entwicklung brauchten mehr als Prinzipien und grobe Skizzen, um über die Modernisierung zu entscheiden und sie zu bauen. Eine Richtung, die nur in Dokumenten existiert, wird im Projektalltag nicht umgesetzt — sie wird diskutiert.
Zwei Designer, eine Produktrichtung
Mit einem weiteren Designer im Projekt mussten Qualität und Konsistenz über Personen hinweg gehalten werden, ohne dass jedes Review zum Flaschenhals wird. Das verlangt klare Regeln, nicht nur Geschmack.

Wie wir vorgegangen sind

Wie sind wir vorgegangen? Struktur zuerst, Screens danach — und von Anfang an in enger Abstimmung mit Stakeholdern, Entwicklern und dem zweiten Designer im Projekt.

1
Domäne und Bestand verstehen
Am Anfang stand kein Entwurf, sondern Zuhören: Wie läuft die Wärmebehandlung ab, welche Begriffe benutzen die Fachleute, welche Abläufe bildet die bestehende Software ab, und was erwarten erfahrene Nutzer von ihr? Dafür haben wir mit Stakeholdern und Entwicklern gearbeitet und die bestehende Software systematisch durchgegangen.
2
Produktarchitektur klären
Bevor eine Oberfläche gezeichnet wurde, haben wir mit dem Team definiert, wie das Produkt aufgebaut sein soll: welche Bereiche es gibt, welche Objekte und Begriffe sie tragen und wie komplexe operative Abläufe darin Platz finden. Das ist der Schritt, den Modernisierungen am häufigsten überspringen — und der entscheidet, ob neue Funktionen später einen Ort haben oder wieder angebaut werden.
3
Informationsarchitektur und User Flows
Auf der Architektur aufbauend haben wir die Informationsstrukturen und die User Flows für die operativen Kernaufgaben ausgearbeitet: Wo beginnt ein Ablauf, welche Informationen braucht der Nutzer in welchem Schritt, wo fallen Entscheidungen, wo liegen Sonderfälle. Ziel war, dass sich Nutzer klarer orientieren und ihre Aufgaben mit weniger Reibung abschließen — mit denselben Fachbegriffen wie bisher.
4
High-Fidelity-Konzepte
Die Modernisierungsrichtung haben wir in detaillierten High-Fidelity-Konzepten ausgearbeitet, damit Stakeholder und Entwicklung nicht über Prinzipien, sondern über ein greifbares Produkt entscheiden konnten. Die Konzepte zeigten, wie moderner Aufbau und fachliche Tiefe zusammengehen, und dienten der Entwicklung als Referenz für die Umsetzung.
5
Interaktionsmuster und Design-System-Richtung
Parallel haben wir wiederkehrende Interaktionsmuster herausgearbeitet und die Grundlagen für ein Design-System gelegt: Komponenten, Zustände und Regeln, die über das ganze Produkt gleich funktionieren. Damit bekommt die Oberfläche Konsistenz und das Entwicklungsteam ein Vokabular, das es ohne Rückfrage wiederverwenden kann. Als Orientierung dienten uns die Prinzipien von ISA-101 und VDI/VDE 3699 für Bedienoberflächen in der Prozessführung sowie die Arbeiten der Nielsen Norman Group zu komplexen Anwendungen — als Referenz für gute Praxis, nicht als Zertifikat.
6
Design-Führung, Reviews und Übergabe
Wir haben die Arbeit eines weiteren Designers im Projekt angeleitet und reviewt, damit Qualität, Konsistenz und Produktrichtung über Personen hinweg gleich blieben.

Ergebnis

Was ist dabei herausgekommen? Eine neu strukturierte Produkterfahrung mit klaren Flows, konsistenten Mustern und umsetzungsreifen Konzepten. Wir bewerten das Ergebnis an dem, was Stakeholder und Entwicklung damit anfangen konnten; Nutzungskennzahlen aus dem Betrieb liegen uns nicht vor, deshalb nennen wir keine.

Aspekt	Vorher	Nachher
Produktstruktur	Aus der Historie gewachsen; man musste wissen, wo etwas liegt	Explizite Produkt- und Informationsarchitektur mit klaren Bereichen, Objekten und Begriffen
Operative Abläufe	Über Wege, die Vorwissen voraussetzten	Definierte User Flows für die Kernaufgaben; Entscheidungen und Sonderfälle sichtbar
Oberfläche	Uneinheitlich, je nach Entstehungszeit	Wiederkehrende Interaktionsmuster und Grundlagen für ein Design-System
Fachbegriffe und Tiefe	Vorhanden, aber bei jeder Modernisierung gefährdet	Bewusst erhalten; modernisiert wurden Struktur und Darstellung, nicht der Fachinhalt
Entscheidungsgrundlage	Prinzipien, Einzelmeinungen, grobe Skizzen	High-Fidelity-Konzepte, über die Stakeholder und Entwicklung konkret entscheiden konnten

Architektur vor Oberfläche
Das Produkt hat jetzt eine ausgesprochene Struktur, die vor der Interface-Arbeit definiert wurde. Neue Funktionen haben einen Ort, an den sie gehören, und die Oberfläche folgt der Struktur statt umgekehrt.
Klarere, konsistentere Workflows für Fachnutzer
Die operativen Kernabläufe sind als User Flows definiert, mit den Fachbegriffen, die die Nutzer kennen. Orientierung und Konsistenz haben sich verbessert, ohne dass die fachliche Tiefe reduziert wurde — das war die eigentliche Bedingung des Projekts.
Richtung für ein Design-System
Wiederverwendbare Muster und die Grundlagen eines Design-Systems geben dem Produkt eine gemeinsame Sprache und machen künftige Erweiterungen konsistenter und günstiger.
Design-Führung im Projekt
Die Arbeit eines weiteren Designers wurde geführt und reviewt, sodass Qualität und Produktrichtung über das ganze Projekt gleich blieben — eine Rolle, die Beabstracto auch in größeren Teams übernimmt.

Was wir gelernt haben

01
Struktur zuerst, Screens danach
Der wertvollste Schritt war nicht das neue Design, sondern die Antwort auf die Frage, wie das Produkt aufgebaut sein soll. Wer bei einer Legacy-Software direkt mit Screens beginnt, modernisiert die Oberfläche einer Struktur, die niemand entworfen hat. Wer mit der Architektur beginnt, bekommt Screens, die sich erklären, und einen Ort für alles, was noch kommt.
02
Fachbegriffe sind keine Altlast, sondern Schnittstelle
Die Versuchung, Begriffe „verständlicher“ zu machen, ist bei Expertenprodukten groß — und fast immer falsch. Die Terminologie ist die Sprache, in der Nutzer, Service und Engineering miteinander arbeiten. Modernisierung heißt, diese Sprache sauber zu strukturieren und konsistent darzustellen, nicht sie zu ersetzen.
03
Modernisieren heißt nicht vereinfachen
Für Fachnutzer ist Tiefe kein Komplexitätsproblem, sondern der Grund, warum sie das Werkzeug benutzen. Die richtige Frage ist nicht „Was können wir weglassen?“, sondern „Was muss in welchem Schritt sichtbar sein, damit die Entscheidung sicher fällt?“. Weniger Reibung entsteht durch bessere Reihenfolge und klarere Zustände, nicht durch weniger Funktion.
04
High-Fidelity früh macht Richtung verhandelbar
Prinzipien erzeugen Zustimmung, aber keine Entscheidung. Erst als die Modernisierungsrichtung als detailliertes Konzept auf dem Tisch lag, konnten Stakeholder und Entwicklung konkret sagen, was passt und was nicht. Das kostet früh mehr Aufwand und spart später die Diskussionen, die Projekte zum Stehen bringen.
05
Design-Führung heißt Regeln, nicht Geschmack
Ein zweiter Designer im Projekt ist ein Gewinn, wenn Konsistenz nicht an Reviews hängt, sondern an gemeinsamen Mustern. Die Design-System-Grundlagen waren deshalb nicht nur ein Produktartefakt, sondern auch das Werkzeug, mit dem zwei Personen in einer Richtung arbeiten konnten.

Was wir geliefert haben

Produktarchitektur
Informationsarchitektur
User Flows für operative Kernabläufe
High-Fidelity-Konzepte
Interaktionsmuster
Design-System-Richtung
Design-Reviews
UX-Dokumentation
Umsetzungsreife Konzepte für die Entwicklung

Häufige Fragen

Geht das, ohne alles neu zu bauen?: Ja — und meistens ist das der bessere Weg. Wir arbeiten mit einer Zielarchitektur und einem Migrationspfad: zuerst klären, wie das Produkt aufgebaut sein soll, dann die Kernabläufe als Flows und Konzepte, dann in der Reihenfolge umsetzen, die für Entwicklung und Bestandskunden tragbar ist. Ein kompletter Neubau ist eine Option, keine Voraussetzung.
Arbeiten Sie mit unserem Engineering zusammen?: Ja, das ist der Normalfall. Bei diesem Projekt haben wir mit Stakeholdern und Entwicklern des Herstellers gearbeitet und Konzepte, Interaktionsmuster und UX-Dokumentation so übergeben, dass die Entwicklung damit bauen kann. Wir programmieren die Software nicht selbst, reviewen aber Zwischenstände, damit in der Umsetzung nichts verloren geht.
Wie gehen Sie mit unseren Fachbegriffen und erfahrenen Nutzern um?: Wir behalten sie. Die Terminologie und die Arbeitsweise der Fachnutzer sind Anforderungen, keine Hindernisse. Modernisiert werden Struktur, Reihenfolge und Darstellung; was fachlich nötig ist, bleibt vollständig. Erfahrene Nutzer sollen sich im neuen Produkt wiederfinden und schneller zum Ziel kommen, nicht neu lernen müssen.
Wie lange dauert so eine Modernisierung?: Dieses Mandat lief von Dezember 2024 bis Juni 2025 und umfasste Architektur, Flows, High-Fidelity-Konzepte, Design-System-Richtung und Design-Führung. Die Dauer hängt vom Funktionsumfang der bestehenden Software und davon ab, wie viel Umsetzungsbegleitung gewünscht ist. Nach einem Erstgespräch nennen wir einen realistischen Rahmen.
Können Sie auch unsere eigenen Designer führen oder ergänzen?: Ja. In diesem Projekt haben wir die Arbeit eines weiteren Designers angeleitet und reviewt und die Produktrichtung über Personen hinweg gehalten. Wir arbeiten als Lead im Team des Herstellers, als Studio oder als einzelne Rolle — auch über Personaldienstleister.