Is this possible without rebuilding everything?

Yes — and usually that is the better route. We work with a target architecture and a migration path: first clarify how the product should be structured, then the core workflows as flows and concepts, then implement in the order that development and existing customers can sustain. A complete rebuild is an option, not a prerequisite.

Do you work with our engineering team?

Yes, that is the normal case. On this project we worked with the manufacturer's stakeholders and developers and handed over concepts, interaction patterns and UX documentation in a form development can build from. We do not program the software ourselves, but we review interim builds so nothing gets lost in implementation.

How do you deal with our domain terms and experienced users?

We keep them. The terminology and the way expert users work are requirements, not obstacles. What gets modernised is structure, sequence and presentation; whatever is needed in the domain stays complete. Experienced users should recognise their work in the new product and reach their goal faster, not have to relearn it.

How long does a modernisation like this take?

This engagement ran from December 2024 to June 2025 and covered architecture, flows, high-fidelity concepts, design system direction and design leadership. The duration depends on the functional scope of the existing software and on how much implementation support is wanted. After an initial consultation we give a realistic range.

Can you also lead or complement our own designers?

Yes. On this project we guided and reviewed the work of a further designer and held the product direction across people. We work as lead within the manufacturer's team, as a studio, or as a single role — including via staffing intermediaries.

Industry · Legacy software for industrial furnaces · Dec 2024 – Jun 2025

A grown industrial software product restructured — without losing the depth of the domain.

For Ebner Industrieofenbau we led the modernisation of a legacy software product for expert users as UX/Product Design Lead: product and information architecture first, then user flows, high-fidelity concepts and the direction for a design system. The outcome is a set of implementation-ready concepts in which experienced users recognise their work — not an interface that merely looks newer.

Book an initial consultation How we approached it

Client: Ebner Industrieofenbau, Leonding (Austria)
Industry: Industrial furnaces · heat treatment of metals
Role: UX/Product Design Lead — external, as Beabstracto
Period: December 2024 – June 2025
Systems: Figma — confirm]]
Team: The manufacturer's stakeholders and developers; one further designer whose work we led and reviewed

In short

Ebner Industrieofenbau, a manufacturer of industrial furnaces for the heat treatment of metals based in Leonding (Austria), runs a specialised software product for technical expert users that has grown over many years. From December 2024 to June 2025, Beabstracto led the modernisation of this legacy software as UX/Product Design Lead: product architecture, information architecture and user flows for complex operational workflows, high-fidelity concepts, interaction patterns and the direction for a design system — plus the design leadership of a further designer. The result is a set of implementation-ready concepts that are clearer and more consistent without losing the domain depth, the terminology and the way the users work.

For machine and plant manufacturers this is the typical starting point: the software is technically right but hard to overview, and a rebuild that ignores its users would be expensive and risky for existing customers. This case shows how modernisation works when structure comes before screens and the users' expert knowledge is treated as a requirement, not an obstacle.

Starting point

Where did the product stand? With a software product that carries the domain and has grown alongside the plants for years — and was hard to modernise for exactly that reason.

Ebner Industrieofenbau builds industrial furnaces for the heat treatment of metals. This software is a B2B product for experts: whoever works with it knows the process, the terminology and the consequences of a wrong entry.

The users are not casual users. They are specialists with experience on the plant and in the process, for whom the software is a working tool, not an experience.

The software had grown over years. Functions were added where they were needed; the structure emerged from history, not from a design. For experienced users that worked, because they knew where things were. For the manufacturer it became harder: every new function raised the question of where it belongs, the interface differed depending on when a part had been built, and a modernisation could not simply mean "new design over old structure".

More than looks was at stake. A modernisation that misses the expectations of expert users costs trust with exactly the customers who operate the plants. So the brief to Beabstracto was not "redraw the screens" but: define the direction of the modernisation, clarify the structure of the product, deliver high-fidelity concepts, contribute to the product architecture, lead the design system work — and guide and review the work of a further designer on the project.

The problem

What was the problem? Not missing functions, but a structure you had to memorise instead of see — and the risk of losing, in the modernisation, exactly what makes the software valuable to experts.

Structure from history, not from design
The product had grown wherever a need arose. There was no explicit answer to which areas, objects and terms the product is built on. Experienced users compensated with habit; for new colleagues and for every new function, the place where it belongs was missing.
Operational workflows with friction
Complex operational workflows cut across the product. Users reached their goal, but via paths that assumed prior knowledge. Every step that only works with experience is a hurdle during onboarding and a source of error under time pressure.
Inconsistent interface
The same things looked different in different places because they had been built at different times. For users this means relearning, at every spot, how the product reacts. For development it means no reusable vocabulary — every component an individual decision.
Modernisation as a risk to expert knowledge
Every modernisation carries the temptation to simplify. For expert users who need the depth, a "tidied-up" interface without their terms and edge cases is not an improvement but a loss. The real question was how a modern structure and domain completeness fit together.
The direction had to become tangible
Stakeholders and development needed more than principles and rough sketches to decide on the modernisation and to build it. A direction that only exists in documents does not get implemented in day-to-day project work — it gets debated.
Two designers, one product direction
With a further designer on the project, quality and consistency had to be maintained across people without every review becoming a bottleneck. That calls for clear rules, not just taste.

How we approached it

How did we proceed? Structure first, screens second — and in close alignment with stakeholders, developers and the second designer on the project from the start.

1
Understanding the domain and the existing product
We began not with a design but by listening: how does heat treatment work, which terms do the specialists use, which workflows does the existing software cover, and what do experienced users expect from it? To do this we worked with stakeholders and developers and went through the existing software systematically.
2
Clarifying the product architecture
Before any interface was drawn, we defined with the team how the product should be structured: which areas exist, which objects and terms they carry, and how complex operational workflows find their place within them. This is the step modernisations skip most often — and the one that decides whether new functions later have a home or get bolted on again.
3
Information architecture and user flows
Building on the architecture, we worked out the information structures and the user flows for the core operational tasks: where a workflow starts, which information the user needs at which step, where decisions fall, where the edge cases lie. The goal was for users to orient themselves more clearly and complete their tasks with less friction — using the same domain terms as before.
4
High-fidelity concepts
We worked the modernisation direction out as detailed high-fidelity concepts, so that stakeholders and development could decide on a tangible product rather than on principles. The concepts showed how a modern structure and domain depth go together, and served development as the reference for implementation.
5
Interaction patterns and design system direction
In parallel we distilled recurring interaction patterns and laid the foundations for a design system: components, states and rules that work the same way across the whole product. This gives the interface consistency and the development team a vocabulary it can reuse without asking back. As orientation we drew on the principles of ISA-101 and VDI/VDE 3699 for operator interfaces in process control and on the Nielsen Norman Group's work on complex applications — as a reference for good practice, not as a certificate.
6
Design leadership, reviews and handover
We guided and reviewed the work of a further designer on the project so that quality, consistency and product direction stayed the same across people.

Outcome

What came out of it? A restructured product experience with clear flows, consistent patterns and implementation-ready concepts. We judge the outcome by what stakeholders and development were able to do with it; we have no usage metrics from operation, so we quote none.

Aspect	Before	After
Product structure	Grown from history; you had to know where things were	Explicit product and information architecture with clear areas, objects and terms
Operational workflows	Via paths that assumed prior knowledge	Defined user flows for the core tasks; decisions and edge cases visible
Interface	Inconsistent, depending on when a part was built	Recurring interaction patterns and foundations for a design system
Domain terms and depth	Present, but at risk in every modernisation	Deliberately preserved; structure and presentation were modernised, not the domain content
Basis for decisions	Principles, individual opinions, rough sketches	High-fidelity concepts that stakeholders and development could decide on concretely

Architecture before interface
The product now has an explicit structure that was defined before the interface work. New functions have a place they belong to, and the interface follows the structure rather than the other way round.
Clearer, more consistent workflows for expert users
The core operational workflows are defined as user flows, using the domain terms the users know. Orientation and consistency improved without reducing domain depth — which was the actual condition of the project.
Direction for a design system
Reusable patterns and the foundations of a design system give the product a shared language and make future extensions more consistent and less costly.
Design leadership on the project
The work of a further designer was led and reviewed, so quality and product direction stayed the same throughout the project — a role Beabstracto also takes on in larger teams.

What we learned

01
Structure first, screens second
The most valuable step was not the new design but the answer to how the product should be structured. Starting a legacy modernisation with screens means modernising the surface of a structure nobody designed. Starting with the architecture yields screens that explain themselves, and a place for everything still to come.
02
Domain terms are not legacy baggage, they are the interface
The temptation to make terms "more understandable" is strong in expert products — and almost always wrong. The terminology is the language in which users, service and engineering work together. Modernisation means structuring that language cleanly and presenting it consistently, not replacing it.
03
Modernising does not mean simplifying
For expert users, depth is not a complexity problem but the reason they use the tool. The right question is not "What can we leave out?" but "What has to be visible at which step so the decision is made safely?". Less friction comes from better sequence and clearer states, not from less function.
04
High fidelity early makes direction negotiable
Principles produce agreement, but no decision. Only when the modernisation direction lay on the table as a detailed concept could stakeholders and development say concretely what fits and what does not. That costs more effort early and saves the debates that bring projects to a halt later.
05
Design leadership means rules, not taste
A second designer on a project is a gain when consistency does not depend on reviews but on shared patterns. The design system foundations were therefore not just a product artefact but also the tool that let two people work in one direction.

What we delivered

Product architecture
Information architecture
User flows for core operational workflows
High-fidelity concepts
Interaction patterns
Design system direction
Design reviews
UX documentation
Implementation-ready concepts for development

Frequently asked questions

Is this possible without rebuilding everything?: Yes — and usually that is the better route. We work with a target architecture and a migration path: first clarify how the product should be structured, then the core workflows as flows and concepts, then implement in the order that development and existing customers can sustain. A complete rebuild is an option, not a prerequisite.
Do you work with our engineering team?: Yes, that is the normal case. On this project we worked with the manufacturer's stakeholders and developers and handed over concepts, interaction patterns and UX documentation in a form development can build from. We do not program the software ourselves, but we review interim builds so nothing gets lost in implementation.
How do you deal with our domain terms and experienced users?: We keep them. The terminology and the way expert users work are requirements, not obstacles. What gets modernised is structure, sequence and presentation; whatever is needed in the domain stays complete. Experienced users should recognise their work in the new product and reach their goal faster, not have to relearn it.
How long does a modernisation like this take?: This engagement ran from December 2024 to June 2025 and covered architecture, flows, high-fidelity concepts, design system direction and design leadership. The duration depends on the functional scope of the existing software and on how much implementation support is wanted. After an initial consultation we give a realistic range.
Can you also lead or complement our own designers?: Yes. On this project we guided and reviewed the work of a further designer and held the product direction across people. We work as lead within the manufacturer's team, as a studio, or as a single role — including via staffing intermediaries.