Case Study · 01
Major Industrial
Problems Tracker
Redesigning a tool people were quietly ignoring — and turning it into one they actually chose to use.
Case Study · 01
Redesigning a tool people were quietly ignoring — and turning it into one they actually chose to use.
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.
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 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.
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.
Detail View
Granular metadata entry form — aircraft type, assembly stage, priority classification, and initial root cause assignment.
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:
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.
Recreated in Figma for portfolio purposes — same layout and interaction logic as the production tool, with placeholder data replacing confidential Airbus content.
Platform Constraints
Palantir Slate's JavaScript and component library restrictions meant the shipped interface was a simplified version of this design — not every interaction pattern below survived the handoff.
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.
A tool scanned fifty times a day by the same people does not need a pretty style guide. It needs consistency rules that still hold when someone is tired, late, and looking for one row in a two-hundred-row table. This section is the thinking behind the colors, type, and row states — grounded in how engineers actually used the screen, not how a brand deck would present it.
Status is the first column people read after the ID. Five states, one shared ramp with Priority — because learning two color languages for the same urgency spectrum is a tax nobody should pay during triage.
Blue marks intake, not urgency. A new ticket needs attention in the next triage pass — not an interrupt of whatever someone is doing right now. Cool hue, low emotional charge.
Non-color signal: Outline circle icon + “New” label text. Color is secondary.
Amber is the working color of the whole tool — primary actions, active pipeline steps. If a row is being owned by someone, it should share that same “in motion” signal so status and action language stay aligned.
Non-color signal: Filled-dot icon + “In Progress” label. Never amber alone.
Violet sits between “still open” and “done.” Mitigation means risk is contained but the structural fix is not finished — a holding state that should not look like closure or like a fresh fire.
Non-color signal: Pause icon + label. Distinct shape from New and Closed.
Green is reserved for completed work that survived the pipeline. Engineers scanning for open risk need closed rows to fall into the visual background fast — success, not attention.
Non-color signal: Check icon + “Closed” text. Green reinforces, never replaces, the label.
Red is the only interrupt color. Every other state can wait for the next triage pass. Recurring means the same failure came back after closure — someone has to drop current work and look now.
Non-color signal: Warning triangle + “Recurring” / “Escalated” text. Highest visual weight in the set.
Priority reuses this exact ramp (low → blue, medium → amber, high → red) instead of a second palette. An engineer scanning 50+ rows a day already maps color to attention cost. Introducing a parallel language for priority would force a second decode on every pass — and under time pressure, that decode gets skipped or misread. One ramp, two fields, same meaning: how hard does this interrupt the current work?
Color is never the only signal. Every status ships with a distinct icon shape and a readable label. That matters for color vision deficiency and for factory-floor lighting where amber and green collapse into each other. If you turn the colors off, the row still tells you what state it is in.
Four levels. Not because design systems love fours — because the tool has four distinct reading jobs: orient, section, scan rows, ignore noise.
Type scale — 4 levels
Title
22 / 28 px
MIP-2847 · Skin fastener mismatch
Re-entry anchor. Someone opens the tool after days away and needs the problem identity to register before they start reading fields.
Section header
15 / 22 px
Root Cause & Impact
Splits dense forms into scannable chunks. Big enough to catch the eye when scrolling a long detail panel, small enough not to waste vertical space Slate already struggles to give you.
Table body
13 / 18 px
FAL · Station 42 · A320 family
The daily surface. Sized to keep roughly 15–20 rows visible without scrolling on a laptop — the actual triage viewport engineers work inside.
Metadata
11 / 16 px
Updated 2h ago · Owner: L. Martin
Secondary facts that should not compete with status or title. If metadata shouted at body size, the table would feel like fifty equal-priority lines.
The jump from title to table body is intentional. Titles need enough weight to act as landmarks when someone re-enters after days away. Body text has to stay small enough that a dense triage view still shows ~15–20 rows without scrolling — otherwise the “overview” stops being an overview and becomes a paging chore. Metadata drops another step so ownership timestamps do not compete with the problem statement.
Losing your place in a long table while a detail panel is open is not a hypothetical annoyance. It is the exact frustration of cross-referencing a form against a 200-row list. Selected has to survive that split view.
Table row states — click a row
| ID | Problem | Status |
|---|---|---|
| MIP-2811 | Sealant void — wing root | Closed |
| MIP-2847 | Skin fastener mismatch | In Progress |
| MIP-2852 | Harness abrasion at frame 28 | New |
| MIP-2794 | Door alignment drift (recurring) | Recurring |
Detail panel · selected persists
Skin fastener mismatch
MIP-2847
Owner: L. Martin. The amber edge on the list stays lit while this panel is open — so coming back from a field edit does not mean hunting the row again.
Default
Quiet row — ID, title, badge. No fill.
Hover
Soft white lift. Pointer target only.
Selected
Amber inset edge + tint. Survives split view.
Default stays quiet — borders and type do the work. Hover is a soft lift so the pointer target is obvious without screaming “selected.” Selected uses a persistent amber edge and tint that stays visible while the detail panel is open beside the list. That is the same reasoning as the triage fields: every visual cue maps to how engineers actually move through problems — pick a row, keep it marked, read the detail, come back without hunting.
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