Context
Unlike consumer products, this platform wasn't built for the public. It was created to support engineers and operators working within EBZ's manufacturing environment, where complex industrial processes shaped every aspect of the product.
With no comparable products or established UX patterns to learn from, the project began not with interface design, but with understanding how the organization worked. Every decision that followed was grounded in research, collaboration, and continuous validation with the people who would ultimately rely on the platform.
About
EBZ develops engineering and automation solutions for complex industrial environments, where projects involve interconnected systems, robotic equipment, and highly specialized operational processes.
The platform was designed as a unified internal workspace that brought together projects, departments, documentation, equipment, and workflows within a single environment. At its core was a node-based workflow builder, allowing users to visualize relationships between different parts of the system instead of navigating disconnected tables and records.
Rather than simply storing information, the product aimed to make a highly complex operational environment easier to understand, manage, and collaborate around.
Challenge
Designing the interface wasn't the hardest part. Understanding the environment was.
Unlike most digital products, this platform had no direct competitors, established UX patterns, or publicly available references. The workflows had evolved internally over many years, involving multiple roles, technical dependencies, and operational knowledge that couldn't be understood through documentation alone.
The challenge was to preserve the depth and accuracy required by experts while making complex systems easier to navigate, monitor, and manage - without changing the workflows people already trusted.
Discovery
Designing the interface wasn't the first step. Understanding how the organization operated was. Before creating a single screen, I immersed myself in the daily workflows of the teams who would eventually use the product.
On-site Research
I spent approximately ten days at EBZ's headquarters in Germany, working closely with delivery managers, engineers, operators, and other domain experts to understand how the organization functioned in practice. Through workshops, interviews, and factory visits, the goal wasn't to discuss interface ideas, but to uncover how work was actually performed, how responsibilities were distributed, and which tools teams relied on every day.
One of the biggest discoveries was that no single platform supported the entire operation. Instead, each department had developed its own combination of spreadsheets, emails, meetings, and internal processes, creating fragmented workflows and limited visibility across teams.
Visiting the factory added an entirely different perspective. Before arriving, I expected highly automated environments where robots performed most of the work independently. Instead, I discovered that successful operations depended just as much on human expertise, collaboration, and manual coordination as they did on automation. Equally valuable were the aspects impossible to capture through documentation alone - working culture, informal communication, and the habits teams had developed over years of experience.
Throughout the research, I continuously asked two questions:
What slows you down every day? and What would you never want to change?
The second question proved just as important as the first. While the supporting tools were fragmented, many of the underlying workflows already worked remarkably well. Rather than redesigning them from scratch, the objective became preserving familiar processes while eliminating unnecessary friction. These findings ultimately became the foundation for the workflow maps and early product structure developed in Miro.
Key Insights
The discovery phase confirmed that the biggest challenge wasn't the complexity of the workflows - it was the fragmentation of the tools supporting them. Each department had already developed effective ways of working, adapting familiar tools such as spreadsheets, emails, and shared documents to fit highly specialized operational needs.
The opportunity wasn't to reinvent those workflows, but to unify them within a single platform while improving visibility, collaboration, and accessibility. Most importantly, these insights were only possible because the research happened inside the real working environment rather than through documentation alone.
Structuring the System
Research provided the understanding, but it still needed to be translated into a coherent product structure. Together with the team, we transformed observations into workflows, defined how different parts of the platform connected, and organized access around real responsibilities rather than technical constraints.
Process Mapping
With a clearer understanding of how the organization operated, we began mapping the platform in Miro. Rather than documenting individual tasks immediately, we first identified the major operational areas before breaking them down into workflows and the detailed actions required to complete each process.
Different users interacted with the platform in different ways. While some primarily reviewed tasks or documentation, others coordinated projects and managed multiple workflows simultaneously. Instead of designing separate experiences, the system adapted to each role by exposing only the information and actions relevant to their responsibilities.
This hierarchical approach helped organize a highly interconnected environment into clear, purpose-driven workflows and established the structure that later guided the interface design.
Structuring Access
As the workflows became more defined, we began organizing how access should be structured across the platform.
The goal wasn't simply to assign permissions, but to reflect real operational responsibilities. Many workflows overlapped, meaning users occasionally needed visibility into processes outside their primary area without receiving unnecessary editing privileges.
Achieving this balance required close collaboration between design, engineering, and product leadership. Where users could view information but not modify it, the interface communicated these limitations through disabled states and contextual explanations, keeping the system understandable while preserving operational clarity.
Design
Once the workflows had been validated, the challenge shifted from understanding the problem to designing the product. Every decision - from information architecture to interaction patterns - was grounded in the research and built around the way people already worked.
Design Principles
Four principles guided the product throughout the project:
Preserve familiar workflows Support existing mental models instead of introducing entirely new ways of working.
Reduce friction Simplify repetitive tasks by minimizing unnecessary steps and interactions.
Improve visibility Make project progress, dependencies, and bottlenecks easier to understand at a glance.
Stay consistent Ensure similar actions behave the same way across every part of the platform.
Designing the Experience
Rather than designing isolated screens, we started with the product's core workflow - the complete lifecycle of a manufacturing project from creation to delivery. Around this foundation, we organized supporting areas such as timelines, meetings, documentation, monitoring, and collaboration.
Every feature followed the same iterative process. Workflows were first mapped in Miro, reviewed with future users, translated into low-fidelity wireframes, and validated before moving into high-fidelity interface design. This allowed us to resolve edge cases early and ensure the interface accurately reflected the way people worked rather than forcing new behaviors.
Building the Design System
Because the platform was built from scratch, the design system evolved alongside the product. Rather than focusing on branding, its primary purpose was to create a consistent interaction language across a growing ecosystem of modules used by different departments.
Consistency didn't mean forcing every scenario into a single component. Where workflows differed significantly, I created specialized components - such as separate table patterns for engineering and production - while keeping interactions familiar across the platform.
The manufacturing domain also introduced concepts that weren't represented in existing icon libraries. Working closely with engineers and domain experts, I designed a custom icon set that accurately reflected technical terminology and became part of the shared visual language.
Ultimately, the design system wasn't just a collection of reusable components. It provided the foundation that allowed the product to scale while remaining coherent and predictable.
Validation
Validation was an iterative process rather than a final checkpoint. The product went through two rounds of prototype testing, feedback collection, and refinement, allowing us to continuously improve both the workflows and the user experience before progressing to the final interface.
Testing with Real Users
Validation began long before high-fidelity interfaces were created. Initial workflows were reviewed directly in Miro, allowing us to validate the overall process before translating it into low-fidelity interactive prototypes in Figma.
Since I was only on-site during the early stages of the project, most usability sessions were conducted remotely with approximately 10–15 participants. Some sessions were held individually, while others took place as collaborative workshops, depending on the workflow being evaluated.
Rather than testing isolated interface elements, the sessions focused on whether users could successfully complete their work. We evaluated how quickly they could perform common tasks compared to the existing process, how easily they could monitor project progress and understand the status of ongoing work, and whether project documentation was easy to locate throughout the workflow.
This iterative approach allowed workflow decisions to be validated before investing time in high-fidelity interface design.
Refining the Experience
While the overall feedback was positive, testing revealed several opportunities for improvement. The biggest challenges appeared in longer workflows, where some users found it difficult to understand their current position in the process and what steps remained to complete their task.
Testing also exposed issues with information hierarchy. In several screens containing large amounts of information, visual emphasis had been placed on elements that users considered less important, making critical information harder to identify. Other areas presented too much content at once, creating unnecessary cognitive load and increasing user frustration.
These findings resulted in multiple design iterations, including clearer workflow guidance, improved information hierarchy, and progressive disclosure of complex content. Rather than changing the underlying workflows, the iterations focused on making them easier to understand and navigate.
Outcome & Reflection
After months of research, collaboration, design, and validation, the platform moved into development and later became part of EBZ's everyday operations. The final outcome not only confirmed many of the decisions made throughout the project but also reinforced a lesson that continues to shape my approach to product design today.
Impact
By the time my design work was complete, the project moved into development, where I continued supporting the team throughout implementation. The platform was fully launched a few months later, and after several months of active use I received feedback from the product team comparing the live product with the results observed during prototype testing.
The overall outcome closely matched the validation phase. The improvements identified during usability testing translated into the final product, while the biggest challenge during rollout wasn't the platform itself, but migrating years of existing documentation, spreadsheets, and operational data into a single environment. Although much of this process was automated, the transition still required significant organizational effort.
Outcomes
The new platform brought together previously fragmented workflows into a single workspace, improving visibility across projects, centralizing knowledge, and making onboarding easier for new employees. Rather than changing how teams worked, it supported familiar processes while removing much of the manual coordination that had previously depended on spreadsheets, emails, and disconnected tools.
Reflection
The most valuable insights didn't come from screens or wireframes - they came from conversations, observations, and mapping the relationships between people, processes, and information.
Working in a domain I had no previous experience with also reinforced an important lesson: good product design isn't about being an expert in every industry. It's about asking the right questions, collaborating with domain experts, and translating complexity into experiences that feel intuitive for the people who use them every day.
Looking back, the biggest achievement wasn't designing a new interface. It was helping improve the everyday work of people operating in a highly specialized environment while preserving the workflows they already trusted.
