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. A lot of how Beabstracto works today comes from those years.
Starting point
In 2016 I started at Siemens in Brazil 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: measurements and technology that has to work.
Then came the internship in industrial engineering for steam turbines. Manufacturing, assembly and commissioning of a steam turbine stretch over months, and every step depends 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, and what does a plant need before it actually uses something new?
Until 2021 I was an application engineer. I wrote technical proposals for steam-turbine generators, built small Python tools for the team and automated recurring SAP processes. That is where I first built software for colleagues who had no time to learn software, because they wanted to get their actual work done.
I learned there that people bypass a tool that is technically correct but does not fit their daily routine, and they do it out of necessity. The Excel list next to the system appears because the system owes them an answer: where is my case, whose turn is it, when is the deadline?
In 2021 I moved from engineering to product design. First izz.ai, then DocuWare (workflow designer and enterprise configuration for a mature B2B platform), then Flexera. Today I lead UX 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, and all of them 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 follows from that.
- Take domain language seriously. Engineers, tax specialists and clerks work with precise terms. We build those terms into the system instead of translating them into marketing speak.
- Rollout is part of the design. A system nobody adopts is not finished, so we support the rollout with key users, training and rework instead of stopping at the prototype.
Our About page puts it in one sentence: I know technical users from the inside, because I was one.
Frequently asked questions
- Why does an engineering background help with UX for expert systems?
- In expert systems the hurdle is usually the process behind the screen. 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 come first. We watch how the work runs today, including the workarounds, and only then develop concept and interface.
- 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.
