Case Study · 01
Major Industrial
Problems Tracker
Redesigning a tool people were quietly ignoring — and turning it into one they actually chose to use.
B2B Product DesignWorkflow OptimizationHigh-Density UIAirbus
Major Industrial
Enterprise Context
This tool lives inside a regulated production environment. Real interface screenshots are restricted under corporate data classification policy — standard practice for aerospace enterprise software. What you'll find here instead: the design thinking, the system architecture, and the outcomes. Annotated wireframes and process artifacts are available on request.
The Challenge
Nobody was breaking any rules. They were just quietly going around them. A problem-tracking application already existed — hosted inside the company's data platform, technically functional. But engineers on the Final Assembly Line were maintaining their own Excel spreadsheets in parallel. That's the real warning sign in enterprise software: not crashes or error messages, but the polite, silent workaround. People finding something easier and saying nothing. The task wasn't to build from scratch — it was to understand exactly why the original had failed, then design something good enough to make people close the spreadsheet for good.
Main Dashboard
Centralized high-density overview of all active industrial problems — FAL priority sorting, status lifecycle, and team assignment.
The UX Solution & Architecture
The first step was going to Toulouse — not to present anything, but to listen. Sitting with the teams who actually worked on the assembly line gave a clear picture that no requirements document could: the real ecosystem, the unspoken workflow habits, and the business logic behind the resolution process. That trip shaped everything. The design started in Figma — presented, challenged, revised in review sessions — then handed off to the development team for implementation in Palantir Slate, the low-code application layer inside the company's data platform. The role throughout was to keep the UX logic intact across the handoff: making sure what was designed was also what got built.
1
Contextual Capture & Triage
Assembly lines generate a lot of noise. Problems get logged, buried, and rediscovered weeks later by a different engineer who has no idea the issue already has a history. The triage layer was designed to cut through that — engineers assign key parameters like priority level, aircraft type, and the specific assembly stage where the issue occurs. Those inputs aren't bureaucracy: they're the filtering logic that determines who sees this problem, how urgently, and in what context. Every field was defined based on how engineers actually talked about problems — not how a requirements doc described them.
MIP Detail View
Granular metadata entry form — aircraft type, assembly stage, priority classification, and initial root cause assignment.
2
The Resolution Pipeline
This was the core of the whole product. If a structural misalignment keeps appearing at the same station, cycle after cycle, it can't just be patched and closed — it needs to escalate. The resolution logic was already defined internally (based on established industrial problem-solving frameworks like Stage-Gate and DMAIC adapted for aerospace). The job was to make that logic feel inevitable and visible in the interface — not hidden in a process document. Every problem moves through a fixed sequence:
Root Cause
Mitigation
Solution ID
Deployment
Closure
If a problem keeps coming back after closure, it escalates to a dedicated steering committee. Budget gets allocated. The problem gets solved once, for good. The pipeline in the interface isn't decoration — it's the thing that prevents a ticket from quietly disappearing and reappearing six months later.
Edit / Create Form
Stage-transition enforcement — the interface only allows forward movement through the resolution pipeline, preventing out-of-protocol state changes.
3
Retaining Historical Impact
The most expensive mistake on an assembly line isn't making a mistake — it's making the same mistake twice. Without a structured record, senior engineers carry years of institutional memory entirely in their heads. If they move teams, retire, or are just not in the room, that knowledge disappears. The tool required documenting not just what happened, but what was tried, what worked, and what the actual operational impact was. Over time, that turns into a living knowledge base — one the whole department owns, not just the people who were there the last time.
Result
The tool was adopted widely enough that it eventually outgrew its original platform. After proving itself in Palantir Slate, it migrated to Palantir Workshop— a more capable low-code environment — where it lives today. That kind of migration doesn't happen to tools people tolerate. It happens to tools people actually rely on.
Slate → Workshop
Tool trusted enough to graduate to a more capable platform
5-step
Enforced resolution pipeline — no protocol gaps, no silent closures
0 Excel
Parallel spreadsheet workarounds eliminated after rollout
Explore more
Back to Portfolio