Industrial Operations Platform

On-site Workshops

Since the product supported highly specialized industrial workflows, understanding the environment was essential before making any design decisions. The primary reason for traveling to Germany was to observe how teams actually worked and uncover the processes behind their daily operations.

Over approximately ten days, I participated in a series of workshops with delivery managers, marketing leadership, engineers, operators, and employees responsible for different stages of the production process. Rather than gathering everyone in a single room, each workshop focused on a specific domain and the people who knew it best.

Most sessions were spent listening, asking questions, and documenting how work was actually performed. Instead of discussing interface ideas, we explored existing processes, responsibilities, and the tools teams relied on every day.

One of the most interesting discoveries was how fragmented the workflow had become. There wasn't a single platform supporting the entire operation. Instead, each team relied on its own combination of tools and processes. Project timelines were tracked manually in Excel, meetings were coordinated through Google Meet, and much of the operational knowledge existed only within individual departments or spreadsheets.

Understanding how these disconnected pieces worked together became essential before defining what the future platform should look like.

To capture these findings, I documented observations, organized notes, and gradually translated complex discussions into workflow diagrams using Miro.

Shadowing Users

Workshops helped me understand the structure of the organization, but seeing the environment firsthand revealed a completely different perspective.

During my time at the factory, I visited multiple departments—including engineering, delivery, warehouse operations, and production—to understand how work happened in practice. Rather than silently observing employees, I was guided through the environment by a delivery manager who explained each process, the responsibilities behind it, and the reasoning behind many of the decisions that weren't immediately visible.

One of the biggest surprises was how different reality was from my initial expectations. Before visiting the factory, I imagined highly automated environments where robots performed most of the work independently. Instead, I discovered that many workflows still relied heavily on manual coordination, human expertise, and collaboration between different teams.

Throughout these sessions, I documented observations and continuously asked questions—not only about pain points, but also about the parts of the process people considered essential and would never want to change.

Perhaps the most valuable insight wasn't technical at all. It was understanding the working culture, communication patterns, and relationships between teams—things that no documentation could fully capture but had a direct impact on how the future product needed to support their work.

Interviews

While workshops helped establish a broader understanding of the organization, interviews focused on the people behind each workflow.

Most sessions were held with a small number of participants—typically managers responsible for larger operational areas or individual employees with deep knowledge of a specific process. Rather than following a predefined script from the beginning, the interview structure evolved naturally. As recurring patterns emerged, the conversations became increasingly structured and focused.

Beyond understanding daily responsibilities and the tools each team relied on, I was particularly interested in two questions:

What slows you down every day? What would you never want to change?

The second question often proved just as valuable as the first. Even when processes appeared fragmented or outdated, many teams had developed effective working habits over the years. The goal wasn't to replace those workflows—it was to preserve what already worked while removing unnecessary friction.

For example, several teams relied heavily on Excel to track project progress. Rather than redesigning the workflow from scratch, the platform kept the familiar structure while simplifying status management, automatically notifying relevant people about updates, and eliminating the need to repeatedly open and check spreadsheets for changes.

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 developed its own effective way of working, adapting familiar tools like Excel, shared documents, and spreadsheets to fit highly specialized processes. Rather than replacing these workflows, the real opportunity was to unify them within a single platform, preserving what already worked while improving accessibility, collaboration, and visibility across teams. Most importantly, these insights only became possible by experiencing the environment firsthand—something that would have been difficult, if not impossible, to understand through documentation alone.

User Roles

The platform was designed to support multiple user roles within a single system, each with different responsibilities and levels of access. While everyone worked in the same environment, the information and actions available to them depended on their role.

Some users primarily consumed information, such as reviewing tasks or documentation, while others were responsible for managing projects, coordinating teams, and overseeing multiple workflows simultaneously. This permission-based structure allowed the platform to present only the information relevant to each user without compromising the overall consistency of the experience.

One of the key design considerations was balancing simplicity for everyday users with the flexibility required by project leaders, who interacted with a much broader set of features and information.

Process Mapping

Once the research phase was complete, the next challenge was transforming a large collection of observations into a structured system.

Together with the people who would eventually use the platform, we began mapping workflows in Miro. Rather than documenting individual tasks immediately, we first identified the major operational areas of the platform. Each area was then broken down into its own workflows, and finally into the detailed actions required to complete specific processes.

Not every workflow served the same purpose. Some were centered around task execution, while others focused on monitoring ongoing operations. Although users could perform additional actions within each workflow, every section was designed around a primary objective, helping maintain clarity without limiting flexibility.

This hierarchical approach made it easier to understand how individual processes related to the broader system and provided a solid foundation before moving into interface design.

System Architecture

As the workflows became more defined, we began rethinking how access should be structured across the platform.

One of the primary goals was to expose users only to the information and actions relevant to their responsibilities. However, this proved more challenging than simply assigning permissions. Many workflows were interconnected, and in some cases a user needed access to a small part of a process that technically belonged to a much larger workflow.

Finding the right balance required close collaboration between design, engineering, and product leadership. Instead of granting unnecessary permissions, we explored alternative solutions that kept the experience focused while still supporting real operational needs.

In situations where users could view information but weren't allowed to modify it, the interface communicated these limitations through disabled states accompanied by clear explanations. This reduced ambiguity while preserving awareness of how different parts of the system connected.

Pain Points

During the discovery phase, a consistent pattern emerged. The challenge wasn't that individual tools were ineffective—it was that the overall process relied on disconnected systems and manual coordination.

Some of the most significant pain points included:

Fragmented information. Critical project data was spread across spreadsheets, emails, Google Docs, and other tools, making it difficult to maintain a single source of truth. Manual workflow management. Progress was tracked manually. Completing one stage of a project often required someone to update spreadsheets before the next step could continue. No shared planning environment. Teams lacked a centralized calendar, making coordination and visibility across projects more difficult. Manual timeline planning. Project schedules were calculated by hand, increasing the effort required to plan and adjust delivery timelines.

None of these issues were particularly complex in isolation. Together, however, they created a workflow that depended heavily on manual effort, constant communication, and repetitive administrative tasks.

Design Principles

Every design decision was guided by a simple objective: help people complete their work faster while making project progress easier to monitor. Rather than introducing new ways of working, the platform was designed to strengthen the workflows that already proved effective in practice.

Several principles shaped the product throughout the project:

Faster task completion

Task-oriented workflows were optimized to reduce unnecessary steps, helping users complete repetitive actions with as few interactions as possible.

Clear progress visibility

Monitoring-focused areas prioritized project status and visibility over task execution, allowing users to quickly understand progress, identify bottlenecks, and track ongoing work.

Preserve familiar workflows

One of the most important discoveries during research was that many existing processes already worked well. Instead of redesigning them from scratch, the goal was to preserve familiar mental models while removing the friction caused by disconnected tools and manual coordination.

Consistency across the platform

Consistency wasn't treated as a branding exercise - it was essential for usability. Many employees worked across multiple areas of the platform every day, so common interactions, such as uploading documents or completing similar actions, needed to behave consistently regardless of where they appeared.

From Workflows to Interfaces

Rather than designing isolated screens, we started with the product's core workflow—the complete lifecycle of a project, from creation to delivery. A project represented a real manufacturing order, bringing together everything required to execute it, including timelines, tasks, meetings, documentation, monitoring, and collaboration.

Starting with this central workflow allowed us to establish the foundation of the platform before expanding into supporting areas. Navigation was designed in parallel, ensuring that the growing product remained easy to navigate as new modules were introduced.

Every workflow followed the same iterative process. We first mapped the complete flow in Miro, including the edge cases we could identify at the time. These flows were then reviewed together with the people who would eventually use the platform, allowing us to validate assumptions and refine the process before moving into interface design.

Once a workflow was agreed upon, I translated it into low-fidelity wireframes. At this stage the focus wasn't visual design—it was validating whether the proposed experience actually supported the intended workflow, uncovering additional edge cases, and refining interactions before investing time in high-fidelity UI.

Only after the workflow had been validated did we move into interface design, using a design system that was being developed alongside the product.

Creating a Shared Design Language

Since the platform was built entirely from scratch, there was no existing design system to build upon. The only available foundation was the company's brand guidelines, which defined its visual identity through colors, typography, and overall tone. Because the product was intended for internal use rather than public distribution, my focus wasn't on translating the brand into a visually expressive interface. Instead, the priority was creating a consistent experience across a large ecosystem of interconnected modules.

From the beginning, it was clear that consistency would become one of the biggest challenges. The platform served multiple departments, each with its own workflows and operational requirements, while many users regularly moved between different areas of the product. As a result, the design system became much more than a collection of reusable UI components—it established a shared interaction language. Common actions such as uploading documents, changing statuses, navigating tables, or interacting with disabled functionality needed to behave consistently regardless of where they appeared, allowing users to rely on familiar patterns instead of relearning interactions.

At the same time, consistency didn't mean forcing every scenario into a single universal component. As the product evolved, it became clear that some components would become unnecessarily complex if they attempted to support every department's needs. In these cases, I deliberately created specialized components based on their context of use rather than their visual appearance—for example, separate table components for engineering and production teams. Although visually similar, they supported different workflows while remaining consistent in behavior and interaction.

One of the more unique challenges involved iconography. Many concepts used throughout the platform were highly specific to the manufacturing domain and simply didn't exist in any existing icon library. Instead of adapting generic icons, I worked closely with engineers and domain experts to understand the meaning behind each concept before designing a custom icon set tailored specifically to the product. This ensured that the interface communicated technical concepts accurately while remaining intuitive for the people who relied on it every day.

Ultimately, the design system wasn't created simply to accelerate interface design. It provided the structure needed for the product to grow without becoming fragmented, ensuring that every new feature felt like a natural extension of the same platform rather than an isolated solution.

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.