Turning complex production workflows into a usable ERP system

Overview

The internal ERP system was designed to give production teams, inventory officers, finance teams, and company leadership a shared view of production activity. It brought project tracking, inventory visibility, equipment management, and role-based oversight into one platform.

The challenge

Before the ERP system, production managers and operators had to piece together information from separate tools and manually maintain updates. This made it difficult to quickly understand:

• Where a project was in the production process
• Which workstation was responsible for the next step
• Whether a project had been delayed, needed rework, or was defective
• What materials were available for an incoming order
• Whether machinery and production capacity could support additional jobs
• Who was responsible for a specific part of the workflow

This limited the team’s ability to keep orders moving and made it harder for the company owner to see what was happening across the production floor.

The goal was not simply to create an admin dashboard. We needed to translate a complex, physical manufacturing process into a system that different teams could understand and use in their day-to-day work.

Understanding the workflow

Before designing the interface, we needed to understand how a product moved through the company.

I worked with the production manager, product managers, developers, the UX writer, the company owner, the finance team, and other stakeholders to map the operational workflow. This involved hours of conversations and ideation sessions because each team interacted with the process differently.

A typical project could begin with a customer request for a custom trophy. The product-design team would create a 3D model or rendering, which needed approval before the project moved to the production floor. From there, it passed through multiple stages, including printing, sanding, spraying, and other finishing processes.

At each stage, the team needed to know whether the item was progressing as expected. If an issue occurred, the project also needed a clear status for rework or defect handling.

These sessions helped us create a PRD and user flows grounded in how work actually happened, rather than designing from assumptions.

Prioritising the first release

The product had a wide scope. Beyond production tracking, stakeholders needed inventory management, asset monitoring, financial visibility, client-facing design approval, and AI-generated design mock-ups.

Trying to build every requirement at once would have created a large, complex first release. We therefore prioritised the most urgent business problem: helping teams understand what was happening on the production floor.

For V1, we focused on the movement of projects across workstations. This made it possible for production managers and operators to see a project’s current stage, its priority, and the next action required.

The product-design and approval workflow was important, but we deferred it because it was not the immediate pain point V1 needed to solve. This helped the team focus effort on the features with the clearest operational value while leaving room for the product to evolve.

Designing production visibility

The main production workflow was designed to make project movement visible from one workstation to the next.

Each project could be tracked through its required production stages, allowing teams to see where work was happening and what needed attention. Clear priorities and status labels were used to communicate progress, while workflows accounted for projects that needed rework or were marked as defective.

The system also included supporting operational tools:

• Project tracking: Track a project as it moves between workstations.
• Workflow statuses: Show project progress, priorities, rework, and defects.
• Inventory management: Provide live inventory counts, material-usage tracking, and low-stock or out-of-stock alerts.
• Asset management: Help teams monitor machines, review maintenance schedules, understand machine usage, and assess production capacity.
• Role-based dashboards: Give relevant teams and leadership a view of the information they needed to oversee operations.
• Client design support: Enable clients to receive mock-ups of designs before they move into production.

Improving V1 for V2

The system went through multiple versions: V1, V1.2, and V2. As the product was used and feedback came in, it became clear that a functional system still needed usability improvements.

Technicians on the production floor found parts of the original typography difficult to read quickly. In a fast-paced working environment, critical information must be easy to scan. I raised the need to reconstruct the typography scale for the ERP system and worked with the team to improve the hierarchy.

We also received feedback that some user journeys were more complex than they needed to be. Through further conversations with technicians and the production manager, we identified workflow requirements that needed clearer handling within the interface.

The changes in V2 included:

• A revised typography scale to improve legibility and information hierarchy
• More intentional colour use to support clarity and status recognition
• Simplified user journeys based on technician feedback
• Refined workflows based on production-manager input
• A shared design system to create consistency across ERP modules

Building consistency at scale

Because two designers were working across different modules, consistency became essential. Without shared patterns, the platform could easily feel fragmented as new features were added.

I contributed to creating a design system that supported a more unified ERP experience. The system established reusable patterns for:

• Navigation
• Role-based dashboards
• Typography
• Colour usage
• Status labels
• Tables
• Filters
• Alerts
• Form and interface patterns

The design system made it easier to maintain consistency across modules while supporting collaboration between designers, developers, product managers, and the UX writer.

My contribution

As a product designer on the project, I worked with another designer and a cross-functional team to shape the system from complex operational requirements into a more intuitive product experience.

My work included:

• Participating in stakeholder sessions to understand workflows, pain points, and business needs
• Mapping production processes and translating them into user flows
• Contributing to the PRD and defining how users would move through the system
• Designing interfaces and workflows for the ERP platform
• Helping prioritise features between V1, V1.2, and V2
• Identifying readability issues in the initial system and proposing a typography overhaul
• Contributing to improved visual hierarchy and colour use
• Creating and applying shared design-system patterns across modules
• Iterating on user journeys based on feedback from technicians and the production manager
• Collaborating with product managers, developers, the UX writer, production stakeholders, finance, and company leadership

Outcome

Version 2 of the ERP system is live.

The live product gives the company a central system for tracking production work and supporting operational visibility across projects, inventory, equipment, and production activities. Feedback from technicians directly influenced improvements to readability and workflow simplicity, while production-manager feedback helped refine features important to day-to-day operations.

The project also established a stronger visual foundation through a revised typography system and reusable design patterns that support consistency as the ERP continues to evolve.

What I learned

This project taught me that operational products cannot be designed well from a feature list alone. A workflow that seems straightforward on paper can involve multiple teams, handoffs, dependencies, exceptions, and competing priorities in practice.

I learned to spend more time understanding the product before moving into solution design. Speaking with each stakeholder, especially the people doing the work on the production floor, revealed needs that would have been easy to miss otherwise.

I also learned the importance of balancing scope with value. Rather than trying to solve every part of the business at once, we focused V1 on the production-floor problem with the clearest immediate need. This allowed the product to move forward while leaving space to improve and expand through later versions.