Turning field work into field intelligence
WEBSITE
CLIENT
Fluix / Readdle
Fluix is an inspection management platform used by 12,000+ field teams across construction, energy, utilities, and aviation. Inspectors run safety, equipment, and compliance checks on mobile and tablet — often offline, on a turbine, a rig, or a construction site — while supervisors track findings, corrective actions, and audit readiness from the web. I spent [X months] on the product design team, working across iOS, Android, and web, on the inspection flow, the manager-facing dashboard, and the design system that ties all three surfaces together.
ADMIN DASHBOARD / MOBILE INSPECTION
Paper doesn't scale, and neither did the first digital version
43%
faster inspection completion after redesigning the checklist flow around conditional logic and single-tap pass states.
increase in issue-to-resolution throughput after restructuring the Task Board and reworking how submissions route to reviewers.
Field inspection is a job done in the worst possible UX conditions: wind, rain, gloves, glare, no signal, and a supervisor waiting on a report. The industry standard for decades has been paper checklists — sloppy handwriting, lost folders, no visibility until the binder gets driven back to the office.
Fluix had already solved the "get off paper" part of that problem. The next challenge was harder: making the digital experience actually faster than paper on a good day, and dramatically more useful on a bad one. That meant designing for two very different users at once:
Design system — rebuilding the foundation while the house was occupied
4
platforms unified under a single token-driven design system — iOS, iPadOS, Android, and web.
tertiary tones built for tags, task states, chart series, and priority levels — tuned to sit next to each other without vibrating.
Fluix ships on iOS, iPadOS, Android, and web — one product, four native contexts. Any design system change has to land in all of them without breaking the muscle memory of teams who run their workday on it.
The starting point was a legacy system built for a different era: components inconsistent between the Admin Portal and the mobile app, tokens not unified, native paradigms on iOS and Android drifted from the web app. It worked — but it wouldn't carry the product into denser reporting surfaces, richer data visualization, and the softer, layered treatment of a more glassmorphic visual direction.
Then the brand refresh landed. A new palette leaned on high-energy, highly saturated hues — the hero color is a near-fluorescent yellow-green, #EBFA00. A fantastic marketing color: it stops the scroll, it's unmistakably Fluix, it photographs beautifully on a billboard. Almost unusable in a dense product interface. At full saturation it fails contrast against white, creates severe visual fatigue on data-heavy screens, and fights every semantic color the system needs — a safety-critical "fail" state cannot compete with the brand color for attention.
The challenge became: how do we keep the feeling of the brand without leaning on the color that defines it? The answer wasn't one thing — it was a system. Reserve the hero color for moments, not surfaces. Build a family of desaturated neighbors that carry the brand's warmth without the intensity. Anchor the semantic palette independently of brand. Expand the tertiary layer aggressively — 20+ tones tuned to sit next to each other in a dense report without vibrating, while still feeling unmistakably part of the Fluix world.
Key Features
Four features define what "field intelligence" means in Fluix — and shaped every design decision in the project.
Projects. The structural backbone. A single container per job — tasks, forms, corrective actions, participants, files. Inspectors see only what's relevant to their site; supervisors see the full picture.
Conditional logic in forms. The hero interaction. A passed item stays a single tap; a failed item auto-expands to require photo, severity, and note. Checklists behave like a conversation.
Automated reporting and dashboards. The Admin Portal side. Reports generate on submission, pre-formatted for auditors and clients. Dashboards surface delays, recurring failures, and open corrective actions across every site.
Auto-sync. The trust layer. Work offline all day; sync the moment signal returns. A persistent indicator tells the user exactly where their data sits — local, queued, or confirmed.
Two products, one seamless system
Fluix isn't one app on multiple platforms — it's two products, tightly coupled around a shared source of truth. The Admin side is where the entire workspace gets built: workflows configured, forms authored in the Form Builder, participants and groups defined, permissions set, storage routing chosen, integrations wired up. Nothing happens in the User app that wasn't first shaped on the Admin side. The User side is where the field actually happens: tasks completed, forms filled, photos captured, signatures collected, findings routed for review.
Both surfaces run on iOS, iPadOS, Android, and web — no platform is exclusive to one role. In practice, admins gravitate to desktop because configuration is a dense, screen-heavy activity, and field users gravitate to mobile because that's where the work is. But an admin can review a submission from an iPhone waiting at an airport, and a supervisor can build a new workflow from an iPad on-site. The system doesn't pick your role by device — it lets you switch between them seamlessly, from anywhere.
This dichotomy is the structural principle of the entire product. Every design decision — the Task Board, the reporting layer, the sync model, the permissions system — falls into place once you accept that Fluix is one system serving two very different jobs.
In closing
Fluix taught me that the hardest problems in field product design aren't visual — they're semantic and structural. What does saved mean when there's no signal? How do you serve two roles inside one system without compromising either? How do you carry a brand through a product interface when the brand color itself resists product use?
None of these questions have clean answers. Each one produced a system of trade-offs — some visible in the UI, most invisible but load-bearing.
What I take from the project: the quality of a field-ops product is defined by the worst 10% of its usage conditions — bad weather, no signal, gloves, urgency — not the easy 90%. A design system is only as durable as the tokens beneath it, not the components on top. And a two-role product is only credible when both sides feel first-class, not when one is treated as an appendix to the other.
The mockups, videos, and interactive prototype above are the surface. The decisions behind them — Saved vs Synced, brand vs product palette, admin vs user hierarchy — are the foundation.