Case Study 01

AI-Powered Service Reporting

Redesigning field documentation for industrial teams by turning a 30-minute burden into a 5-minute voice workflow.

CompanyKNOWRON
RoleSenior Product Designer (Lead)
PlatformB2B SaaS · Mobile + Web
Team2 Designers · CPO · 4 Engineers
0%
Reduction in reporting time 30 min → 5–8 min
0
New pilot clients secured via feature pivot
0
Most-used feature after AI search voice knowledge creation
Click to expand

This page is a highlight reel. For a deep dive into how I framed the problem, managed strategic tradeoffs, and collaborated with the engineering team, explore the comprehensive process deck.

View Full Case Study
The Problem

Technicians weren't using the reporting system.

Reporting in industrial organizations remains a largely manual and fragmented process. Despite the push for digital transformation, many field technicians still rely on paper-based workflows where reports are handwritten, printed, scanned, and emailed. This leads to chronic delays and incomplete documentation, leaving managers with inconsistent data that is impossible to analyze or act upon. To address this, KNOWRON introduced a digital logbook feature within its app, designed to streamline data entry. However, because the feature only supported input as a single, unstructured block of text, it failed to gain traction with technicians and lacked the necessary structure for meaningful reporting.

The lack of adoption was a design problem rather than a lack of willpower. Several issues persisted across both manual and digital processes, including a multilingual workforce struggling to type in non-native languages and the burden of filling out repetitive fields across 30 different report variations. Furthermore, because there was no way to report in the flow of physical work, the digital logbook remained an administrative hurdle rather than a helpful tool.

Technician pain
Typing is friction
Often wearing gloves, working mobile. Delayed reporting meant memory gaps and missed detail.
Language barrier
Non-native input
Technicians in multilingual teams faced significant friction when filling out reports because they often think in their native language but are required to document their work in the company's primary language.
System problem
25–30 field variations
No consistency across templates. Required fields were routinely skipped.
Manager pain
Manual everything
Template creation, distribution, and review all done by hand. High effort, low quality.
Approach

Structured thinking under speed.

With a pilot contract on the line and limited user access, I used the Cynefin framework to navigate the ambiguity. This wasn't a complex domain requiring experimentation, it was a complicated one requiring analysis. Sense, analyse, respond.

Click to expand
01
Mapped workflows before designing
Used internal knowledge including CS teams, existing reports and business context to understand current state before touching a design tool.
02
Dogfooding as a research proxy
With no access to real users, we simulated the maintenance workflow using our office coffee machine as a test case. This helped us detect real friction super fast.
03
Scope reduction as a strategic move
Dropped the manager template builder entirely. Technician adoption was the adoption bottleneck. Manager templates were hardcoded to unblock speed.
mediaClick to expand
Solution

Voice-first, AI-structured reporting.

The core insight: technicians speak faster than they type, and speak their native language. The solution was an AI-powered voice input layer where technicians describe the work in any language, and the AI maps their speech to structured report fields automatically.

Voice input, any language
Speak freely in your native language. AI handles transcription and field mapping.
Auto-fill + gap highlighting
Repetitive fields populated automatically. Missing required fields surfaced before submission.
Human review before submit
AI does the heavy lifting and the technician confirms. We knew trust and accuracy could not be compromised.
Non-linear completion
No forced field order. Draft saving lets technicians report in the moment, and move away when they need to without having to finish it in one setting.
Click to expand
Outcome

How we fixed reporting and turned it into a new product strategy

Reporting time dropped from ~30 minutes to 5–8 minutes and report quality improved. More consistent, fewer missed fields, usable data for managers. The pilot contract was secured.

The pivot
When the reporting feature was deprioritized, the core insight wasn't.
The client's internal changes shelved the reporting feature but voice input had already proven itself. We applied the same interaction model to knowledge article creation. It became the 2nd most-used feature on the platform after AI search, drove adoption, and contributed to 8 new pilot clients. A feature that looked like a dead end became a product foundation.
Reflection

What I'd do differently.

"Looking back, I would have pushed harder for direct user access much earlier. Even a single session with a real technician would have sharpened our hypotheses faster than any internal simulation. While dogfooding provided some value, real-world context is irreplaceable. On the flip side, I learned to trust strategic scope reduction. Cutting the manager builder was the right call because it allowed us to test adoption before investing more time and effort into the build."

This page is a highlight reel. For a deep dive into how I framed the problem, managed strategic tradeoffs, and collaborated with the engineering team, explore the comprehensive process deck.

View Full Case Study
KNOWRON · Senior Product Designer
AI-powered SaaSIndustrial UXVoice interfacesB2BMVP strategyDesign under constraintsHuman-in-the-loop AIAdoption-focused designSystems thinkingRapid validation