While at Dreipol in Zurich, I was assigned to a client that brought me closer to home, not only geographically but also in the projects I feel truly drawn to. Due to NDAs, I can’t show current screenshots or reveal specific features, but I’d like to walk you through the process and share what I learned.
The Client – Bachmann Electronics
Bachmann is a textbook example of a “Ländle” company – a hidden champion from Austria's west. It’s a place where meaningful work has a real-world impact. Case in point: Bachmann technology is used in over 70% of all wind turbines worldwide.
From Information Overload to Clarity
When I joined the project, I had no idea what a Fieldbus was. The interface of the existing configuration software (“Solution Center”) felt like an airplane cockpit—powerful, but overwhelming.
Like an airplane cockpit, the software must perform at the highest level. Simplifying the interface must never come at the cost of reducing functionality. The full range of capabilities must remain intact and usable, just easier to access and understand. On the contrary, our goal was to preserve and even extend the software's capabilities by making them more accessible through modernized patterns, clear structure, and consistent interaction design.
Bachmann’s vision is clear: configuring Fieldbus networks shouldn’t require an IT degree. Instead, technicians and machine operators should be empowered to do it, with less training time and lower cognitive load.
Our guiding question:
How might we enable technicians to configure Fieldbus networks—without writing a single line of code?
While at Dreipol in Zurich, I was assigned to a client that brought me closer to home, not only geographically but also in the projects I feel truly drawn to. Due to NDAs, I can’t show current screenshots or reveal specific features, but I’d like to walk you through the process and share what I learned.
The Client – Bachmann Electronics
Bachmann is a textbook example of a “Ländle” company – a hidden champion from Austria's west. It’s a place where meaningful work has a real-world impact. Case in point: Bachmann technology is used in over 70% of all wind turbines worldwide.
From Information Overload to Clarity
When I joined the project, I had no idea what a Fieldbus was. The interface of the existing configuration software (“Solution Center”) felt like an airplane cockpit—powerful, but overwhelming.
Like an airplane cockpit, the software must perform at the highest level. Simplifying the interface must never come at the cost of reducing functionality. The full range of capabilities must remain intact and usable, just easier to access and understand. On the contrary, our goal was to preserve and even extend the software's capabilities by making them more accessible through modernized patterns, clear structure, and consistent interaction design.
Bachmann’s vision is clear: configuring Fieldbus networks shouldn’t require an IT degree. Instead, technicians and machine operators should be empowered to do it, with less training time and lower cognitive load.
Our guiding question:
How might we enable technicians to configure Fieldbus networks—without writing a single line of code?
Module Configurator; Transform abstract hierarchies into a visual, modular interface. The snippet of that screen is from Bachmanns documentation for the Solution center. (Source: bachmann.at)
Understanding Invisible Systems
Together with Dreipol designers and Bachmann engineers, we expanded on the design system already implemented in the Module Configurator.
The next step is to configure complete Fieldbus networks. These networks vary widely—daisy-chain, star, ring, branch, tree—and are combined with different protocols, manufacturers, and module types. In short, they are complex.
To better understand Fieldbus communication, we developed a simple metaphor:
Imagine a Fieldbus network as a train system. The I/O modules are stations. A train on a continuous loop carries sensor data and commands. At each station, it picks up or drops off messages. The controller acts as the dispatcher, defining the speed, route, and what gets loaded or unloaded.
This analogy helped bridge the gap between engineers and designers, build domain knowledge, and shape our shared design vocabulary.
Collaborative Design Workshop – Intense but Effective!
One big leap in the development came when we left our screens and met in person for three consecutive days at the Bachmann headquarters.
We created our three-day workflow inspired by Google’s five-day design sprint. Why three instead of five? Because getting the right people in the same room for five days is rarely feasible.
The key to making up for the two missing days? Intense preparation and thoughtful follow-up!
Collaborative Design Workshop – Intense but Effective!
One big leap in the development came when we left our screens and met in person for three consecutive days at the Bachmann headquarters.
We created our three-day workflow inspired by Google’s five-day design sprint. Why three instead of five? Because getting the right people in the same room for five days is rarely feasible.
The key to making up for the two missing days? Intense preparation and thoughtful follow-up!
The method beeing used is widely know as High Uncertainty x High Impact matrix. (Source: Dave Grey)
User Testing
For one specific critical feature, it took several sprints to understand user needs and craft a truly usable solution. Without user testing, it wouldn’t have been possible.
What to test:
We used the High Uncertainty × High Impact Matrix to prioritize.
Each feature (or "Epic") was broken into user stories and scenarios, then mapped on the uncertainty/impact grid. The stories that ended up in the top-right quadrant (high uncertainty + high impact) were selected for testing.
How to test:
This template shows exemplarily how we prepared and documented each test session.
Prototypes were built directly in Figma—fast, interactive, and reliable.
Testers were recruited and scheduled.
Scenarios and guiding questions were filled out using our Miro template. If the Hypothesis is validated by at least 80%, it passes; otherwise, it goes back to the drawing board.
The outcome? Confidence.
We had the evidence we needed to move into development.
Each test cycle, from setup to analysis, took three weeks. A duration fits with our Scrum sprint cycle.
This screenshot (blurred intentionally) shows the insights we gained from testing with just 5 users and 6 scenarios. Just imagine how AI tools could automate and accelerate this process.
(I’m working on it!)
Reflections
I left the project with sharpened skills across the board—from shaping core concepts and building prototypes to managing Developer handovers. I also had the chance to bridge disciplines and work closely with UX, UI, and engineering experts.
The method beeing used is widely know as High Uncertainty x High Impact matrix. (Source: Dave Grey)
User Testing
For one specific critical feature, it took several sprints to understand user needs and craft a truly usable solution. Without user testing, it wouldn’t have been possible.
What to test:
We used the High Uncertainty × High Impact Matrix to prioritize.
Each feature (or "Epic") was broken into user stories and scenarios, then mapped on the uncertainty/impact grid. The stories that ended up in the top-right quadrant (high uncertainty + high impact) were selected for testing.
How to test:
This template shows exemplarily how we prepared and documented each test session.
Prototypes were built directly in Figma—fast, interactive, and reliable.
Testers were recruited and scheduled.
Scenarios and guiding questions were filled out using our Miro template. If the Hypothesis is validated by at least 80%, it passes; otherwise, it goes back to the drawing board.
The outcome? Confidence.
We had the evidence we needed to move into development.
Each test cycle, from setup to analysis, took three weeks. A duration fits with our Scrum sprint cycle.
This screenshot (blurred intentionally) shows the insights we gained from testing with just 5 users and 6 scenarios. Just imagine how AI tools could automate and accelerate this process.
(I’m working on it!)
Reflections
I left the project with sharpened skills across the board—from shaping core concepts and building prototypes to managing Developer handovers. I also had the chance to bridge disciplines and work closely with UX, UI, and engineering experts.
