From the shop floor to the interface: from steam turbines to UX for expert systems
Before I designed interfaces, I built tools for engineers who had no time to learn software. Those years still shape how Beabstracto works.
Starting point
In 2016 I started at Siemens in Brazil — not as a designer, but as an apprentice in the Formare project with the Fundação Siemens. My 2017 final thesis was about photovoltaic modules at the Jundiaí I site. It was about technology, measurements, things that have to work.
Then came the internship in industrial engineering for steam turbines. A steam turbine is not a product you build in one sprint: manufacturing, assembly and commissioning stretch over months, and every step hangs on documents, routines and systems that other people set up years ago.
What happened
In 2019 our team reached the semi-final of the Werner von Siemens Award — with a project on 3D printing in steam-turbine manufacturing. What stayed with me was less the technology than the experience of carrying an idea through a large organisation: who has to be convinced, which processes stand in the way, what does a plant need to actually use something new?
Until 2021 I was an application engineer: technical proposals for steam-turbine generators, small Python tools for the team, automation of recurring SAP processes. That is where I first built software for colleagues who had no time to learn software. They wanted to get their work done.
The lesson was uncomfortable: a tool that is technically correct but does not fit the daily routine gets bypassed. Not out of spite — out of necessity. The Excel list next to the system does not appear because people love Excel, but because the system owes them an answer: where is my case, whose turn is it, when is the deadline?
In 2021 I switched sides: from engineering to product design. izz.ai, then DocuWare — workflow designer and enterprise configuration for a mature B2B platform — Flexera, and today UX lead for a German withholding-tax reclaim platform, as an external UX consultancy for the vendor.
What we make of it for clients
Beabstracto works by three rules, all of which come from the factory.
- Process before screen. Before we touch an interface, we want to know the case: intake, check, approval, deadline, exception. The interface is the consequence, not the start.
- Take domain language seriously. Engineers, tax specialists and clerks have terms that are precise. We do not translate them into marketing speak, we build them into the system.
- Rollout is part of the design. A system nobody adopts is not finished. That is why we support the rollout — key users, training, rework — instead of stopping at the prototype.
The sentence that sums it up is on our About page: I know technical users from the inside, because I was one.
If this applies to your team in concrete terms, a first conversation is worthwhile. We look at where you stand today and what it takes for the system to carry.
Book a first conversationFrequently asked questions
- Why does an engineering background help with UX for expert systems?
- Because the hurdle in expert systems is rarely the visual layer but the process behind it. Someone who has worked inside such processes spots faster where a system hides status, deadline or next step.
- What does “process before screen” mean in practice?
- As-is analysis and observation first: we watch how the work runs today, including the workarounds. Only then do concept and interface emerge.
- Does Beabstracto also support the rollout?
- Yes. Implementation support is a service of its own: key-user concept, training and feedback loops after go-live.
