Zwilling Labs
Internship @ IIT Bombay
My Role
Worked as the sole UX designer (intern) in a tech team
Team
1 Full Stack developer
UX Designer (Me)
Deliverables
High-fidelity dashboard designs, Design system, Branding, Website Redesign
Timeline
3 months (June 2024- Oct 2024)
// What is a digital twin?
Digital Twin
/डिजिटल ट्विन/
noun
1. A virtual representation of a physical object, system, or process that updates in real time using sensor data, enabling monitoring, simulation, and optimization.
“The factory used a digital twin to track machine performance and predict failures before they happened.”
Similar:
SCADA
IIoT
Cyber-Physical System
// About the company
Zwilling Labs is building a digital twin platform for the manufacturing sector — helping factories visualize machine data, monitor processes in real-time, and identify inefficiencies before they turn into bottlenecks. Their goal is to bring more transparency and control to shopfloor operations through IoT-powered dashboards.
// Process followed
// My responsibilities and context
I joined the team at an early stage, when there was no design groundwork in place — no screens, no flows, and no clear visual language. As the sole designer of the team, I was responsible for creating the entire platform and related interfaces from scratch. I worked across multiple modules, designing interfaces for plant overviews, shopfloor layouts, machine health diagnostics, and user management tools all in just 3 months.
My role was to take this technical, backend-heavy product and shape it into a usable platform. I worked closely with engineers and domain experts to understand the system’s complexity and translate it into a structure that made sense to real users. It was less about adding polish, and more about building clarity.
The digital twin market in manufacturing is experiencing rapid growth, driven by Industry 4.0, IoT integration, and the need for operational efficiency. The global digital twin market was valued at over $10 billion in 2023, with the manufacturing sector contributing a significant share. It is expected to reach $73.5 billion by 2030, growing at a CAGR of 38–40%.
Target Users : Zwilling Labs focuses on mid-to large-scale manufacturers looking to modernize their operations with digital monitoring, analytics, and role-specific dashboards.
Competitor Landscape : PTC ThingWorx, Siemens Mindsphere, and GE Digital's Predix are dominant players offering digital twin solutions, though they often require heavy customizations and long onboarding times.
Differentiation : Zwilling Labs differentiates by focusing on:
Faster setup with modular, pre-configured dashboards
A clean, role-specific interface focused on usability
Built-in access control system for stakeholder management
// Understanding the industry and its structure
The process began with an in-depth exploration of the manufacturing unit’s structure, workflows, and pain points faced by different stakeholders. This foundational research helped set the direction for a hierarchical, user-centric platform that accurately represents real-world operations while optimizing usability for each role.
This analysis helped understand access control to various views within the platform across stakeholders. (eg. Organization admin can access data across board - from high level insights to machine details, whereas a machine operator’s view would be limited to accessing the machine data)
// Understanding the people
To start making sense of it all, I needed to understand who we were building for and what their everyday problems looked like. Who are the users? Here’s a glimpse of the people we were designing for:
// Key considerations before kickstarting
// Setting up information hierarchy
Designing a hierarchical information architecture for the Digital Twin dashboard was key to mirroring the real-world structure of a manufacturing unit (the platform needed to reflect the way different users interacted with data) from organization to plant, shopfloor, and machine levels.
By implementing a clear and accessible top navigation, we gave users instant context and control—letting them jump between high-level overviews and detailed machine data with ease.
It wasn't just about clean UI—it was about respecting the mental model of how operations are managed, reducing cognitive load, and helping every user find the right information, faster.
// Testing initial concepts
With the IA in place, wireframing was approached from broad to specific. Plant and Shopfloor dashboards focused on operational performance and machine efficiency comparisons. Machine dashboard displayed real-time metrics like uptime, downtime, and cycle time.
Paper wireframing
Instead of jumping straight into digital tools, most of the initial wireframing was done on paper—and for good reason. Early ideas weren’t locked in too soon—sketching allowed for divergent thinking before committing to a specific direction.
Paper wireframes made it easier for non-designers (like developers and stakeholders) to engage and give feedback without feeling overwhelmed by design details. Changes could be made instantly—just cross something out and sketch a new version!
// Iterative approach
Constant iteration of the initial dashboard designs played a key role in helping us reach the final version faster. Feedback was gathered through quick reviews, async comments, and live discussions, which helped surface usability issues, technical constraints, and alignment gaps early on.
Shopfloor details dashboard
The shopfloor details dashboard provides a comprehensive visual overview of the entire manufacturing floor. By integrating live sensor data with CAD/CAM models, it allows users to monitor operations in real-time. It includes an events log section which helps identify bottlenecks, inefficiencies, or potential issues within the shop floor.
We realized users often needed to trace back recent events (like breakdowns or parameter overrides) to understand machine behavior. This led to the creation of the Events Log, a timestamped, categorized record of machine activities.
Between 2nd & 3rd iteration, branding, color palette and styles were finalized and I started implementing the styles to the designs to help stakeholders visualize the final outcomes better.
final solution - shopfloor dashboard
Role-based Navigation
It is a dynamic top navigation system that adapts based on the user’s role and permissions.
Real-Time Data Pop-Overs (Sticky)
Interactive pop-over system that anchors live data directly onto machines and rooms within the shopfloor view.
Visual Analytics for Shopfloor Performance
These visualizations helps supervisors quickly compare and identify performance gaps.
Events log table
Timestamped events table that captures every action, alert, and update across shopfloor.
Machine details dashboard
The machine details dashboard allows users to monitor the performance and status of individual machines in real-time. This level of detail ensures that any anomalies or issues can be detected and addressed immediately, minimizing downtime and preventing potential failures.
Through internal reviews and discussions with developers and stakeholders, it became clear that data like axis load was rarely acted upon by operators or managers in day-to-day decision-making. While technically rich, we soon realized that not all data was equally useful to every user.
final solution - machine dashboard
features of machine dashboard
Top Summary Bar
A persistent KPI strip at the top of the dashboard displays key machine-level metrics.
Runtime
This visual breakdowns of how the machine’s time is spent—running, idle, off; important to understand machine utilization
Feed Gauge Chart
This gauge visual tracks live spindle speed and any manual feed overrides made by operators.
Machine State Timeline
Offers a linear timeline minute-by-minute, allowing users to spot unexpected downtimes.
processes & orders dashboard
The Processes Dashboard provides real-time tracking of various stages in the manufacturing workflow, from the assembly of individual components to final production. By visualizing each step, it ensures transparency and efficiency in monitoring progress, identifying bottlenecks, and optimizing operations.
final solution - Processes dashboard
While the Processes Dashboard gave a high-level view of process performance and bottlenecks, it didn’t provide insights into how individual orders were progressing through each stage of production.
The Orders Dashboard was introduced after the Processes Dashboard to address a growing need for more granular, order-specific visibility.
In essence, the Orders Dashboard evolved as a natural next step, building on the insights from the Processes Dashboard but zooming in on individual journeys, offering a more operationally actionable and stage-aware view.
Production Rate: Line Graph
Helps to spot dips or spikes in performance, correlate changes with factors like shift transitions or machine adjustments.
Process Path: Circular Sankey Diagram
Maps the flow of materials or products across different process stages, visually highlighting how product travels.
Updates: Vertically Stacked Timeline
Dynamically flags bottlenecks based on deviations in the product rate and avoid snowballing issues.
Downtime Bar Graph
Aggregates downtime duration per process, gives a clear picture of which stages cause the most delay.
Cumulative & Stage-wise Timeline Views
allows users to switch between a cumulative timeline and a stage-wise breakdown
Detailed Stage View per Order
detailed stage-wise breakdown for each step in the process including attached parts.
// Empty states
// Design System
The Twin Design System is a modular, scalable design framework built to power Zwilling Labs' digital twin platform. It includes a library of responsive UI components, data visualization styles, and role-based layouts tailored for complex manufacturing environments.
Twin ensures that every dashboard—from operator to admin—is easy to use, data-driven, and easy to navigate across web and industrial touch interfaces.
// Key learnings
Stakeholders Need to See Color in Context
Placing colors into actual UI layouts made it easier for them to see why high-contrast combinations were necessary.
Color Should Support Functionality
Early iterations helped determine that some colors impacted readability (e.g., the lighter blue being too weak for primary elements).
Testing Color in Low-Fidelity Saves Time in High-Fidelity
Without early testing, colors might not work well in real UI scenarios, forcing costly revisions later.
Less is More When It Comes to Technical Data
Trimming unnecessary machine stats (like axis load) led to a cleaner, more focused UI
// What I could’ve done better
Used Grid Systems More Rigorously
A stronger use of grid systems could’ve improved structure and scalability across screens.
Set Clearer Documentation Standards
Given more time, documentation could’ve been made more robust with better dev hand-off.
More Thoughtful Use of Color
At some places the use of color could be more intentional, eg. the side navbar.
fin.
Next project
