Early discovery involved executives, site directors, performance managers, and operators with limited availability. The product scope was also still evolving which made it difficult to establish requirements through discussion alone. I started with domain immersion before relying on formal user research. Three inputs became essential: access to every relevant reporting artifact, a deep understanding of the manufacturing reality from the full value chain down to specific entities, production lines, KPIs, constraints, and terminology, and analysis of existing dashboards. I first built context around the client’s operating model, manufacturing operations, performance processes, and entity-level specifics by speaking with domain experts across the organization, not only target users. I then deconstructed the reports as operational artifacts, not just documents. Each file was considered a response to a real operational problem, revealing information hierarchy, reporting priorities, decision models, terminology, chart choices, and the mental models behind them. This compressed discovery significantly and made later stakeholder conversations more concrete and productive. Much of this work had to run alongside design and development within the available discovery timeline. It provided essential context, but required continually revisiting assumptions as my understanding of the domain developed.

My initial direction adapted an operations visualizer from earlier work to the manufacturing context. Early feedback showed that the Executive Summary dashboard needed to come first, ahead of the detailed operational modules I had planned to prioritize. The early operational reporting concept later proved broadly appropriate when we returned to the detailed modules, requiring only minor adjustments. At this stage, however, the priority was to understand what stakeholders needed from the Executive Summary.

The operations visualizer from the supply chain platform which informed the initial direction.

The breakthrough came when analysis of existing spreadsheets revealed a reporting logic that stakeholders knew well. Understanding that logic helped me shape the information architecture. The structure reflected the major phases of manufacturing operations and how executives evaluated performance. It became the foundation for the Executive Summary dashboard and influenced the platform’s performance hierarchy. The challenge then shifted to identifying which parts reflected genuine decision-making needs and which were artifacts of Excel and reporting constraints.

The reporting structure extracted from existing reports which shaped the executive summary view

Translating this structure into the dashboard also revealed opportunities to reuse a small set of patterns and components which helped maintain consistency for users and made implementation more manageable despite the amount of information involved. Some secondary details and supporting content still required negotiation later in the project. Having worked with the same development team on previous large-scale platforms, I already had a good understanding of our technical constraints, delivery capacity, and implementation challenges. This made it easier to distinguish between improvements that were critical to the user experience and those that could be simplified or deferred to keep the project moving within its timeline.

The Executive Summary dashboard, with sensitive details obscured and values replaced with illustrative data.

Many dashboard details went through several rounds of iteration, including later in the project as new requirements emerged. The toolbar shown below is one example: its controls evolved to support different benchmarks, reporting periods, views, and data sources, alongside comments, notifications, and export options. As these needs became clearer, I revisited how the controls were grouped, labeled, and displayed to keep the growing set of options understandable without overwhelming the dashboard.

Evolution of the Executive Summary toolbar as reporting requirements emerged.

The Executive Summary dashboard had to support a specific decision model: first determine whether each phase of the manufacturing value chain was performing correctly, then understand the impact of any deviation, and finally trace its origin from high-level operational areas down to specific sites and plants. Achieving this within a single view was challenging given the scale of the operation and the amount of performance data involved.

Collapsed sections highlight key performance signals; expanded sections reveal the operational detail behind deviations within the same dashboard.

Within the expanded view, performance KPIs were represented through hierarchical tables that mirrored the manufacturing structure. Users could progressively move from high-level operational areas to sites and finally plants, allowing them to trace the source of a deviation without leaving the dashboard. To keep the view manageable, only the most impactful contributors were shown at the lowest level by default, while still allowing further exploration when needed. Each row displayed multiple performance dimensions simultaneously, supported by global controls that allowed users to switch benchmarks and reporting perspectives across the entire dashboard.

These tables later became more than reporting components. Site rows evolved into navigation entry points leading directly to detailed reporting pages and contextual discussions related to that site's performance. Because tables became one of the platform's most frequently used interaction patterns, their design received significant attention. Numerical values were monospaced for easier comparison, column widths were designed around real operational edge cases, and top-level summary rows were highlighted with a subtle grey background to improve scanability across dense datasets. I intentionally pushed back against zebra striping because it introduced visual noise and conflicted with hierarchy and state indicators. Instead, hierarchy, spacing, hover states, and semantic highlighting were used to guide attention.

Progressive drilldown from company-level performance to entities and individual sites.

During testing and subsequent client presentations, participants reported being able to assess perforamnce across the manufacturing value chain in just a few seconds. Familiar mental models, consistent structures, clear visual hierarchy, and progresive disclosure helped them identify the most significant deviations and trace their impact through sites and operational entities, all from a single screen.

The executive summary dashboard helped identify deviations but did not explain them. Executives also needed to understand why a particular site or product had underperformed or overperformed, so we needed a new workflow to allow this. Originally, operational teams collected these explanations in separate Excel and PPT files to document events such as line stops, maintenance, experiments, or improvements alongside the relevant performance figures. Bringing this context into the platform became another important design challenge. We initially referred to this feature as "Comments".

The initial comments feed, accessible directly from the global topbar.

My first direction used a notification-style feed accessible from the dashboard, with each entry showing its author, site, product, and operation. Users with the appropriate access could submit an explanation through a composer, specify its context, and categorize it as positive or negative. Stakeholders responded well to accessing these explanations from the dashboard, but some felt the composer was not an effecient input mechanism. On top of this, further requirements sessions revealed that the entries were not independent messages. A single problem could have several action plans, each with its own status and impact. Users needed to document what had happened, what they were doing about it, and how much of the lost production had been recovered. For example, an issue could cause a loss of ten tons, while separate actions recovered different portions of that loss. A flat comment could describe this, but made the relationship between the cause, actions, and their individual contributions difficult to review. The workflow needed to make those relationships explicit.

Early explorations of comment entries, categorization, and filtering

I moved towards a table that brought the operational context, date, impact in tons, cause, action plans, and action status into a shared view. Users could filter entries by product, entity, operation, or date. Creating an entry also became a structured form: users with the appropriate access could specify the context and add multiple action plans with their associated details. Alongside this, we explored a separate notes flow for another group of users who needed to add observations or comment on action plans without documenting a cause or quantified impact. Keeping notes separate avoided forcing every contribution into the same reporting structure. The table and form required more explicit input than the original composer, but better supported how users documented and reviewed operational events. We also removed the search functionality explored in early versions because the volume of entries did not justify the additional scope, and contextual filters were sufficient for finding relevant records.

Operational causes, impacts, and action plans in one shared view (Shown with fictional data).

The new structured form for documenting multiple action plans, their impact, and status.

Moving to this structure also meant letting go of the composer I had spent considerable time refining. It was a reminder that a well-refined interaction can still be built around an incomplete understanding of the workflow.

Iterations of the original composer, later replaced as the workflow became clearer.

I was already familiar with designing for B2B environments, where efficiency, density, and clarity often matter more than the visual qualities associated with consumer UI. The users of this platform were accustomed to spreadsheets, enterprise systems, and operational reporting tools. The visual direction needed to feel familiar and precise while supporting clearer workflows and interactions.

Evolution of the dashboard’s visual design, from early concepts at the top left to the refined direction at the bottom right.

Stakeholders referenced reports and existing tools as examples to follow. Rather than copying their visual language, I focused on understanding the underlying preference: precision, control, familiarity, and information density. The resulting UI used restrained colors, strong numerical hierarchy, clear segmentation, and highly consistent patterns while still following modern UX principles. I used a restrained green palette and a darker neutral green for system actions, with semantic colors reserved for performance and status. This separation supported instant deviation detection without competing meanings.

Selected components from the platform’s shared interface system.

Combined with the dashboard direction described earlier, this approach was one of the first concepts that immediately resonated with stakeholders. While details such as charts, icons, shadows, and navigation treatments continued to evolve through feedback, the overall visual direction remained stable throughout the project.

The initial filter-based approach (top) and the final combination of tabs, product selectors, and local filters (bottom).

One of the earliest architectural challenges I underestimated was how to structure detailed performance reporting. The platform had to support multiple sites, products, dates, and performance dimensions. The question was whether to organize reports into separate pages, distinct views, or a single screen controlled through filters.My initial instinct was to use a conventional reporting screen: a single page with charts and filters for performance type, site, product, date, and additional options. I expected this to minimize navigation and accommodate new reporting needs. However, early validation sessions revealed a flaw. Users frequently jumped between sites and products during performance reviews. Repeatedly opening dropdowns, searching, and selecting created too much friction for a workflow that depended on quick switching. The next attempt relied on a large filtering sidebar containing all controls. While this made them more accessible, the number of sites, plants, products, and other filters made the panel difficult to navigate. More importantly, stakeholders didn’t see sites as filter values. They saw each site as a distinct operational entity with its own products, performance, and operational reality.

An early concept whose site-and-product navigation became the foundation of detailed reporting

The breakthrough came during a validation session where I presented several navigation directions. One organized sites as tabs and product families as chips within each site, revisiting an early operational reporting concept set aside while we prioritized the Executive Summary. Unlike previous concepts that required explanation, this one was immediately understood because it mirrored how users already reviewed performance. Sites became the primary navigation layer, while product families became a secondary layer within each site’s context. Even then, new challenges emerged. Some sites represented groups of multiple sub-sites, while some product families contained dozens of products. Showing everything as tabs and chips became unmanageable. The compromise was to introduce expandable site tabs and limit chips to major product families. Detailed plant and product selection remained available through a local filtering sidebar, while global controls at the top applied across the reporting view. The filter's sidepanel itself remained controversial because it consumed valuable screen width that could otherwise be used by charts. but users consistently preferred keeping filters visible and accessible. The expandable tabs introduced an unconventional interaction that I initially had reservations about, but it tested well with stakeholders and proved easy to learn in practice.

Selected explorations of how to organize entities, sites, and products for quick switching.

An unexpected benefit was that alert indicators could be embedded directly into tabs and chips, allowing users to see which sites and product families contained issues before opening them.  From a technical perspective, these dimensions still behaved as filters applied to the same reporting datasets. In the interface, however, sites became navigation views while products became contextual selectors. This allowed the experience to reflect how users thought about performance rather than how the data was structured.

Alerts in entity tabs and product selectors highlighted issues before users opened the reports.

Detailed reports combine historical trends, benchmark comparisons, and performance breakdowns across entities and sites. Sensitive information is blurred.

The Executive Summary provided a snapshot of performance. Detailed reporting needed to show how that performance evolved over time across sites, entities, and products. Before deciding how users would navigate these reports, I first had to determine what they should contain. Across the manufacturing ecosystem, hundreds of charts, tables, and indicators existed in spreadsheets and presentations. The challenge was deciding which deserved a place in the platform, which should be improved, which could be simplified, and which could be removed entirely.

For each reporting pattern, I started with the question users needed to answer: how performance evolved over time, how it compared with a benchmark, or which factors contributed to a deviation. This guided the choice of chart and the information shown by default. Units, periods, and benchmarks needed to remain clear so users could interpret the figures in context. Hover details exposed precise values and supporting information without adding permanent clutter, while chart-level controls allowed users to adjust the analysis within the broader reporting context.

Snapshot from figma. Chart iterations compare readability, information density, and interaction tradeoffs. The same process informed the other reporting charts.

Deconstructing the reports revealed that many were repeated analyses applied to different combinations of sites, products, periods, or performance dimensions, often using different visualizations to communicate the same underlying insight. This shifted the problem towards designing a smaller set of reusable reporting patterns.The challenge was deciding how much to standardize while preserving familiar reporting methods. Some were deeply embedded in operational workflows and needed to be retained, while others could be improved, replaced, or simplified. Significant effort went into improving chart usability through interactions, contextual information, and clearer visual hierarchy.

Multiple grid layouts for report cards were also explored to balance density, readability, and scalability. Different combinations of local and global controls were tested and validated to determine which settings should apply across reports and which belonged to individual charts. This allowed the same reporting patterns to support different operational contexts without recreating every existing report separately.

Selected variations of one chart. Each of the +10 other charts required testing different ways to present the same performance data.