Product Management
Pressure-tested scope and sequencing — what “MVP compliance” means vs. operator trust, and which metrics prove we didn’t just ship UI.
Percepto AIM · Focused study
Remote ID: from business blocker to a shippable cross-device journey
How I anchored on product OKRs and US regulation, interviewed operators in the field, and partnered with PM, Support, and Engineering to map the opportunity and de-risk architecture before engineering locked a build path — then explored high-fidelity UI against that shared system model.
Regulatory & product strategy
Stakeholder alignment
US user research
Systems & flows
B2B / enterprise
3
US operator interviews
PM · Support · Eng
Core partners on discovery
US RID
Compliance & salability driver
Several
Architectures & ship concepts
Context
Initiative ownership inside a regulated enterprise product
Remote ID wasn’t a small UI tweak — it was a go-to-market gate for AIM in the US. My job was to turn regulation and internal OKRs into something operators could execute under pressure, on more than one device, without breaking mission continuity.
How I positioned the role
Embedded product designer — initiative lead for Remote ID UX (discovery → flows → documented states for build)
Company & product
Percepto · AIM (autonomous inspection & monitoring)
Why this mattered to the business
Align product to US regulation — unlock legal salability and operator trust
Discovery stack
Workshops with PM, Support, Engineering · operator interviews · annotated journey maps · solution/risk matrix
Business & product framing
Start from the OKR — not from the wireframe
Before user flows, I aligned with Product on the real business problem: without compliant sharing of operator and aircraft location, Percepto couldn’t claim a complete US story. That framing turned “checkbox compliance” into a product and revenue constraint the whole squad could reason about.
We treated success as observable behavior + operational reliability, not just “feature shipped” — e.g. location data present for flights, and fewer mission interruptions caused by missing Remote ID data.
Research & empathy
Three US operators — behavior under pressure, not only opinions
What I needed to learn
How operators actually move through launch when something “mandatory” arrives mid-flow: phone in pocket, sun on glass, incomplete mental model of why the SMS exists, and zero patience for opaque waits.
What I did with it
Synthesized behavioral themes into requirements for timing, messaging, and recovery — where AIM must explain state vs. stay out of the way — and fed that back into the swimlane so Support and Engineering could challenge edge cases early. The full AIM case study shows how the same practice paired with Power BI preflight analytics and post-interview empathy maps (Says / Thinks / Does / Feels) to define problem severity alongside qualitative insight.
Themes from US interviews (synthesis)
- Interruptibility: Remote ID arrives mid-launch — operators need to understand why in seconds, not read a manual.
- Trust & automation: tension between speed and confidence (“will this make me miss a leak / a failure?”) — copy and state visibility must earn trust.
- Recovery: weak GPS, denied permission, or aborted steps must map to clear next actions in AIM and in the field, not dead ends.
- Cross-device mental model: SMS → browser → back to AIM has to feel like one mission, not three products.
Cross-functional discovery
Mapping the opportunity with PM, Support, and Engineering
Remote ID sits between policy, infrastructure, and frontline support load. I facilitated working sessions to get a shared picture of triggers, failures, and responsibilities — who owns the SMS, what happens when GPS is weak, how operators recover without abandoning the drone on the pad.
Support
Surfaced real failure language and workaround paths — the material for error copy, help surfaces, and what “success” looks like on a bad day.
Developers
Grounded flows in system truth — disabled takeoff until GPS, async SMS delivery, correlation between mobile approval and AIM state.
Systems thinking
Two interfaces, one mission — making the handoff explicit
The deliverable that moved alignment fastest wasn’t visual polish — it was a shared map of parallel states: AIM waiting, mobile completing Remote ID, and the moment takeoff unlocks.
Scroll horizontally to read each diagram at full width
Direction & tradeoffs
Comparing solutions on value, viability, usability, and feasibility
Lead-level craft shows up when you name risks before pixels. Below, three architectures are broken into scannable tradeoffs (instead of a dense workshop bitmap). Each option included a discovery task before we committed eng.
Option 1
Secondary device — SMS link journey
SMS with a link to approve Remote ID and share phone GPS while AIM waits on the primary session.
- Value risks
- Link opened on wrong device; office vs. field location; battery and attention.
- Viability
- Consistent mobile-web behavior across OS versions.
- Usability
- Operator notices SMS, understands why location is needed mid-launch, can recover if dismissed.
- Feasibility
- GPS accuracy; tight correlation between mobile approval and AIM state.
- Discovery
- Device matrix checks (iOS / Android) with Engineering.
Option 2
Two dedicated URLs
One URL to activate Remote ID / location, another for secondary control — redirect once location is trusted.
- Value / viability
- Similar surface area to Option 1; more session coupling across two entry points.
- Usability
- After redirect, operators need visible Remote ID status — not a dead-end secondary shell.
- Feasibility
- Same GPS and permission edge cases as Option 1.
- Discovery
- Redirect + failure prototypes with PM; scenarios with Support.
Option 3
Desktop browser location
On AIM desktop, the browser asks for location approval; AIM submits operator position without a parallel SMS path.
- Usability
- Reduce repeat prompts; still surface when sharing is active for compliance clarity.
- Value
- Fewer handoffs — weaker if real-world ops are always mobile on site.
- Discovery
- IT/browser policy review + field interviews on desktop vs. phone reality.
View original workshop matrix (image)
Solution proposal
Parallel concepts: combined wizard, Remote-ID-first URL, and roadmap
After aligning on OKRs, KPIs, preflight data, interviews, and swimlanes, I drafted multiple viable architectures so Product and Engineering could trade off velocity, operator trust, and implementation cost: (A) a single wizard URL for Secondary + Remote ID, (B) a dedicated Remote ID URL that collects location approval first and then redirects to Secondary, plus (C) a future track for clearer in-product status and notifications.
Proposal A consolidates both services into one guided browser flow — modal education, secondary login, then Remote ID permission in sequence. Proposal B optimizes for a clear compliance checkpoint up front: SMS opens the Remote ID experience, the operator approves location (or cancels — which terminates the launch mission in AIM), then the browser redirects to Secondary for the rest of the handoff. Both needed better SMS and deep-link trust; Proposal B leans on faster-to-ship native browser dialogs in places, at the cost of polish and brand continuity.
Proposal A — single URL wizard
Phase 1 (ship path)
- Activate: operator receives SMS from Percepto with link to open the wizard (staging URL / token pattern in early builds).
- Wizard step 1 — Secondary control: plain-language context, password field, inline error on invalid credentials, Connect stays disabled until validation succeeds, then establishes the trusted link back to AIM.
- Wizard step 2 — Remote ID: explains that AIM needs location through the mission for regulatory sharing; system permission sheet + optional “Don’t ask again” where policy allows.
- Both capabilities in one linear flow so PM, Support, and Engineering share one state model.
Future / phase 2+
- Remote ID service status surfaced clearly in AIM — not only “green check at wizard exit.”
- Notifications when compliance or secondary connection state changes mid-mission prep (retry, reconnect, escalation paths).
- Continued iteration on messaging, link branding, and recovery to reduce support load and operator anxiety.
Proposal A — high-fidelity wizard: SMS → secondary → Remote ID
Direction for the combined flow: activation message, then secondary / password (disabled CTA until valid), then Remote ID framing and location permission in branded UI.
Proposal B — Remote ID URL first, then secondary
Dedicated Remote ID link → approve location → redirect
In this pattern the operator receives an SMS with a unique Remote ID URL. Opening it surfaces a Remote ID modal: explanation, clear CTA to approve sharing location for FAA-related data, and an explicit cancel path that aborts the action — with the launch in AIM configured to terminate the mission launch if the operator backs out (same systemic risk called out in swimlanes). After approval, the session redirects to the Secondary URL for login / secondary-control completion (wizard or native prompts depending on build).
Flow summary
- Activate: SMS from Percepto with Remote ID link.
- Approve Remote ID: in-browser (or in-app webview) — explanation + CTA; operator must allow location; optional “Don’t ask again” pre-checked where policy allows (validated with Legal/PM — default-on can reduce friction but needs informed consent).
- Deny / cancel: operator can refuse location or cancel; mission launch does not proceed.
- Success path: after location approval, redirect to Secondary for credential step and connection back to AIM.
- “Default browser” variant: use the native location / prompt surfaces for speed — paired with short instructional copy; longer-term, replace with fully custom UI for trust and accessibility.
Reference screens: browser-hosted Remote ID permission, a lightweight browser-native password dialog
on Secondary (same family as prompt() — fast to implement, weaker branding and accessibility), and a
mobile-styled bottom sheet showing the same location decision in a Percepto shell.
Phase 1 decision (final)
Custom HTML modals for a clearer B2C-grade experience
For Phase 1, the decision was: custom HTML modals (a more B2C-style experience) for every step we own — education, recovery, and handoff — while the default built-in browser/OS location permission stays exactly that: not recreated or “designed” as rendered HTML, because the platform owns that surface. After alignment, a visual polish pass on the HTML modals was scheduled on the roadmap.
Remote ID URL — scenario map
- (1) Location not shared / blocked. Browser hasn’t been allowed to use location (or access is off). Show a custom modal that explains the constraint and points users to device/browser settings to continue.
- Authorized only via native prompt (no Percepto screen). When the user approves location through the built-in browser permission dialog, we add no extra designed UI in HTML for that moment — the OS/browser owns approval.
- (2.1) User taps Deny. Close the native prompt; open a new in-page alert that explains why location is required to launch on AIM and what to do next.
- (3) Location authorized. User proceeds directly into the secondary interface (live mission / secondary shell) — the success path.
- (4) No GPS capability. URL opened on a context that can’t provide location (e.g. unsuitable device). Custom modal: “GPS not recognized” with instruction to open the secondary link on a mobile device so location can be granted.
Screens below: representative HTML modals and success handoff for scenarios (1), (2.1), (3), and (4).
Outcomes & impact lens
What “good” meant for Remote ID
Targets
Success criteria from the product brief (not post-launch results)
Product defined “good” as: drone + operator location shared for flights as required, and no cancellations driven by missing Remote ID data — the bar we designed and debated against, with Legal and PM.
1
Shared system model
Squads could argue edge cases against one map instead of three versions of the truth.
3+
Scored options
Matrix paths plus A/B ship concepts — explicit risks and discovery tasks per route.
This page covers discovery → options → Phase 1 decision (custom modals + scenario map) and related UI exploration. Broader AIM tracks (preflight checklist, mission authoring, metrics) live in the full Percepto AIM case study.
Lead takeaway
Why this story maps to team-lead expectations
“Compliance UX is stakeholder UX.” If Remote ID failed, Legal, Support, and Sales all paid the cost. My job was to make the abstract regulation concrete enough for everyone to commit — then make operators successful inside that frame.
“Flows before mockups.” When takeoff is disabled until GPS lands, the product is a state machine. Leading the initiative meant owning that clarity before arguing gradient tokens.
“Research density over research volume.” Three thoughtful US interviews + triangulation with Support beat a dozen shallow surveys for this class of problem.