A manufacturing application is judged in two minutes, with gloves on, by somebody who has somewhere else to be.
Most enterprise applications are built for one person at one desk with one mailbox. A plant is none of those things, and the gap between the two is why shop-floor software gets abandoned.
This table is the design brief, established before any wireframe. It is the difference between an application people use and one that is live and ignored.
Most manufacturing application programmes design for row four and deploy to all six.
Fragmented manufacturing applications and user experiences
Six applications, six logins, six navigation models, each introduced to solve one department’s problem. The cost lands on whoever has to use more than one of them, which is usually the supervisor.
Manual workflows and spreadsheet-based operations
The spreadsheet works. It is fast for its owner and it encodes real business logic nobody has written down. Replacing it requires beating it on speed, which is addressed in section 3.
Limited visibility across manufacturing departments
Each function can see its own work. Nobody can see the sequence, so the handoffs are where time disappears and where nobody is accountable.
Disconnected employee, supplier and customer portals
Three audiences with genuinely different security postures. Combining them in one application is usually wrong, and building three that share nothing is also wrong.
Inconsistent application access across plants
A plant that grew by acquisition has its own directory, its own device standard and its own view of who may approve what. Access harmonisation is the unglamorous precondition for a group application.
Legacy manufacturing application limitations
Applications that work and cannot change: no mobile, no API, an unsupported framework. Whether to modernise or replace is covered on the Application Modernization page.
Poor mobile accessibility for shop-floor users
Mobile in a plant does not mean a phone. It means a shared rugged device, a wall-mounted terminal, a forklift-mounted screen, or a tablet in a wipe-clean case. Each has different input and different constraints.
Duplicate data entry across enterprise systems
Two departments each keep their own record because each has been caught out by the other. The duplicate entry is a symptom of an unresolved ownership question, and an application cannot settle it.
Limited workflow automation and collaboration
Approvals that travel by email and conversations that happen by radio. Both work and neither leaves a record, so the same decision gets made again next month from scratch.
Application security and scalability challenges
Shared accounts on the floor, a supplier login that outlived the supplier, and an application that was built for one plant and is now expected to serve eight.
The first design session happens on the floor, during a shift, watching the task. Requirements gathered in a meeting room produce an application that matches what people say they do, which is reliably different from what they do.
Step 1
Manufacturing business process and user needs assessment
What the work is, who does it, and what currently gets in the way. Conducted where the work happens rather than where the budget is.
What the work is, who does it, and what currently gets in the way. Conducted where the work happens rather than where the budget is.
Step 2
Stakeholder and user journey mapping
Per population from the table in section 2, including the device and the identity mechanism each one actually has.
Per population from the table in section 2, including the device and the identity mechanism each one actually has.
Step 3
Application requirements and workflow discovery
Including the spreadsheet logic, which usually has to be read rather than asked about because its owner has internalised it.
Including the spreadsheet logic, which usually has to be read rather than asked about because its owner has internalised it.
Step 4
Portal and application architecture design
Shared services behind, separate experiences in front. One data layer, one identity model, several front ends matched to populations.
Shared services behind, separate experiences in front. One data layer, one identity model, several front ends matched to populations.
Step 5
User experience and interface design
Designed against the physical conditions: glove use, lighting, distance, noise, one free hand, and whether the user is standing.
Designed against the physical conditions: glove use, lighting, distance, noise, one free hand, and whether the user is standing.
Step 6
Application development and system integration
Built with the enterprise interfaces specified as contracts. The integration patterns themselves are covered on the API & Enterprise Application Integration page.
Built with the enterprise interfaces specified as contracts. The integration patterns themselves are covered on the API & Enterprise Application Integration page.
Step 7
Workflow automation and business rules implementation
Rules externalised so a threshold or an approver can change without a release, because in a plant they will change.
Rules externalised so a threshold or an approver can change without a release, because in a plant they will change.
Step 8
Application testing and security validation
Tested on the actual device, in the actual area, by the actual users. A tablet that works at a desk can be unusable under plant lighting in a case with gloves on.
Tested on the actual device, in the actual area, by the actual users. A tablet that works at a desk can be unusable under plant lighting in a case with gloves on.
Step 9
Pilot deployment and user adoption
One line or one department, with somebody present on the floor during the first week of shifts rather than training in a room.
One line or one department, with somebody present on the floor during the first week of shifts rather than training in a room.
Step 10
Continuous application enhancement and support
With a route for a supervisor to request a change and get an answer, because an application nobody can influence stops being used when it stops fitting.
With a route for a supervisor to request a change and get an answer, because an application nobody can influence stops being used when it stops fitting.
The population is named for each, because it determines the device, the identity mechanism and the interaction model, and those three decide whether it gets used.
Shop-floor operator applications
For the shared terminal. Two taps, no typing, legible at distance, and functional with gloves on. The hardest build on this page and the one with the highest return when it is right.
Manufacturing employee portals
Self-service for a workforce that may not have individual mailboxes: payslips, shift rosters, leave, training records, accessed through a kiosk or a badge tap.
Production workflow applications
The coordination that currently runs on radio and paper: requests, handoffs, escalations, each with a state and a record.
Manufacturing management dashboards
For supervisors and managers at a desk or on a floor tablet. Distinct from a shop-floor screen, which is a different product.
Quality and compliance applications
Light-touch capture and visibility here, with the full inspection, nonconformance and corrective action workflows on the Quality Management Applications page.
Maintenance request and service portals
Raising and tracking a request from the line, with the maintenance planning side handled in your maintenance system.
Supplier collaboration portals
External identity with scoped, expiring access and delegated administration, so the supplier manages their own people and you are not the last to know when somebody leaves.
Customer and dealer portals
Order and delivery status, documentation and self-service. Status only, with no path to anything internal.
Document and knowledge management applications
Current revision at the point of use, which for work instructions means the station rather than a document library somebody has to go and search.
Mobile manufacturing applications
Built for the device class in use: rugged handheld, wall terminal, vehicle-mounted screen or tablet in a case, each with different input and different assumptions.
Role-based enterprise applications
One application with role-scoped experiences where the populations genuinely overlap, which is less often than it is assumed.
All ten work. They differ in how reliably people keep using them after the first month, and the order below is the order to build them in if adoption matters more than visibility.
Digital shop-floor work instructions
Current revision of the job at the station, for the product running.
Shift handover and operational communication
What happened, what is broken, what to watch, captured and carried across the handover.
Maintenance request and approval workflows
Raising a request from the line and seeing what happened to it.
Quality inspection and issue reporting
Capturing a check or raising an issue at the point it is found.
Production supervisor dashboards
The shift view with the exception queue attached.
Manufacturing employee self-service
Rosters, leave, payslips and training records, through a kiosk or badge tap.
Manufacturing document approvals
Review and approval with a record of who approved what.
Supplier onboarding and collaboration
Documents, qualification, orders and performance in one place for the supplier.
Customer order and delivery visibility
Self-service status for customers.
Multi-plant operational collaboration
Shared visibility and shared working across sites.
The populations in section 2 need genuinely different interfaces and the same data, rules and identity behind them. That shape is the architectural decision on this page, and getting it wrong in either direction is expensive.
One application stretched across all six populations fits none of them. Six independent applications duplicate the rules, and the rules then diverge.
Cloud-native and hybrid application architecture
Cloud for anything the plant does not depend on inside a shift. Local execution or local caching for anything a line cannot run without, because a shop-floor application that stops when the link drops will not be trusted again.
Web and mobile application development
Built against the device class rather than against a screen size. A rugged handheld, a wall terminal and a tablet in a case have different input methods and different failure modes.
Microsoft Power Platform and Dynamics 365
Named in the brief. We work with these platforms where the client already runs them and where the workload suits a low-code approach, which is true for approval and request workflows and less true for a high-volume shop-floor capture screen. We state no partner or certification status.
.NET, Java, Python and modern application frameworks
Chosen against what your team can maintain after handover, which is a more important criterion than any technical comparison between them.
React, Angular and modern frontend technologies
Used for the desk and supervisor experiences. A shop-floor capture screen is usually simpler than a framework assumes and benefits from being lighter.
REST APIs and enterprise integration
Each interface specified as a contract with its failure behaviour stated. The integration patterns are covered on the API & Enterprise Application Integration page.
ERP, MES, PLM, QMS and CMMS connectivity
Reading and writing against a named system of record per data element, so the application never becomes a second place the truth lives.
Workflow and business process automation
Rules and approvers held as configuration rather than code, so a change of threshold or approver does not need a release.
Identity and access management
One identity model across the populations, including the badge and PIN mechanisms from section 5 and delegated administration for external users.
Application hosting, monitoring and DevOps
Pipelines, environments and monitoring, with alerting on a shop-floor application treated as a production concern rather than an IT one.
Governance defines who may change the application, how exceptions get resolved, and how production continuity is protected. Everything below serves one of those three.
Shared accounts on the floor are the normal starting condition and the single biggest control weakness in this category. Every approval, every quality record and every inventory adjustment made under a shared login is unattributable, and discovering that during an audit is the expensive way to learn it.
Role-based access and authorisation
Roles defined by what the job requires, reviewed when people move, and scoped per plant where the plants genuinely differ.
Application identity and authentication
Individual identity even on shared devices, through a badge tap or PIN with a short session. Shared accounts are acceptable only for read-only display and never for anything that records a decision.
Manufacturing data protection
Process parameters, formulations, costs and supplier terms restricted by role rather than visible to anyone with a login. A plant application often carries more commercially sensitive data than its users realise.
Workflow approvals and segregation of duties
The person who raises something cannot approve it, enforced in the workflow rather than stated in a policy. This matters most in procurement, inventory adjustment and quality disposition.
Audit trails and activity logging
Who did what, when, on which device, retained so an action can be reconstructed. Subject to the employee relations constraint below on how that data may then be used.
Application security testing
Before exposure rather than after, including the external-facing portals, where the supplier and customer surfaces are the ones that matter most.
Application lifecycle and release management
Releases into shop-floor applications go through the plant change process and respect production windows. Software a line depends on is a plant change whichever function builds it.
Data ownership and retention policies
One named owner per data domain, with retention agreed rather than defaulted. An application that keeps everything forever becomes a disclosure problem.
Business continuity and recovery
A documented way for the line to continue when the application is unavailable, and a path to load what it recorded locally without creating duplicates.
Application support and operational governance
A named owner, an on-call route for anything a line depends on, and a change request route a supervisor can actually use.
An application can be available, fast and error-free and still be unused. Availability tells you the system works. Adoption tells you whether it fits the job, and only one of those is the point.
Portal usage and user adoption
The primary measure, and measured by task completion rather than by logins. A login followed by nothing is a person checking whether it is still broken.
Manual process reduction
The second measure. Whether the spreadsheet, the paper form or the radio call actually stopped. A surviving parallel process is the clearest evidence of a usability failure.
Workflow completion time
End to end, including the waiting. Most of the improvement in these applications comes from removing waiting rather than from speeding up entry.
Application availability and response time
At the device, measured during a shift. A response time measured from the data centre is not what the operator experiences on a wall terminal over plant wireless.
Application error and failure rates
By population, because an error rate concentrated in one group is a design problem for that group rather than a general fault.
User experience and satisfaction
Collected on the floor from the people using it, briefly and often, rather than through an annual survey nobody on a shift completes.
Integration reliability
Per interface, since an application that cannot reach ERP looks broken to its users whatever the application itself is doing.
Mobile application performance
On the actual devices, including the oldest one still in service, which is the one that sets the real experience.
Application maintenance and support efficiency
Effort to keep it running, and the share of support tickets that are usability questions rather than faults. A high share of the latter is a design signal.
Continuous application improvement
Changes requested by users and delivered, tracked as a ratio. An application nobody can influence stops being used the moment the process changes.
Connected manufacturing teams and stakeholders, with each population given an interface built for the device and the identity they actually have
Improved operational collaboration, mostly from making the handover and the request durable rather than from a collaboration feature
Reduced manual workflows, measured by whether the spreadsheet and the paper form actually stopped
Faster information access and decision-making, with most of the gain coming from removing waiting rather than from faster entry
Improved employee and supplier experiences, which for a workforce without mailboxes is often the first digital service they have been given
Scalable manufacturing applications, achieved through one back end with several front ends rather than one application or six
If a previous application went live and is not used, the cause is usually that it was designed for the office and deployed to the floor. That is diagnosable in a day on site.
CaliberFocus builds manufacturing applications for the people who actually use them: shared terminals, gloves, no personal mailbox and seconds between tasks. We watch the job before designing the screen, make the spreadsheet owner the acceptance test, build one back end with front ends matched to each population, and give every user individual identity even on shared devices.
- Device and identity reality established per user population
- The spreadsheet owner’s timed task as the acceptance test
- One back end with separate front ends per population
- Individual attribution on shared devices through badge or PIN
Security & Compliance
