1. Project Overview

AssetProof is a digital transformation solution for industrial operations, designed to help organizations manage and verify equipment inspection data across multiple factory locations.

Rather than simply replacing paper checklists, the system connects field inspections, operational evidence, and management data within a unified platform. This enables businesses to track inspection activities from the factory floor through to management, creating a reliable operational record that supports day-to-day decision-making.

My Role: Product Lead (Design & Delivery)

I led the project from problem definition through product delivery, taking responsibility for both product strategy and execution. My responsibilities included:

• Redefining the business problem through user and operational research.
• Defining the product strategy and development roadmap.
• Coordinating development scope, timeline, and delivery.
• Designing the end-to-end experience for both the field inspection application and the administration platform.

The client participated in User Acceptance Testing (UAT) throughout each implementation phase to validate operational workflows before deployment.

Highlights

Confidentiality Notice: To protect client confidentiality, certain names, visuals, and operational data have been anonymized or modified. This case study focuses on the product thinking, problem discovery process, and key design decisions behind the solution.

2. Understanding the Operational Context

The existing inspection workflow relied heavily on employees to manually record inspection results and upload supporting data to the system. While the process captured inspection records, it provided limited assurance that the reported results accurately reflected the actual condition of the equipment at the time of inspection.

This raised a broader product question: How might we help the business trust its inspection data without creating additional burden for field workers?

The Initial Challenge

The project initially started with a straightforward business request:

How can we prevent inspectors from cheating during equipment inspections?

At first glance, the problem appeared to be about preventing fraudulent behavior.

However, as I observed the operational workflow and spoke with stakeholders, a different picture emerged.

Fraud was not the only reason inspection data became unreliable. It was simply one of several factors that could compromise data quality.

Even when inspectors followed the process honestly, inaccurate data could still occur because of:

• Selecting the wrong checklist
• Missing evidence from the inspection site
• Fragmented documentation and record management

The underlying problem was never about controlling people.

It was about creating a system capable of producing trustworthy operational data.

Redefining Success

The business didn’t need tighter control over people. It needed a system capable of producing trustworthy operational data. A system that could ensure every inspection was:

• Performed on the correct equipment
• Completed by the assigned inspector
• Conducted at the right time
• Verified at the actual inspection site
• Traceable
• Verifiable

3. Research & Discovery

Key stakeholders across the AssetProof ecosystem

Research Approach

To understand the real operational context, I went beyond stakeholder interviews and spent time observing field inspectors during actual equipment inspections.

Because this was an operational workflow, I believed the most important insights would not come from documented requirements alone, but from observing how people actually performed their work in the field.

This helped uncover challenges that were difficult to identify through meetings or reports, while also revealing how the factory environment would influence future product decisions.

Key Findings

1. Inspections Were Highly Time-Constrained

Equipment inspections were carried out at the end of each shift. Each inspector was responsible for completing checklists for approximately 15–20 pieces of equipment before handing over to the next shift.

Under this level of time pressure, every unnecessary interaction increased the risk of skipped steps, mistakes, or inaccurate inspection records.

2. The Workflow Was Highly Repetitive

The same inspection process was repeated every day.

Over time, this increased the likelihood that inspectors would rely on habit rather than carefully observing the equipment, making inspection records less representative of the actual equipment condition.

3. Finding the Correct Checklist Took Too Much Time

Each equipment type required a different inspection checklist.

Inspectors had to manually match equipment IDs with the corresponding checklist before starting an inspection.

Besides increasing the time required to complete inspections, this also introduced the risk of recording inspection results under the wrong checklist. Even when inspectors followed the process correctly and honestly, the resulting data could still become unreliable.

4. Limited Access to Context During Inspections

When abnormal conditions were identified, inspectors had limited access to previous inspection or maintenance records.

As a result, assessing the severity of an issue depended more on personal experience than on historical operational data.

Gaps in the Existing System

After analyzing the inspection workflow, I identified four key gaps in the current system.

Rather than being caused by a single interaction, these gaps revealed weaknesses across the entire lifecycle of inspection data—from data collection and storage to its use in operational decision-making.

Project Constraints

The research also identified several constraints that directly influenced the product strategy:

• Inspection records required long-term storage and traceability.
• Users had varying levels of digital literacy.
• Inspections were performed under significant time pressure.
• The product needed to satisfy multiple stakeholder groups.

Reframing the Problem

When I presented my findings to the client, I explained that the real challenge was not inspection fraud, but trust in operational data. I supported this perspective with evidence gathered through field observations and workflow analysis.

The client paused for a moment before asking: “Can you actually solve this?”

That was the moment I knew we had successfully reframed the problem. It was also the moment the real scope of the project began.

4. Key Product Decisions

Once I identified the core challenge—building inspection data that truly reflects what happened in the field—I focused the solution around four key objectives.

4.1. Ensuring Verified Inspection Data

The Problem

The company had no reliable way to verify whether an inspection was actually performed on the correct asset and at the correct location.

Without a verification mechanism, inspection records only reflected what users submitted—not what actually happened in the field.

Decision

I initially considered using NFC for asset identification. NFC offers two major advantages: it requires close physical proximity, making it more difficult to bypass, and the engineering team already had hands-on experience implementing it in a previous project, which reduced technical risk.

However, after evaluating deployment scale and long-term operational costs, I decided not to move forward with NFC.

Instead, I chose a combination of QR codes and BLE beacons. This approach still verified both asset identity and inspector proximity while significantly reducing deployment costs. QR codes are also easier to replace, maintain, and scale with far less hardware dependency.

For a system expected to support thousands of assets, QR + BLE provided the best balance between reliability, cost, and scalability.

4.2. Reducing Human Error

The Problem

The previous workflow required inspectors to manually create folders, organize photos, structure files, and upload everything according to predefined rules.

These activities added no value to the inspection itself, yet became a major source of missing files, misplaced data, and poor traceability.

Decision

Rather than asking users to manage inspection data, I shifted that responsibility to the system.

Once an inspection is completed, photos and checklists are automatically compressed, categorized, and stored using a consistent structure—without requiring any additional user actions.

The goal was to eliminate repetitive tasks that created unnecessary friction while introducing avoidable human errors.

4.3. Standardizing Inspection Workflows

The Problem

Each asset type required its own inspection checklist. Managing these checklists through paper documents and temporary tools made updates difficult and increased the risk of inspectors using outdated or incorrect versions.

Decision

Instead of building an application that only supported inspections, I proposed extending the solution with a centralized checklist management platform within the administration system.

Checklists can now be created, updated, and distributed from a single source of truth, ensuring every inspector always receives the correct version.

4.4. Turning Data into Actionable Information

The Problem

After each inspection, information was scattered across photos, checklists, and separate reports. When incidents occurred, answering simple operational questions became surprisingly difficult:

• When was this asset last inspected?
• Who performed the inspection?
• Was the previous issue ever resolved?

Finding these answers often required multiple teams to piece together information manually, slowing down investigations.

Decision

I transformed raw inspection records into information that managers could immediately access through the dashboard, including asset history, inspection progress, detected abnormalities, and maintenance records.

The reporting system also consolidates operational data over time, helping organizations evaluate equipment health and measure the effectiveness of maintenance and inspection teams.

5. Solution Design

After Phase 1 was deployed, observations from real-world operations revealed new challenges and opportunities. These insights became the foundation for the overall architecture and long-term product vision of AssetProof.

The following solution demonstrates how the product evolved from real operational needs rather than predefined feature requests.

From Operational Challenges to System Architecture

AssetProof consists of four core components working together as a single operational ecosystem.

Redesigning the Inspection Workflow: From Manual Documentation to an Automated Operational Flow

From 24 manual steps → 5 digital tasks. Measurable operational impact

Impact

(*) The 30–50% improvement is not an estimate—it reflects results observed during five days of usability testing with real users.

The variation came from two factors: users’ familiarity with technology and the time required to adapt to the new workflow.

Users who were already comfortable with digital tools achieved higher improvements from the first day. Those with less experience required several days before the workflow became intuitive, but by the end of the five-day trial, the performance gap had narrowed significantly.

I intentionally present the results as a range rather than a single rounded number because it reflects reality more accurately. Digital transformation does not create the same impact for every user immediately—it depends on both adoption time and user familiarity.

These results were measured using brand-new hardware. Long-term signal degradation caused by battery aging, physical impacts, or industrial dust remains a risk that should be monitored in Phases 2 and 3.

The redesigned workflow connects the entire operational lifecycle of an asset—from inspection and maintenance to management reporting.

Instead of relying on disconnected reports and manual coordination, every inspection record is captured, traceable, and synchronized in real time within a single system.

End-to-End Workflow Comparison

A Shift in System Design Thinking

6. Product Roadmap

The client’s initial challenge was improving the reliability of inspection data. Rather than building a complete platform from day one, I planned the product as a phased roadmap where each release delivered measurable operational value while laying the foundation for the next stage of growth.

Planning the Product Rollout

AssetProof was intentionally developed as an incremental product rather than a large, all-in-one system.

The roadmap was prioritized based on:

• The urgency of operational problems.
• The business value delivered in each phase.
• Dependencies between system components.
• The product’s natural path for expansion.

The objective was not simply to deliver features, but to ensure that every phase solved a meaningful business problem while creating a clear reason to continue investing in the product.

Phase 1 — Validating a Digital Inspection Process

Objective

Replace paper-based inspections while improving the reliability of inspection data collected in real-world operations.

Plan for Phase 2 — Building the Management Platform

Objective

Expand from reliable data collection to a scalable operational platform.

Plan for Phase 3 — Operational Monitoring & Traceability

Objective

Transform inspection data into a management tool that supports operational decision-making.

7. Experience Design Decisions

Design Principle: Simplicity to Reduce Cognitive Load

Not because minimalism looks better. Because users work under pressure.

Field inspectors typically use the application during short breaks between tasks while trying to inspect multiple assets within limited time.

One principle guided every design decision throughout this project:

Just because the system knows something doesn’t mean the interface needs to show it.

The system always has more information than users need at any given moment. For example, login information identifies the user’s work shift, while scanning a QR code identifies both the asset and the appropriate inspection checklist.

As a result, every piece of information was evaluated with a single question:

Does this help users make their next decision?

If the answer was no, the system handled it automatically or revealed it only when it became relevant.

Field inspectors and maintenance technicians have fundamentally different mental models. One needs to start working immediately. The other needs immediate visibility into what has gone wrong and where.

For that reason, each role has its own dedicated Home screen. Their goals, workflows, and decision-making processes are fundamentally different, so each user sees only the information they need from the moment they open the application.

For me, simplicity is not about showing less information—it is about showing the right information to the right person at the right time.

This principle allowed every screen to focus on a single objective and a primary action, reducing cognitive load while helping users stay focused in high-pressure working environments.

Designing for Context of Use

One stakeholder suggested displaying daily inspection progress on the Home screen immediately after users logged in, allowing them to see the remaining workload before starting.

After analyzing the context of use, I reached a different conclusion.

The moment users open the application, their primary goal is to begin inspecting equipment—not to evaluate their progress. Displaying additional information at that moment would increase cognitive load precisely when they needed to focus.

Rather than treating this as a choice between user needs and stakeholder requests, I saw it as a design opportunity.

Instead of removing progress tracking, I reconsidered when and where it should appear.

During a work shift, users are taken directly to the QR scanning screen after their first login, skipping the Home screen entirely.

This removes a navigation step that adds no value to the inspection workflow while allowing users to start working immediately.

Progress tracking remains available on the Home screen. After completing an inspection, users receive a confirmation and can either continue scanning another asset or return to the Home screen to review their overall progress.

After discussing the technical feasibility with the engineering team—including camera permission handling and fallback scenarios—I presented the solution to stakeholders.

The proposal was approved because it preserved the business goal of tracking progress while creating a more efficient workflow for field inspectors.

Designing Around Gaps in the Experience

While designing the inspection workflow, I realized that standardized checklists successfully captured inspection results, but they failed to capture another type of operational knowledge.

Inspectors often noticed small observations in the field that were not serious enough to be reported as issues, yet could provide valuable context for the next work shift.

That gap led to the introduction of Shift Notes—a lightweight touchpoint that preserves operational observations, maintains context across shifts, and helps teams make better decisions.

It also became a reminder that meaningful product improvements do not always come from large features. Sometimes, small additions with low implementation complexity can create significant value when introduced at the right moment in the user journey.

8. From Assumptions to Reality

QR Codes Alone Were Not Enough

Initially, I assumed that scanning a QR code would be sufficient to verify that inspectors were working on the correct asset.

However, observing real-world operations revealed a different reality. Users could scan a previously captured QR code or record inspection data for a nearby asset of the same type. Although the records appeared valid, they no longer reflected what actually happened in the field.

Adjustment

I introduced BLE beacons to verify physical proximity, ensuring that inspectors were actually standing next to the correct asset before an inspection could begin.

Platform Guidelines Didn’t Reflect Real Working Conditions

The first version of the application followed standard Android tablet design guidelines. During usability testing, however, users consistently reported that buttons felt too small for quick and confident interaction.

Field observations provided the explanation. Most inspectors were male industrial workers operating under time pressure, where every interaction needed to be accurate on the first attempt.

Adjustment

I increased touch target sizes and expanded the spacing between interactive elements to better match the realities of industrial field work.

The Lowest Upfront Cost Isn’t Always the Best Long-Term Decision

During the pilot phase, QR codes were printed on paper stickers to enable rapid deployment at minimal cost.

After evaluating the operating conditions inside the factory, I realized those labels would gradually deteriorate, reducing scan reliability and increasing long-term maintenance effort.

Adjustment

Instead of standard paper labels, the project adopted engraved metal QR tags to improve durability and reduce replacement costs throughout the equipment’s lifecycle.

There was another reason behind this decision. In an industrial environment, the physical equipment and supporting infrastructure are highly visible to both executives and customers. A durable metal QR tag not only performs better over time—it also reinforces confidence in the quality and professionalism of the overall system.

9. UI Design

App for Factory Equipment Inspectors

App for Maintenance Technicians

Back Office for Managers and IT Administrators

App icon

10. Results

Phase 1 Outcomes

Impact on Users

No more paperwork or manual file management: The entire inspection workflow is completed within a single application, with data stored automatically.

Reduced checklist errors and reporting mistakes: After scanning a QR code, the system automatically identifies the asset and displays the correct inspection checklist.

Better visibility into equipment conditions in the field: Inspection history, photos, and related information are available during inspections, helping users make more informed decisions when abnormalities are detected.

Better visibility into equipment conditions in the field: Inspection history, photos, and related information are available during inspections, helping users make more informed decisions when abnormalities are detected.

Broader Product Impact

Asset Proof was originally created to solve a specific problem within the equipment inspection process.

However, through the implementation of Phase 1 and continued operational research, the organization recognized benefits that extended beyond the original scope:

• Operational data became standardized and easier to retrieve.
• Manual processes were significantly reduced.
• A reliable data foundation was established to connect inspection, maintenance, and operational management in future phases.

These outcomes helped the organization recognize the broader value of digital transformation and created momentum for improving other operational processes.

What began as an equipment inspection solution evolved into a platform that enables operational improvement through trusted data and technology.

Reflections on Asset Proof

1. The User Problem Is Only the Beginning—Not Always the Entire Product Problem

The project started as an initiative to digitize paper-based inspection checklists.

Through research, however, the real problem became clear: the organization didn’t simply need to record inspection results—it needed operational data that was accurate and trustworthy enough to support business decisions.

A product’s scope should be defined by the problem it needs to solve, not only by the initial request.

For AssetProof, equipment inspection was never the final goal. It was the starting point for solving a much broader operational challenge.

2. A New Domain Isn’t Intimidating When Your Product Foundations Are Strong

AssetProof was my first project in the industrial sector. It reinforced an important belief for me: a Product Lead’s core strength isn’t measured by the number of industries they’ve worked in. It comes from the ability to understand complex systems quickly, ask the right questions, and transform ambiguity into structured solutions.

When those foundations are in place, a new domain stops being a barrier—it becomes an opportunity to learn, explore, and create meaningful impact.

3. Transparency Matters More Than a Perfect Timeline

During the project, there were moments when the team fell behind schedule.

I realized that clients don’t only value an on-time delivery. They also value transparency when plans change, expectations shift, and timelines are affected.

Open communication about what happened, why it happened, and how the team is responding builds far more trust than maintaining a perfect timeline on paper.

Everything above shaped AssetProof into far more than a checklist digitization project.

It became a product that transformed operational data from something that was merely recorded into something the business could genuinely trust.