Overview

In CMMS products used by SMB and enterprise maintenance teams, users often repurpose work orders for work that does not fit the asset model: the asset may not be tracked in the CMMS, may not be added yet, or the work may still be a planning draft. This created a need for a separate way to capture real maintenance work without forcing inaccurate or placeholder asset data.

A self-driven POC concept

The problem space is grounded in patterns observed in industrial maintenance software across teams at different stages of maintenance maturity. The survey data in this case study is simulated, and the POC usability study is planned, not run. Both illustrate the design and validation process.

How I used AI

I worked with Claude as an AI assistant for research support, workflow exploration, microcopy and artifact generation, including the live prototype. It helped me explore, draft and build. I reviewed what it produced, made the decisions and set the scope of the work.

Understanding the problem

An earlier survey in a real CMMS context showed people creating work orders without selecting an asset. The most common reason was work on assets not tracked in the CMMS, followed by assets not yet added, then draft work orders for planning. The work order model didn't support every kind of real maintenance work. A work entry is a lighter record for work that doesn't fit the asset model.

Research goals

• Find the strongest non-asset scenario to build a lean POC around.
• Understand why people track this work in the CMMS.
• Check how creating work orders without an asset affects reporting and data quality.

Survey research plan (simulated)

The insight and the decision

Survey results are simulated for this conceptual POC and are shown only to demonstrate how the opportunity could be narrowed. It’s more than missing data. People still needed to track real work even when there was no asset to link it to, and creating work orders without an asset was already hurting reports.

Survey results (simulated)

• 15 of 54 said they had never needed to create a work order without selecting an asset.
• 39 of 54 participants had created a work order without selecting an asset.
  • Of those 39, they did it for these situations:
  • Note: this was a multi-select question, so participants could choose all that apply and the three add up to more than 39 (51 selections from 39 people).
  • 19 selected work on an asset not tracked in the CMMS
  • 17 selected work on an asset not yet in the CMMS
  • 15 selected a draft work order for planning
• 31 of those 39 said the workaround caused a moderate or major reporting issue

The decision

Based on these results, I focused the POC on work on assets not tracked in the CMMS, and kept planning drafts and new assets as later, lower-priority cases.

How I used AI

My AI assistant helped me turn the research goals into survey questions and a scope. I cross-checked the survey artifacts and results to make sure everything aligned.

Survey results (simulated)

The insight and the decision

Survey results are simulated for this conceptual POC and are shown only to demonstrate how the opportunity could be narrowed.

It’s more than missing data. People still needed to track real work even when there was no asset to link it to, and creating work orders without an asset was already hurting reports.

Designing the experience

In the POC, I introduced a work type to capture work that doesn’t fit the asset model. It gives maintenance teams the ability to choose what kind of work they are creating, because that choice decides whether an asset is needed. Work on an untracked asset gets its own work type, assetless by design, so required assets stay required on work orders. With AI assistance, I looked at competitors and adjacent industries for similar workflows, to adapt established industry-standard patterns and usability best practices.

How I used AI

I used it to explore the flow, pull patterns from competitors and adjacent industries, write microcopy and generate the wireframe board layouts.

Workflow and wireframes

Testing the POC

Note: this is a concept for a usability test plan. It was not run and there are no results.

Before moving on to high-fidelity designs, I would test the POC wireframe flow as an unmoderated usability study to see whether maintenance teams can find and use the new work type without any guidance. As part of that, I would run a few internal dry-run tests to make sure the tasks make sense, and make any adjustments before launching the unmoderated usability study in Maze.

Unmoderated usability test plan (simulated) POC prototype workflow POC prototype High-fidelity UI

How I used AI

I used it to explore the flow, pull patterns from competitors and adjacent industries, write microcopy and generate the wireframe board layouts.

Moving from POC to MVP launch

Findings from the unmoderated usability study would be triaged into fix, refine, park or drop. I would then make the design tweaks, check accessibility compliance, finish the final UI and hand off to development.

Launching to a closed pilot first. Users would opt in through an in-app invitation, and I would widen the pilot based on the success metrics. This is a plan; none of it is implemented..

From POC to MVP and Measuring Success

Possible future iterations

These are ideas for later, when AI-powered features are added to the CMMS. None of them is part of this POC.

• Templates from repeat work: flag how often a specific type of work is created and suggest turning it into a template.
• Better-fit work types: notice when someone starts a work order without the details it needs and suggest a better fit, such as "New asset work" or "Planning / Draft".
• Entry summaries: a one-line summary of a long activity and chat thread, useful for hand-offs between shifts.
• Reporting insights: a plain-language summary of how much work is happening outside the asset model, supporting the reporting impact metric in the closed pilot plan.

Reflection

Working with an AI partner on this case study showed me where it speeds the work up and where I still need to lead.

• AI is fast at exploring, synthesizing and drafting. It simulated survey data modelled on a past real survey, flagged inconsistencies when prompted, and produced wireframes and visual design quickly, especially when I gave clear direction.
• It was a back-and-forth partnership, not a one-shot generator. AI gave me strong starting points, but I still had to check its work, give direction and make the final calls. The best results came from several rounds of my feedback and decisions.
• Next time, I would use one tool. Using two AI tools sped up the work but added friction. License constraints and split context slowed me down, so I would invest in one tool and keep the structure in one place.