The challenge

They had a 68-page technical proposal naming four business modules, four backend systems and one identity layer. What it did not have was any evidence that a pilot would experience them as one product rather than four apps sharing a password.

The solution

The fix was to stop designing as four modules in a menu and start designing as one pilot lifecycle: discover, learn, try, own, compete.

That shifted the problem from navigation to continuity. I focused on the hardest handoff, from course completion to race entry.

The solution was to stop designing as four modules in a menu and start designing as one pilot lifecycle: discover, learn, try, own, compete.

It shifted the problem from navigation to continuity. I focused on the hardest part, from course completion to race entry.

My role

Sole Product Designer, independently leading research, information architecture, the cross-module interaction model, and the visual system. I also built a working React prototype, used as a research instrument to test the journey, not as a production deliverable.

Drag sideways

34%

Of pilots who completed a course registered for a race within 60 days

vs <10% estimated pre-platform

58%

Opened at least 3 of the 4 module tabs in their first week

Proxy for "does this feel like one product"

311 / 480

Activated accounts in the first three months (65%)

Instrumented

SUS 71.2 to 81.4

Across two testing
rounds

-
Across two testing
rounds

The one call that mattered

The real problem wasn't navigation, it was continuity between Learn and Race. Build the connective tissue between the four modules, not the modules themselves.

The one call that mattered

The real problem wasn't navigation, it was continuity between Learn and Race. Build the connective tissue between the four modules, not the modules themselves.

Context & Brief

A WhatsApp group, a spreadsheet, and a 68-page proposal.

Falcon Circuit started as forty pilots in an Abu Dhabi WhatsApp group and a leaderboard someone maintained by hand. Rashid, a former competitive pilot, raised a seed round to turn that into a platform, and hired an engineering vendor who produced a technical proposal I still treat as ground truth: Magento for the store, Moodle for the academy, a Spring Boot events service, Keycloak issuing one identity across all of it.

It is a good document. It specifies four modules, their data models, their queues and their deployment. What it does not contain, because it is not that kind of document, is any account of what a pilot does on a Tuesday. I was brought in after it was finalised and before Phase 1 infrastructure work began in earnest, which is the only window where IA decisions can still change the identity model and the API contracts instead of being retrofitted around them.

What existed before I started

Technical proposal

68 pages

Business modules specified

Identity layer

Keycloak SSO / OIDC

Designs

Validated user journeys

Community on hand

~40 pilots

"I don't want to build a store, a rental company, a school, and an events company. I want to build a place where someone becomes a pilot."

Rashid

- Founder & CEO, on our first call

That line became the actual design brief. I was brought in for a design-validation sprint, run in parallel with the vendor's own Phase 1 MVP build, specifically so the cross-module interaction model could still shape the Keycloak role structure and API contracts instead of getting retrofitted after the fact.

Market & competitive teardown

Nobody bundles all four. That is the opportunity and the risk.

Regulatory ground

Two constraints, two specific product decisions.

Regulatory ground

Two constraints, two specific product decisions.

Not an "enterprise-grade security" gesture. Each of these forced a decision I can point at in the interface.

Dubai is worth a footnote because it is routinely reported wrong. DCAA directive DCAD-2025-00007 does not ban recreational flying in the emirate: it defines approved zones, mandatory registration, a per-flight authorisation code, and an observer requirement specifically for FPV goggles. Genuinely restrictive, not a blanket ban. It is the reason our calendar sits mostly outside Dubai, and the reason the qualification gate has to understand where you are flying, not just whether you are certified.

GCAA

Drone regulation - Jan 2025

Approved training and drone registration required regardless of weight, flight banned within 5 km of any airport, and recreational flying confined to approved zones.

Decision it forced

Pilot-qualification validation runs before a rental or a race registration confirms, not after payment. The gate is the same component in both flows, which is why it behaves identically.

PCI DSS

Named in the proposal

Card data never stored client-side, the app holds a provider token only.

Decision it forced

Shop checkout and the Rent deposit-authorisation lifecycle share one payment surface. A deposit hold and a purchase look different to the user and identical to the system.

Discovery & research

I asked pilots to show me their Saturday.

Participants: 4 pilots, 2 prospective renters, 3 stakeholders

30–45

Minutes per session, semi-structured, moderated, think-aloud

Day diary study with timestamped notes as pilots switched tools.

Competitor products torn down heuristically, across all the 4 verticals

Who I talked to

4 hobbyist and community pilots, beginner through advanced, UAE residents aged 19–44, recruited through the existing 40-pilot group.

2 prospective renters who own nothing yet, 1 resident and one short-stay visitor who wanted a day's rental and a guided flight.

3 internal stakeholder, Rashid (CEO), Omar (Academy), Sara (Events), each of whom owns a different module's P&L

Plus a service-blueprinting session with those three, mapping buy, learn, rent, and race, end to end for the first time.

What I asked

"Walk me through the last time you decided to enter a race."

Open

"How did you learn what you know? Who taught you?"

Open

"How many apps or groups did that take?"

Counted

"What stopped you the last time you nearly booked something?"

Open

"Where does your race history live right now?"

Open

Four findings that set the scope

Pilots run three to four tools to do one thing

8 / 9

A retailer's website for parts, a WhatsApp group for race news, informal in-person coaching, and sometimes an Instagram DM for rentals. Nothing shared identity or history. The diary study caught the switches as they happened rather than as remembered.

Beginners had no visible on-ramp

7 / 9

Renting or buying before any training felt backwards to them, but nothing connected "I want to try this" to "here is a beginner course, and a rental you can use for it.

Renters could not tell if they were allowed to fly

6 / 9

Especially the short-stay segment. GCAA and DCAA rules diverge, and the moment that became confusing, people abandoned the research entirely rather than risk it.

Every event felt like starting over

6 / 9

Registration lived in a spreadsheet, and results were posted and forgotten. No pilot owned a persistent record of what they had done. Khalid, chasing his first sponsorship, had nothing to show anyone.

Secondary research

I audited the experience already in use: the four-tool workaround.

There was no incumbent app to audit. So I audited the thing pilots were actually using: the four-tool stack they had assembled themselves: retailer site, WhatsApp race group, informal coaching, DM-based rentals, treated as one de facto product. Six of Nielsen's ten returned violations worth acting on, and every one of them maps to something visible in the final design.

01 · Visibility of system status

Nothing anywhere told a pilot where they stood. Course progress lived in Moodle, race standing lived in a spreadsheet, order status lived in an email.

What It Became

The status line under the greeting, "1 ongoing course - 2 new races this week", plus a weekly progress ring. State is the first thing on the screen, not something you navigate to.

02 · Match to the real world

The tools were organised by business: a shop, a group, a calendar. Pilots think in terms of a progression: I'm learning, I'm ready, I'm competing.

What It Became

Courses and races share one skill vocabulary. Beginner, Intermediate, Advanced mean the same thing on both sides of the crossing.

03 · Recognition over recall

To enter a race you had to remember the group post, the date, the venue rules and whether you were qualified. All four lived in different places.

What It Became

The event card carries date, venue, tier, difficulty, closing window and remaining slots. Nothing has to be held in the head.

05 · Error prevention

Pilots could, and did, pay for a rental or a race entry they were not legally qualified to use, and found out afterwards.

What It Became

The qualification gate runs before confirmation, in both flows, as the same component. You cannot buy your way past it.

07 · Flexibility & efficiency

A returning pilot and a first-timer got exactly the same undifferentiated wall of content.

What It Became

The Academy home leads with whatever you already started, and the "For You" rail below it is ordered by what you have completed, not by what is newest.

10 · Help & documentation

Airspace rules lived in a PDF and a government app. Nobody read either at the moment they mattered.

What It Became

Qualification requirements surface inside the booking flow at the point of decision, phrased as what you need rather than what the regulation says.

Who this is for

Three pilots at three different points of the same life.

Composites drawn from the 16-person sample. What matters about this set is not their demographics: it is that they are the same person at three different times. Chloe becomes Yusuf. Yusuf becomes Khalid. A product built as four modules cannot see that. A product built as one lifecycle can.

Yusuf Al Shamsi

27 · One drone, browsing a second

Domain knowledgeMedium

Price sensitivityMedium

Context

Abu Dhabi, marketing exec
Weekend hobbyist, ~1 year in
Buys parts monthly

Goal

Upgrade without wasting money
Get meaningfully better
Eventually enter something

Blocker

No idea whether he is "good enough" yet
Every race he sees looks like it is for someone else

Trigger

Snapped an arm mid-flight at a Saturday meetup and started shopping for the replacement that same night
A pilot at the meetup mentioned a beginner race category he could enter on the drone he was already eyeing

Traits

Spec-drivenReads the spec table first and skips the marketing copy sitting above it
Community-ledTrusts what the Saturday regulars are flying more than any star rating
Progression-hungryWants proof he's actually improving, not just proof he's spending

I've been flying a year. I still don't know if that means I can enter a race or if I'd just be in the way.

Chloe Bennett

34 · Never flown

Domain knowledgeLow

Price sensitivityHigh

Context

British expat, Dubai Marina
Watched a friend race, wants in
Owns no equipment

Goal

Try it once without spending AED 3,000
Not embarrass herself
Know she is allowed to fly

Blocker

Renting before training feels backwards
Airspace rules read as legal risk

Trigger

Watched a friend qualify at the Sharjah Desert Challenge, asked “what do I actually do first?” and got four different answers
Rental research died in an Instagram DM that took three days to get a reply

Traits

Risk-averseWill not book anything until she is certain it is legal where she lives
Research-heavyReads the rules page twice, then messages someone to confirm it
Time-poorWants one straight answer, not four different explanations

I don't want to buy a drone to find out I hate it. But renting one when I don't know how to fly seems worse.

Khalid Mansour

21 · 3 seasons, chasing sponsorship

Domain knowledgeHigh

Price sensitivityLow

Context

Sharjah, competitive pilot
Races informally, wins sometimes
Builds his own quads

Goal

A record a sponsor will take seriously
Never miss a registration window
Rank against real pilots

Blocker

Three seasons of results exist nowhere
Every event restarts his history from zero

Trigger

A prospective sponsor asked for his season record and all he had to send were screenshots
Lost a heat slot because the spreadsheet filled before the group-chat announcement reached him

Traits

CompetitiveLogs his own lap times more carefully than any organizer ever has
Self-taughtSolders his own stacks and reads a spec sheet the way other people read a menu
Reputation-drivenWants a record a sponsor can check, not a highlight reel

I've won things. I just can't prove it to anyone who matters.

The reframe

Four modules is an org chart. Five stages is a product.

The four modules aren't four products sharing a login. They're four stages of one pilot's life, and the app's job is to make that visible without forcing anyone through it in order.

That sentence came out of the blueprinting session with Rashid, Omar and Sara, and it is the single most useful thing the engagement produced. Before it, every scoping conversation was a negotiation between three module owners defending their own surface area. After it, the question changed from "how much space does Academy get" to "what has to be true at the moment somebody finishes a course", which is a question with an answer.

Four of the five crossings were straightforward, because they run downhill: each one is a commercial upsell somebody was already motivated to build. The fifth is different. Learn → Compete is the only crossing where nothing is being sold, which is precisely why it had no owner, and precisely why it is the one this case study is about.

Drag sideways

The problem, quantified

The suspected break. Almost all stopped after course completion.

Sara had run the community calendar for years and could describe the drop-off precisely without ever having measured it. We reconstructed it together from her registration spreadsheets and the course rosters Omar kept. It is an estimate, and I treat it as one, but the shape of it was not in dispute, and the shape is what mattered.

Two different failures, not one

The drop between finishing and looking is a notification problem. Nothing told the pilot anything had changed, so crossing over required them to remember to go and check.

The drop between looking and finding something that fits is not a notification problem, and no amount of prompting fixes it. It is a supply problem: there was nothing on the calendar addressed to the person who had just finished a beginner course. Those two need different solutions, and conflating them is how you end up shipping a nudge at a structural gap.

Where the estimate comes from

Sara's registration spreadsheets and Omar's course rosters, cross-referenced by name across the same period. The final figure, fewer than one in ten course-finishers entering a race within sixty days, is the one number in this table with records behind it.

The step-by-step counts are her reconstruction of how people fell away, not instrumented events. I use them for shape, not magnitude, and the shape was never in dispute between the three people who had watched it happen for years.

What I would not claim.

There is no baseline instrumentation here and there was never going to be, the "before" state was a spreadsheet and a group chat. Everything above is a reconstruction, and I am using it the way a reconstruction should be used: to locate the break and to argue about which step deserves the design effort, not to publish a conversion rate.

Drag sideways

Information architecture

Keep four tabs. Make them talk.

The obvious move, once you have a five-stage lifecycle, is to build navigation around the lifecycle. I tried it, and it was wrong.

Lifecycle navigation vs. four fixed tabs

IA 01

Rejected: lifecycle nav

Navigation that adapts to the pilot's stage: a beginner sees Learn first, a competitor sees Race first. Elegant on a whiteboard. In testing it meant the app moved under people, Yusuf-types could not find the shop they used last week, because the shop had been demoted by their own progress. It also made the four module owners invisible to each other, which is an organisational failure mode as much as a design one.

Shipped: four fixed tabs, cross-aware content

Shop, Rent, Learn, Race stay exactly where they are, always. The lifecycle lives inside them: what each tab shows is ordered by where the pilot is, but where each tab lives never changes. Spatial memory is preserved; relevance is still adaptive.

Race-registration task completion reached 8/8 at round 2, up from 3/8 at round 1, when the nav still adapted

The structure that shipped

The three crossings I built explicitly

Learn → Race : The status line, the completion notification, and tier-matched event surfacing. The subject of this case study.

Learn → Rent : A beginner course names the gear it is taught on, and that gear is rentable in one tap. Chloe's on-ramp.

Race → Shop : An event's class rules link to compliant parts. Khalid's actual buying trigger, which nobody had connected before.

Everything else stayed a plain tab. Three deliberate crossings beat twelve accidental ones: each is a contract two module owners have to maintain, and contracts have a cost.

Drag sideways

Design → code

The build was a research instrument, and it found things.

I established the React validation build myself, in parallel with the visual system, paired with one of the vendor's frontend developers. Its purpose was never to be shipped: the production app is React Native on iOS. Its purpose was to run real content through real states, because that is where a cross-module model either holds or does not. One thing surfaced that a static handoff would have carried into production intact.

Finding 01

01

The calendar had no beginner tier

The catalogue is Beginner-weighted: three of five courses. The race calendar was 100% PRO LEAGUE, two of three ADVANCED. Populate both with real data, put them side by side, and the flagship journey walks into a wall. Nobody had noticed because nobody had ever seen the two datasets in one place.

Outcome

Became decision 2, the Rookie tier, entered by course completion. The single highest-impact change in the engagement, and it came from a data collision, not a critique.

Reframed the brief · became decision 2

The method that found it

Side by side, two catalogues. That was the whole technique.

The method that found it

Side by side, two catalogues. That was the whole technique.

There was no clever workshop behind the most important finding in this engagement. There was a two-column list. When a product's entire premise is that two systems connect, the fastest way to test it is to lay out what each side actually contains and read across, because a crossing can only work if there is something on the far side to land on.

Empty next step

The highest-intent courses were sending newly trained pilots into a dead end: a race calendar with nothing available after completion.

Drag sideways

Why nobody had seen it

The course catalogue lived in Moodle and belonged to Omar. The race calendar lived in a spreadsheet and belonged to Sara. Both were correct, complete and well run. The two lists had simply never been printed on the same page, because no single role owned the space between them, which is the same organisational gap that made Learn → Compete the crossing with no owner.

Why static screens failed

In Figma the Race hub is three well-composed event cards and it looks excellent. The defect is not in any screen: it is in the relationship between two datasets, and it only becomes visible when both are populated with real content at the same time. This is the argument for designing against real data that I would make on any project, and it is why the coded build existed.

What it changed

It reframed the brief. Up to this point I had been designing the signposting for a crossing: a status line, a notification, a well-tiered event card. The audit showed the signposting was pointing at a wall. The remaining work was not an interface problem at all: the calendar needed a tier that did not exist.

Key design decisions

Four calls, the alternative I rejected, and what each one moved.

Nine words instead of a dashboard

The Academy needed to show progress and the next cross-module action without burying the course.

REJECTED

A four-module dashboard that gave equal weight to everything.

SHIPPED

“1 ongoing course · 2 new races this week.”

Comprehension reached 7/8 in round two.

A Rookie tier gated by learning

Beginner-weighted learning led into an event calendar with no beginner entry point.

REJECTED

A skill filter on an empty beginner event set.

SHIPPED

A Rookie class unlocked by course completion.

Eligible-race completion moved from 3/8 to 8/8.

Qualification before payment

Regulation requires approved training before flight, and checkout could not be the first gate.

REJECTED

Validate after checkout and create a refund queue.

SHIPPED

One qualification gate reused in Rent and Race.

Zero eligibility-related refunds in beta.

A record the pilot owns

Results existed as event posts, not as a durable identity or history for the pilot to own and share with sponsors.

REJECTED

An event-first archive that answered the organiser’s question.

SHIPPED

A person-first record of races, finishes, and progression.

Shareability became the most-requested v1.1 feature.

Design engineering

Tokens I can grep, not a style guide describing intentions.

Design engineering

Tokens I can grep, not a style guide describing intentions.

The build was not there to impress stakeholders with motion. It was there to make the system argue back. By wiring course states, race eligibility, rental gates, and pilot records into one clickable surface, I could see where the proposed architecture created dead ends that static screens had hidden.

I built the validation prototype as a lightweight React surface, not to ship production code, but to force the lifecycle model through real states: course completion, eligibility checks, rental availability, race tiers, saved records, and empty calendars. The value was not animation or fidelity. It was making every cross-module assumption visible enough to test, break, and rewrite before the vendor’s Phase 1 contracts became expensive to change.

1 validation repo

A lightweight coded prototype became one working surface for review, replacing clickable mockups with a single place to test flows, states, and logic.

4 modules stress-tested

Shop, Rent, Learn, Race all stayed separate backend modules, and the beta prototype tested where they actually needed shared user-facing rules.

6 shared patterns

Eligibility gate, race card, course card, rental state, pilot record, and empty calendar were designed as shared patterns across the ecosystem.

3 decisions de-risked

Rookie tier, My Records, and reusable qualification gates were validated in the build before being carried into the vendor Phase 1 scope.

Drag sideways

Designs at a glance

Every region here exists to move a pilot one step further across.

Usability testing

Two rounds. The gap between them is the whole argument.

Usability testing

Two rounds. The gap between them is the whole argument.

Methodology

Round 1

Open

Round 2

Open

Format

Counted

Recruitment

Open

Composition

Open

Round 2 : It is ran on the coded build rather than a clickable prototype, which is the only reason the timing figures mean anything.

Tasks

1. "You've just finished a course. Find a race you could actually enter."

2. "Read me the line under the greeting. What is it telling you?"

3. "Register for the Dubai event."

2. "Rent something you could use for the course you're taking."

3/8 → 8/8

+5

Found an eligible race after finishing a course

6/8 → 8/8

+2

Completed race registration

4/8 → 7/8

+3

Explained the status line correctly

4m10s → 1m52s

−55%

Time to first race registration

71.2 → 81.4

+10.2

System Usability Scale

Outcome

Three months of limited beta, 311 real pilots.

Beta ran from roughly July 2025 against the vendor's Phase 1 build. Where a figure is self-reported rather than instrumented.

Course completion → race registration, 60 days

Estimated baselineBeta, instrumented

<10% → 34%

"Where do I go for X" support tickets, per week

Pre-platform estimateBeta · self-reported by ops

Pre-platform estimateBeta · self-reported

15–20 → 4

65%

Activation, 311 of the 480 invited

Instrumented

58%

Opened ≥3 of the 4 tabs in week one

The one-product proxy metric

81.4

System Usability Scale, round 2

n=8

1m52s

Median time to first registration

Down from 4m10s at round 1

What the numbers don't say

The 34% is the figure I would defend, because it is instrumented and it is the one the whole engagement was aimed at. Everything it is compared against is soft, the <10% baseline is a reconstruction from spreadsheets, and the support-ticket figures are Layla's team counting from memory. I have kept both because the direction is real and the magnitude is not the claim. And 81.4 SUS is a good score, not an excellent one, and it is worth to flag.

Beta cohorts are also the friendliest users a product will ever have: 480 people from a community that already existed. None of this survives contact with cold acquisition, and nothing here should be read as though it has.

What didn't land clean

The Rookie tier is the best idea in this journey and it is a recommendation, not a shipped feature. It required Sara to restructure how heats run at every event, a real operational cost that a designer proposing it in the middle does not get to wave away. It went into the production backlog, and the 34% is attributed to it on the strength of the funnel model plus the push mechanics that did ship. I cannot cleanly separate those two contributions, and I am not going to pretend otherwise.

The status line still loses one reader in eight, due to a corrected hyphen issue. Two rounds of testing, three passes of copy, and the thing I missed was a punctuation mark, not a metric.

What came next

Phase 2, deliberately not built here.

What came next

Phase 2, deliberately not built here.

Rookie tier, operationally

The heat structure, prize split and marshalling changes Sara needs before it can run at a real event.

Shareable pilot profile

My Records as something Khalid can send a sponsor. The most-requested item in beta feedback.

Web parity for pilots

The Operations Web App exists for staff, and pilots are mobile-only by design in v1.

Arabic and RTL support

A UAE product shipping English-only is a staging decision, and it was made to fit the deadline.

Reflection

The most useful thing I did was not a screen.

What I would do the same

Building the validation layer in code rather than clicking through a prototype. A list of findings were covered, the missing tier, currency splits, widgets divergence, only exist because real data was running through real components. A static handoff would have shipped all, and the missing tier would have quietly capped the product's flagship journey at under 10% forever.

And spending week one on a five-stage lifecycle instead of a wireframe. Every scoping argument after that resolved against it.

What I would do differently

I found the tier problem midway. It was visible in week one: the course catalogue and the race calendar were both in the technical proposal, and putting the two lists side by side is a ten-minute exercise I did not think to run until code forced it. The most valuable finding was available on day one and I needed a prototype to see it.

The lesson I actually took: when a product's premise is that two systems connect, audit the data on both sides before designing anything. Content collisions are cheaper to find in a spreadsheet than in a build.

Reflection

The most useful thing I did was not a screen.

What I would do the same

And spending week one on a five-stage lifecycle instead of a wireframe. Every scoping argument after that resolved against it.

What I would do differently

Reflection

The most useful thing I did was not a screen.

What I would do the same

And spending week one on a five-stage lifecycle instead of a wireframe. Every scoping argument after that resolved against it.

What I would do differently

Thank you for scrolling through 25,500 pixels of intent

Crisis-NG

Defence · Security Operations · NDA

Crisis-NG

Defence · Security Operations · NDA

Crisis-NG

Defence · Security Operations · NDA

Argus

Security Operations · NDA

Argus

Security Operations · NDA

Argus

Security Operations · NDA

View all

Available for consulting & partnerships

The next project could be yours

I partner with startups, enterprises, and government teams to simplify complex systems, from strategy and design to production-ready delivery. If you're building something ambitious, let's talk.

You

Let's build together

Four businesses Into One pilot's lifecycle.

Four businesses Into One pilot's lifecycle.

Four businesses Into One pilot's lifecycle.

Four businesses Into One pilot's lifecycle.

Sole Product Designer / UX Engineer

Product Designer / Engineering

5 (Myself + CEO, COO, Academy & Race Ops)

Myself + CEO, COO, 2 Ops

Feb – May 2025

They had a 68-page technical proposal naming four business modules, four backend systems and one identity layer. What it did not have was any evidence that a pilot would experience them as one product rather than four apps sharing a password.

The fix was to stop designing as four modules in a menu and start designing as one pilot lifecycle: discover, learn, try, own, compete.

That shifted the problem from navigation to continuity. I focused on the hardest handoff, from course completion to race entry.

The solution was to stop designing as four modules in a menu and start designing as one pilot lifecycle: discover, learn, try, own, compete.

It shifted the problem from navigation to continuity. I focused on the hardest part, from course completion to race entry.

Sole Product Designer, independently leading research, information architecture, the cross-module interaction model, and the visual system. I also built a working React prototype, used as a research instrument to test the journey, not as a production deliverable.

34%

58%

311 / 480

SUS 71.2 to 81.4

SUS 71.2 to 81.4

A WhatsApp group, a spreadsheet, and a 68-page proposal.

A WhatsApp group, a spreadsheet, and a 68-page proposal.

What existed before I started

Nobody bundles all four. That is the opportunity and the risk.

Two constraints, two specific product decisions.

Two constraints, two specific product decisions.

GCAA

Drone regulation - Jan 2025

Approved training and drone registration required regardless of weight, flight banned within 5 km of any airport, and recreational flying confined to approved zones.

Decision it forced

Pilot-qualification validation runs before a rental or a race registration confirms, not after payment. The gate is the same component in both flows, which is why it behaves identically.

PCI DSS

Named in the proposal

Card data never stored client-side, the app holds a provider token only.

Decision it forced

Shop checkout and the Rent deposit-authorisation lifecycle share one payment surface. A deposit hold and a purchase look different to the user and identical to the system.

I asked pilots to show me their Saturday.

I asked pilots to show me their Saturday.

Participants: 4 pilots, 2 prospective renters, 3 stakeholders

Minutes per session, semi-structured, moderated, think-aloud

Day diary study with timestamped notes as pilots switched tools.

Competitor products torn down heuristically, across all the 4 verticals

Who I talked to

4 hobbyist and community pilots, beginner through advanced, UAE residents aged 19–44, recruited through the existing 40-pilot group.

2 prospective renters who own nothing yet, 1 resident and one short-stay visitor who wanted a day's rental and a guided flight.

3 internal stakeholder, Rashid (CEO), Omar (Academy), Sara (Events), each of whom owns a different module's P&L

Plus a service-blueprinting session with those three, mapping buy, learn, rent, and race, end to end for the first time.

What I asked

Four findings that set the scope

8 / 9

A retailer's website for parts, a WhatsApp group for race news, informal in-person coaching, and sometimes an Instagram DM for rentals. Nothing shared identity or history. The diary study caught the switches as they happened rather than as remembered.

7 / 9

Renting or buying before any training felt backwards to them, but nothing connected "I want to try this" to "here is a beginner course, and a rental you can use for it.

6 / 9

Especially the short-stay segment. GCAA and DCAA rules diverge, and the moment that became confusing, people abandoned the research entirely rather than risk it.

6 / 9

Registration lived in a spreadsheet, and results were posted and forgotten. No pilot owned a persistent record of what they had done. Khalid, chasing his first sponsorship, had nothing to show anyone.

I audited the experience already in use: the four-tool workaround.

I audited the experience already in use: the four-tool workaround.

01 · Visibility of system status

Nothing anywhere told a pilot where they stood. Course progress lived in Moodle, race standing lived in a spreadsheet, order status lived in an email.

What It Became

The status line under the greeting, "1 ongoing course - 2 new races this week", plus a weekly progress ring. State is the first thing on the screen, not something you navigate to.

02 · Match to the real world

The tools were organised by business: a shop, a group, a calendar. Pilots think in terms of a progression: I'm learning, I'm ready, I'm competing.

What It Became

Courses and races share one skill vocabulary. Beginner, Intermediate, Advanced mean the same thing on both sides of the crossing.

03 · Recognition over recall

To enter a race you had to remember the group post, the date, the venue rules and whether you were qualified. All four lived in different places.

What It Became

The event card carries date, venue, tier, difficulty, closing window and remaining slots. Nothing has to be held in the head.

05 · Error prevention

Pilots could, and did, pay for a rental or a race entry they were not legally qualified to use, and found out afterwards.

What It Became

The qualification gate runs before confirmation, in both flows, as the same component. You cannot buy your way past it.

07 · Flexibility & efficiency

A returning pilot and a first-timer got exactly the same undifferentiated wall of content.

What It Became

The Academy home leads with whatever you already started, and the "For You" rail below it is ordered by what you have completed, not by what is newest.

10 · Help & documentation