How Celean validates prototypes with industry partners

A prototype can look convincing in a polished demonstration and still fail when a planner meets a daily work routine. The Celean Research Team at Chalmers approaches this gap differently: it develops digital visual planning, Kanban, enterprise systems and lean tools beside the people who use them. Prototype quality is therefore judged by operational fit, not visual appeal.

Celean, the Chalmers Electronic Lean Research Team, works with industry partners to study how digital visual planning, Kanban boards, visual project management, enterprise systems and lean processes perform in practice. Its role is to connect academic inquiry with the decisions teams make around software, information and day-to-day work. Prototype tools become research instruments when their assumptions, boundaries and effects are made visible to both sides.

Industry validation is therefore more than arranging a demonstration. It means testing whether a proposed tool supports the work it was meant to improve, under realistic constraints, and learning whether users understand, trust and adapt it. A strong result may justify wider use; a weak result can expose a design fault, missing integration or incorrect problem definition before expensive implementation begins.

For Australian organisations, that scrutiny must include operating across capital cities, suppliers and dispersed teams. Volvo's Australian presence gives a useful local reference point, while projects in Melbourne, Sydney, Brisbane and Adelaide expose prototypes to different work rhythms. The aim is not to recreate a Swedish site exactly, but to learn which principles transfer and which need local interpretation.

Turning research questions into testable propositions

Validation starts by reducing a broad research interest to a concrete operational question. Instead of asking whether visual planning improves performance in general, a study might ask whether a shared Kanban view helps a project team identify blocked work sooner. The team records a baseline, defines the users and decisions in scope, and states what evidence would count as improvement.

The partner context determines the research design. Celean works with organisations such as Volvo, where digital tools connect production, project and maintenance activities. Interviews with planners, team leaders and operational users reveal where information currently disappears, while technical specialists identify constraints in enterprise platforms, access rights and data quality. This shared problem definition prevents a technically elegant prototype from solving the wrong issue.

The result should be a testable proposition, not a promise. For example, reducing time spent assembling status updates may be the intended effect of a visual planning prototype, provided it remains accurate and practical for daily use. Success criteria can include shorter planning cycles, clearer ownership, fewer stalled items and acceptable administrative effort. Constraints such as shift patterns, device access and legacy integration belong in the proposition from the outset.

Co-designing with operational users

Co-design sessions bring research and industry knowledge into the same room. Participants sketch current workflows, mark delays and compare alternative routines on a whiteboard before software behaviour is decided. This exposes assumptions quickly: a column that looks logical to a developer may not match how supervisors describe work, while a simple tablet view may be more usable than a detailed dashboard. Prototypes then evolve through small, visible cycles rather than a single handover from designers to users.

Technical fidelity should match the question. A concept test may use paper cards and a clickable screen, while an operational pilot might connect a Kanban board to planning, maintenance or enterprise data. The team balances realism with control, using representative cases without exposing confidential records unnecessarily. Interface design, system performance and governance are tested together, because a useful interface cannot compensate for stale data or an unclear owner.

Transparency matters when a framework may be reused beyond one partner. Project Visit's account of open-source Kanban frameworks illustrates how shared development can expose design choices and invite adaptation. Celean uses that openness during research by documenting what is configurable, what remains fixed and how a prototype changes when tested with different teams. The aim is a framework whose behaviour can be understood, reproduced and challenged.

Testing inside the workflow

A pilot needs a defined setting, period and comparison. The team might begin with one planning team, observe it for several weekly cycles and compare it with the previous process, a comparable team or an agreed set of process measures. A baseline does not need to be a laboratory control; it needs to be stable enough to show whether a change is plausible. Access to data and agreement on observation boundaries are settled before use begins.

Observation reveals what interviews alone miss. Researchers record repeated status updates, unofficial spreadsheets, workarounds and moments when a person ignores the tool because the underlying data is late. Short interviews then help explain those behaviours without interrupting urgent work. Task-based exercises can add controlled evidence, but live use remains essential for understanding how the prototype fits shifts, meetings, handover routines and the physical environment of a workplace.

Feedback is organised around decisions rather than general approval. After each cycle, the team asks what changed, which new burden appeared, which data fields remain unreliable and whether the next iteration still addresses the original hypothesis. This rhythm lets industry partners retain ownership of the work while researchers connect observations to systematic evidence. It also keeps a successful presentation from being mistaken for a successful process.

Measuring outcomes and evidence

Quantitative measures establish whether the observed change matters. Depending on the study, Celean may examine planning cycle time, work in progress, schedule adherence, overdue actions or time spent preparing reports. It can also assess usage patterns, such as how often cards move, which fields are completed and where users abandon a workflow. Baseline definitions matter, since an attractive dashboard can otherwise create the appearance of control without changing the underlying flow.

Qualitative evidence explains the numbers and captures effects that standard metrics miss. Interview extracts, observation notes, system logs and short user surveys can be compared to identify consistent themes rather than relying on one enthusiastic account. The research team can also examine whether the prototype redistributes work, reinforces existing managerial routines or makes cooperation across roles easier. Mixed evidence supports a balanced judgement about value, limits and conditions for use.

Documentation is another part of validation because it allows partners, researchers and future adopters to reproduce the test. A service such as the QLOUDPRESS publishing platform can support concise workflow guides, release notes and versioned demonstration material, while Project Visit provides the durable home for research publications. Clear records of assumptions, data sources and known defects make later comparison possible and help separate verified findings from promotional descriptions.

Recommendations for a defensible pilot

A reliable pilot is easier to run when responsibilities are settled before the first task. The research team owns the method and evidence, while the partner owns access to users, operational decisions and interpretation of local practice. Both sides should know who can change a requirement, approve a data extract and decide whether the next cycle continues.

The following recommendations provide a practical review point for any industrial prototype. They are deliberately concise enough to use in a project meeting and specific enough to expose gaps before a rollout.

• State one operational decision the prototype must improve, and keep every design choice linked to that decision.
• Record a baseline before deployment, including how the metric is calculated, who owns the data and when it will be reviewed.
• Recruit a representative mix of experienced users, occasional users and people who may receive the prototype's outputs.
• Test with realistic cases, including exceptions, incomplete information, shift handovers and scenarios where users bypass the intended path.
• Capture failures, workarounds, support requests and negative feedback as carefully as successful transactions and positive comments.
• Agree in advance what evidence will trigger redesign, further testing, limited adoption or a recommendation against deployment.

Adapting validation to Australian realities

Melbourne offers a useful starting context because Volvo Cars Australia is based in South Melbourne, close to a substantial automotive, design and advanced-manufacturing network. A local pilot can involve engineering, service and supplier coordination across metropolitan sites. It also tests whether a visual tool fits procurement cycles, regional travel and the commercial pressure of keeping vehicles, equipment and projects moving.

Spread across Sydney, Brisbane and Adelaide, Australian teams face different operating rhythms. Eastern-state offices may coordinate with European colleagues across several time zones, while Adelaide brings defence and advanced-manufacturing relationships into the mix. These settings reward prototypes that expose ownership and dependencies clearly, since a single shared view can help people coordinate without assuming everyone attends the same meeting or works the same hours.

Australian workplace customs also influence the evidence. Operators and supervisors often provide direct, practical feedback during informal site walk-throughs, while project teams expect demonstrations to be tied to actual responsibilities rather than abstract benefits. Safety approvals, access rules and local supplier requirements may shape a pilot as much as software behaviour. A prototype designed only for central headquarters could miss these realities and overstate its transferability.

Turning pilot evidence into reusable capability

Validated prototypes feed the next stage of research rather than disappearing after the pilot. Findings can refine an open-source framework, identify integration requirements for enterprise systems or become a case in a research publication. Celean's collaboration model keeps academic rigour and industrial relevance connected: partners gain an evaluated tool and clearer process understanding, while the research team gains observations that a controlled lab exercise could not provide.

Publication also requires editorial clarity. A research site may sit beside reader resources unrelated to the project, including a RocketPlay bonus code page, so labels must distinguish peripheral material from Celean's evidence. The same discipline applies to prototype demonstrations. Screenshots, performance claims and participant quotations need context, version details and clear limits, allowing readers to judge what was tested without mistaking promotion for proof.

The practical takeaway is simple: a prototype earns confidence when it is shaped with users, tested against a baseline in real work, measured with mixed evidence and revised in response to what the evidence shows. That sequence turns a promising demonstration into a credible basis for research, product decisions and lean process improvement.