2026 Member Survey + Mobile Audit · March 2026
Members told us
what's broken.
The audit explains why.
3.50
App portal score / 5
64
Members: booking is stressful
13
Members: hard to navigate on phone
7
Members: forced to switch app ↔ browser
2026 Annual Survey · n=627
What members are telling us
These themes emerged from open-text responses — members weren't asked about mobile. They volunteered it. The technical audits explain exactly what's causing each experience.
64
members
Booking Feels Stressful
"I find it frustrating and hard to navigate especially from my phone. Lots of glitches and difficulty accessing what's open at a glance."
Booking felt "competitive or stressful" — the #1 single complaint in the survey. Members on mobile can't see or reach the booking action when the keyboard is open.
What the Audit Found
- No sticky CTA on search/booking flows — keyboard buries the action button
- Forms don't account for soft keyboard — no scroll-to-field on focus
- Touch targets at 40px, below 44px minimum — small buttons under pressure
13
members
Hard to Navigate on Phone
"I find the system very difficult on my phone."
The most common unprompted complaint. Members can't tell where they are in the app or how to get back. "Difficult to navigate" was named 13 times without being asked.
What the Audit Found
- No active state in mobile nav drawer — members don't know where they are
- No back navigation in nested flows — destination → detail → back is disorienting
- Native app shows web nav AND native nav simultaneously inside the webview
7
members
Forced to Switch App ↔ Browser
"I don't like the switching back and forth. I think it should all be on the app."
Members start a task in the app, hit a wall, and open their browser to finish it. The app and the website do the same things — but differently — with no clear ownership.
What the Audit Found
- Platform ownership undocumented — no decision on what lives where
- Explore and Search built independently in both native and web
- Web runs inside the native app as an undetected webview — no context sharing
49
members
Can't Browse Residences on Mobile
"320 residences available in next 90 days but you have to go into each destination residence by residence."
49 members said the booking window misaligns with how they plan travel. The browse experience forces one-by-one exploration with no filter persistence or list view.
What the Audit Found
- Duplicate Explore surface in native and web — no single source of truth
- No list view — members must tap into each property individually
- Images unoptimized for mobile — slow loads degrade the browse experience
30-Day Plan · Driven by Member Feedback
What we fix first
Every action below is tied directly to something members reported. Effort estimates are conservative. All of Week 1 can ship in a single sprint.
Week 1
Fix Booking
Days 1–7 · 64 members asked for this
- Add sticky CTA to booking + search flows 30 min
- Fix keyboard avoidance — scroll-to-field on form focus 2 hrs
- Raise touch targets 40px → 44px on web buttons + inputs 5 min
- Add loading + error states to booking flows 4 hrs
Member impact: Booking feels responsive and reachable on mobile
Week 2
Fix Navigation
Days 8–14 · 13 members asked for this
- Add active state to mobile nav drawer 10 min
- Add webview detection — hide duplicate nav + footer 15 min
- Add back navigation + breadcrumb to nested flows 4 hrs
- Fix native touch targets on icon-only buttons 1 hr
Member impact: Members know where they are and how to get back
Week 3
Unify App + Web
Days 15–21 · 7 members asked for this
- Document platform ownership — what lives where Decision
- Remove 8 deprecated screens from native app 1 hr
- Build auth bridge for webview context sharing 3 days
- Consolidate Explore to web as single source of truth 3 days
Member impact: One coherent experience — app and browser feel the same
Week 4
Fix Browse
Days 22–30 · 49 members asked for this
- Optimize Cloudinary images for mobile viewports 1 day
- Add list view to destination browse 3 days
- Add skeleton loading states to browse + search 3 hrs
- Begin unified design token layer (native + web) Ongoing
Member impact: Finding and comparing residences works on a phone
Independent Validation
The audits confirm
what members are saying.
The native app audit and mobile web audit were conducted independently of the survey. They identify the same four root causes members reported — which means the fixes will directly improve member experience.
Issue 01
Navigation is broken
on mobile
on mobile
✓Native Audit: 5 nav issues — no active states, 8 deprecated screens, no back listeners
✓Mobile Web: No active nav indicator, no breadcrumb, no back path in nested states
◈13 members reported "difficult to navigate on phone" — most common unprompted complaint
Issue 02
App and web are
fragmented
fragmented
✓Native Audit: Platform ownership undocumented; Explore & Search duplicated across both apps
✓Mobile Web: Webview runs blind — full nav + footer duplicated inside the native shell
◈7 members: forced to switch back and forth between the app and a browser to complete tasks
Issue 03
Booking creates
stress, not ease
stress, not ease
✓Native Audit: No form library, no keyboard avoidance, no loading states or error feedback
✓Mobile Web: No sticky CTA — keyboard buries the booking action at the highest-intent moment
◈64 members: booking felt competitive or stressful — highest-count single complaint in the survey
Issue 04
Browse & search
don't work on mobile
don't work on mobile
✓Native Audit: Duplicate Explore surface, no list view, no filter persistence across sessions
✓Mobile Web: Images unoptimized, carousel not responsive, slow loads degrade browse experience
◈49 members: booking window misaligned with travel planning — "320 residences, one by one"
Platform Architecture · Mobile Strategy
Native vs. Web
Platform Decision
Framework
5
Stay in native
7
Move to web
8
Deprecated screens
12wk
Path to completion
Decision Framework
When to use native vs web
Use Native (React Native)
Native
Device
Camera, GPS, push notifications, biometrics, haptics
Offline
Content members need without connectivity
Performance
Frequently-accessed screens where 60fps matters
Conventions
Bottom tab nav, swipe gestures, native pickers
Use Mobile Web (Webview)
Web
Content
Complex, content-heavy flows — destinations, editorial, search
Velocity
Changes frequently without requiring an app release
Forms
Profile, add traveler, account management
Admin
Cancellation, policy review, document uploads
Platform Mapping
Current vs. Recommended
| Feature / Flow | Current | Recommended | Rationale |
|---|---|---|---|
| Login / Auth | Native | Native | Biometrics, secure token storage |
| Bottom tab navigation | Native | Native | Platform convention, instant |
| Home / Dashboard | Web | Native → | Frequently accessed, needs speed |
| Explore / Search | Both ⚠ | Web only | Editorial content, frequently updated |
| Destination details | Both ⚠ | Web only | Rich content, media-heavy |
| Property + Calendar | Native | Web → | High maintenance; web more flexible |
| Available Trips | Web | Web | Forms, changes frequently |
| Book / Request Trip | Web | Web | Form-heavy, needs fewer releases |
| My Trips list | Web | Web | Push notifications from native |
| Trip Details | Web | Web | Complex multi-section layout |
| Get Ready / Pre-trip | Native | Web → | Forms, lots of edge cases |
| Add Traveler | Native | Web → | Form-heavy, editorial |
| Flight Info | Native | Web → | Form-heavy |
| Cancellation | Native | Web → | Policy display + form |
| Connect / Messaging | Native | Native | Real-time, push notifications required |
| Profile / Account | Web | Web | Forms, changes frequently |
| Community | Web | Web | Content-heavy |
| Push Notifications | Native | Native | Requires device integration |
Recommended Approach
Four-Phase Roadmap
Phase 1
Establish the Contract
Weeks 1–2
- Document platform map — ratify with product + engineering
- Add webview detection (
isWebviewflag) to The Source v2 - Conditionally hide web nav + footer inside The Club
- Establish shared design token source of truth
- Remove 8 deprecated screens from native app
Output: Clear platform architecture doc + webview-aware web app
Phase 2
Fix the Foundation
Weeks 3–6
- Touch targets — 44px minimum enforced on both platforms
- Typography — reduce to 8 semantic sizes, enforce Canela rules
- Sticky CTAs — search, booking, trip detail flows
- Keyboard avoidance — forms on both platforms
- Active nav states — mobile drawer shows active section
Output: Both apps meet baseline mobile UX standards
Phase 3
Consolidate to Web
Weeks 7–12
- Move Add Traveler → web form (retire native)
- Move Flight Info → web form
- Move Cancellation → web form
- Unify Explore/Search → web only
- Build webview bridge: auth sharing, native back
Output: Native app is shell + messaging; web handles all content flows
Phase 4
Elevate to Luxury
Ongoing
- Shared design token system across both platforms
- Accessibility remediation — WCAG AA compliance
- Form component library (web) + button library (native)
- Loading/skeleton states — consistent across all screens
- Image optimization — responsive Cloudinary transforms
Output: Cohesive, premium feel across entire mobile experience
Native App Audit · The Club
React Native
iOS + Android
Full Audit
70+
Colors defined
23
Font sizes
763
Hardcoded values
4/10
Component library
Executive Summary
The Club has solid architectural foundations — proper navigation type-safety, reasonable separation of concerns, good list performance via FlashList — but suffers from significant design system inconsistency, typography chaos (23 font sizes), accessibility gaps, and scattered UX debt. It feels utilitarian rather than luxurious. The codebase prioritizes functionality over visual polish, with hardcoded values proliferating across 154 files (763 occurrences).
Priority Issues
Top 10 Critical Fixes
| # | Issue | Location | Fix |
|---|---|---|---|
| 1 | Color system fragmentation — 70+ colors, 4 error reds, 763 hardcoded values |
src/styles/Theme.ts, all component styles |
Consolidate to ~30 colors, enforce via ESLint, create semantic tokens |
| 2 | Typography chaos — 23 sizes, confusing names, no hierarchy |
src/styles/Theme.ts |
Reduce to 8 sizes max, define semantic tokens (h1/h2/body/caption) |
| 3 | Accessibility absent — 80%+ of interactive elements missing labels/roles |
All components |
Audit every touchable, add labels + roles + hitSlop, test VoiceOver/TalkBack |
| 4 | Inline styles replace design system throughout |
All component files |
ESLint rule against hardcoded px values; extract to StyleSheet.create() outside render |
| 5 | Modal presentation inconsistency + 8 deprecated screens |
src/app-navigation/RootStack.tsx |
Define clear modal rules, remove deprecated screens |
| 6 | Deep linking incomplete — 6 of 26+ routes mapped |
src/app-navigation/linking.ts |
Map all major screens, add URL validation, test both platforms |
| 7 | No form component library — inputs unstyled, no validation feedback |
src/components/ |
Build LabeledInput, FormError, FormSection with consistent focus/error states |
| 8 | Spacing system ignored — 30+ magic numbers override tokens |
All component files |
Add xs (4), xl (48) tokens, ESLint enforcement, refactor to Theme.spacing |
| 9 | Loading/error states inconsistent — hidden in prod, no skeletons 3 members: slow / loading issues reported |
src/components/error-notifier/ |
Show errors in prod (generic message), build SkeletonLoader, disable buttons during submission |
| 10 | Button system fragmented — 3 different heights, BottomButtons hardcoded |
src/components/member/BottomButtons.tsx |
Define button variants (primary/secondary/tertiary), standard height 48, support small/medium/large |
Design System
Typography & Color Chaos
Typography Scale — 23 Sizes
xxxLarge
56px — Rarely used
xxLarge
32px — Never found in use
extraLarge
30px — Overlaps xLargePlus
xLargePlus
28px — Confusing naming
xlarge
26px — Overlaps with large
large
24px — OK
subtitleLarge
22px — Overlaps subtitle
mediumMiddleLarge
17px — Confusing name
smallMedium
15px — Barely different from small
smallPlus
13px — Barely different from small
pickerSize
20px — Duplicate of subtitle
Color Fragmentation
4 different error reds: #EB5851, #f52d00, #E02B00, #E85255
3 different greens for status: #1D8139, #718991, #09d9e0
15+ gray shades with confusing naming: light1–6, dark1–3, mediumDark, neutral
Opacity hack:
3 different greens for status: #1D8139, #718991, #09d9e0
15+ gray shades with confusing naming: light1–6, dark1–3, mediumDark, neutral
Opacity hack:
colors.states.error + '10' instead of proper alpha utility
Component Library — 4/10
ClubText
No default styles; not a real design system component
ClubTextInput
No focus state, no placeholder styling
Checkbox
StyleSheet inside render, magic numbers (24x30 vs 18x24)
HR
Default white backgroundColor — invisible on white
BottomButtons
Hardcoded width 160, height 50; not responsive
Screen Reviews
Screen-by-Screen Findings
Strengths
- Type-safe navigation via RootStackParamList in src/app-navigation/RootStackParam.tsx
- Clear separation of auth states (Loading → Login → Tabs) in RootStack.tsx
- Modal/transparentModal grouping for presentation control
- Deep linking config exists with prefixes theclub:// and thesourcev2://
Issues
- Two modal strategies with no clear pattern — modal vs transparentModal mixed inconsistently
- Only 6 routes mapped via deep link; 20+ key screens unreachable (no property, destination, FlightInfo, Connect, Settings)
- 8 screens still present with _DEPRECATED_ naming (PdfModal, PostTripSurvey, ClubJournal, etc.)
- No beforeRemove listeners — back navigation handling inconsistent
- Untyped any fields in RootStackParam.tsx (e.g., UpdateConfirmation.data)
Login
- Status bar hardcoded white
- Platform-specific font sizes as magic numbers
- No accessibility labels on any buttons
Explore / Search
- Filter button lacks active state visual
- No focus state on search input
- Loading indicator positioned poorly in list items
Destination Screen
- Styling uses hardcoded colors
- Custom modal header inconsistency unclear
Property Screen
- Multiple hardcoded border radius values (15, 8 — not tokens)
- Calendar tappable while data loads (no visual feedback)
- Width calculation calendarWidth/7 magic math
Get Ready / Pre-Trip
- No visual feedback for incomplete checklist sections
- Inconsistent input styling
- Spacing inconsistencies throughout
Cancellation
- colors.states.error + '10' opacity hack
- Hardcoded ambassador photo size (100x100)
- Button sizing inconsistent (minHeight: 50 vs height: 50)
Connect / Messaging
- Unread badge not square (19x17)
- Font hardcoded as 10 instead of Theme token
All Forms
- No consistent input styling — default RN TextInput with inline styling
- Only button disable/enable as feedback — no field-level errors
- keyboardType specified inconsistently
- accessibilityLabel missing on 80%+ of interactive elements (buttons, icons, touchables)
- hitSlop rarely used — most small touch targets (icons, close buttons) below 44x44pt minimum
- No semantic roles — accessibilityRole missing from custom buttons, list items, headings
- brand.light (#cadcde) on white: ~2.8:1 — WCAG AAA failure
- grey.light4 (#77777D) on white: ~4.5:1 — borderline AA
- No live region announcements — filter results update silently
- No evidence of VoiceOver/TalkBack testing
Low Effort, High Impact
Quick Wins
5 minFix HR default: backgroundColor: 'white' → colors.lightGray.light3 (invisible on white backgrounds)
5 minFix typo: erroText → errorText in error-notifier/styles.ts
10 secAdd accessibilityLabel="Open filters" to HeroScreen.tsx filter button
5 minUnread badge: make square width: 20, height: 20 in elements.ts
2 minCheckbox hit area: add minHeight: 44 to ensure accessibility minimum
2 minMessages padding: replace paddingVertical: 20 with spacing.base2
15 minAlgolia error boundary: wrap carousel/result list to catch failures gracefully
20 minRemove deprecated screens: delete 8 _DEPRECATED_ screens from RootStack.tsx
Mobile Web Audit · The Source v2
Next.js Portal
Mobile + Webview
Full Audit
40px
Button height (need 44)
14px
Body text (need 16)
0
Webview detection
61KB
global.css overrides
Executive Summary
The Source v2 has a solid mobile foundation — thoughtful navigation patterns, responsive typography, and drawer-based modals. However, critical gaps in touch targets, keyboard avoidance, image optimization, and webview context awareness fall short of luxury product standards. Most significantly: the app has no awareness that it runs inside The Club native app, meaning it shows redundant navigation and footer inside the webview.
Priority Issues
Top 10 Mobile Fixes
| # | Issue | Location | Fix |
|---|---|---|---|
| 1 | Button touch targets below 44px (size-md = 40px) |
components/Common/Button/styles.ts:141 |
Enforce 44px minimum across all interactive elements |
| 2 | No sticky CTA on search/booking flows 64 members: booking felt competitive or stressful |
pages/search.tsx, booking modal |
Add position:sticky bottom container with CTA + safe-area-inset-bottom |
| 3 | No webview detection — redundant nav/footer inside native app 7 members: forced to switch between app and browser |
pages/_app.tsx |
Add isWebview utility; conditionally hide footer, simplify nav |
| 4 | Cloudinary images not optimized for mobile |
All CloudinaryImage components |
Add responsive w_ transforms; cap at 90vw on mobile |
| 5 | Forms don't account for soft keyboard 64 members: booking felt stressful — keyboard buries key actions |
All form pages |
Scroll-to-field on focus; padding-bottom adjustment when keyboard open |
| 6 | Body text at 14px (below mobile minimum) |
styles/theme.ts:122 |
Increase body to 16px on xs/sm breakpoints |
| 7 | No active tab indicator in mobile nav drawer 13 members: difficult to navigate on phone |
components/Nav/index.tsx:456 |
Add background or underline for active nav item |
| 8 | Tab navigation truncation on ≤375px |
TabNav on Profile, MyTrips |
Responsive font size or label abbreviation for xs |
| 9 | Canela used at h6 (16px mobile) |
styles/theme.ts:117 |
Restrict Canela to h1–h3 only; always Gotham below 28px |
| 10 | No back navigation in nested mobile flows 13 members: hard to navigate / find way around on phone |
Nav/drawer stacking |
Add back button/breadcrumb to nested states |
Category Breakdowns
All Findings by Area
Strengths
- Hamburger menu correctly hidden on mobile; drawer pattern appropriate
- Nav height: 64px mobile (reasonable)
- Logo/icon sizing appropriate at 48x48px
Issues
- No active indicator in mobile drawer — display: isMobile ? 'none' : 'flex' hides underline on mobile (Nav/index.tsx line 456)
- No breadcrumb or back path in nested states — destination details → modal → back is disorienting
- Profile icon lacks touch affordance — no visual indication it's tappable on mobile (Nav/index.tsx:496–505)
- Body text at 14px — below 16px minimum for mobile legibility (styles/theme.ts:122–127)
- Canela used at h6 (16px on mobile) — serif at 16px loses elegance; CLAUDE.md requires 28px+ (styles/theme.ts:117–121)
- eyebrowSmall and bodyXSmall at 12px — too small on mobile; no responsive bump (styles/theme.ts:188–193)
- No max line-length constraint — text stretches edge-to-edge on mobile
Critical — App runs inside The Club native app as a webview
The web app has zero awareness it's running inside a native app. This causes fundamental UX breakdowns on every screen.
- No webview detection — footer and full nav render inside webview (redundant, wastes vertical space)
- No native bridge — can't access auth tokens, push notifications, native share
- External links unhandled — may open inside webview instead of external browser
- Android back button conflicts — web history management conflicts with native back
- No testing confirmed inside actual The Club app
Recommended Fix
const isWebview = typeof window !== 'undefined' && !!window.ReactNativeWebView;
- Cloudinary widths not confirmed responsive — images likely fetched at desktop size on mobile (bandwidth waste + layout shift)
- next/Image disabled (images: { unoptimized: true } in next.config.mjs) — mobile optimization is entirely manual
- No loading="lazy" on images below fold
- Carousel images not responsive — full container width, may cause layout shift
- Hero image aspect ratio — constants defined but not verified for correct mobile crop
- Phone input 40px — below 44px minimum (components/Form/InternationalPhoneInput/styles.ts)
- No keyboard avoidance — forms obscured by soft keyboard; no scrollIntoView() or padding adjustment
- Validation errors hidden by keyboard — ErrorStyled renders below input, not above
- No mobile-specific input types — missing type="tel", type="email" for correct keyboards
- TextField marginBottom: 32px hardcoded — excessive on small screens
Low Effort, High Impact
Quick Wins
5 minChange size-md button from 40px → 44px in Button/styles.ts
5 minIncrease phone input from 40px → 44px in InternationalPhoneInput/styles.ts
10 minAdd active indicator to mobile nav drawer (Nav/index.tsx line 456)
15 minAdd isWebview utility and hide footer + nav inside webview
5 minRestrict Canela to h1–h3 in theme — no Canela below 28px
5 minBump body to 16px on xs/sm breakpoints in styles/theme.ts
15 minAdd loading="lazy" to CloudinaryImage components below fold
10 minAdd type="tel" to phone inputs, type="email" to email inputs
10 minAdd aspect-ratio CSS to hero images on mobile
30 minAdd sticky CTA container to search page (position:sticky + safe-area-inset-bottom)
Consolidated Priority Matrix
All Issues
Ranked by
Impact × Effort
5
P0 — Fix first (sprint)
7
P1 — Next quarter
8
P2 — Polish
S M L
Effort scale
P0
Fix First — High impact, achievable in a sprint
1
Webview detection + hide nav/footer inside app
Web
S
2
Button touch targets: enforce 44px minimum
Both
S
3
Decide and document native vs web platform ownership
Strategy
S
4
Stop duplicating Explore/Search in both platforms
Both
M
5
Active nav indicator in mobile drawer
Web
S
P1
High Value — Next quarter
6
Unified design token layer (shared colors, type scale, spacing)
Both
L
7
Sticky CTA on conversion flows (search, booking)
Web
M
8
Keyboard avoidance on all forms
Both
M
9
Consolidate native Get Ready flows → web
Native→Web
L
10
Complete deep linking in native app
Native
M
11
Responsive Cloudinary images
Web
M
12
Typography cleanup — reduce to 8 semantic sizes
Both
M
P2
Polish & Completeness
13
Accessibility audit + remediation (labels, roles, contrast)
Both
L
14
Form component library (consistent inputs across web)
Web
L
15
Build native button + component library
Native
L
16
Native → Web bridge (auth, push, share)
Both
L
17
Loading/skeleton states (consistent pattern)
Both
M
18
Remove deprecated screens from native nav
Native
S
19
Color system consolidation
Both
L
20
Error states visible in production
Native
M
Member Survey · 2026 Annual · n=627 Respondents
Members agree
with the audit
4.04
Overall satisfaction / 5
3.50
App portal score / 5
3.54
Booking ease score / 5
Satisfaction Scores
How members rate the portal and booking
3.50
/ 5
App Portal Satisfaction
n=477 respondents
Key Signal
53.3% are satisfied or very satisfied, but 32.9% neutral and 13.8% dissatisfied represents meaningful churn risk in a high-retention membership model. Neutral is the most dangerous segment — it's members who haven't left, but haven't been won either.
3.54
/ 5
Booking Ease
n=492 respondents
Booking Challenges (multi-select)
64 cited "competitive or stressful" booking · 49 said the window misaligned with travel planning · 31 noted availability changed quickly · 29 found release timing unclear.
Mobile-Specific Findings
What members say about the app and mobile web
The mobile problem was volunteered, not prompted
These frustrations surfaced in open-text fields — members weren't asked specifically about mobile. Over 40 responses named app or portal usability problems unprompted. When members go out of their way to name something, it matters.
13
Difficult to Use / Navigate
Most frequent unprompted complaint. Navigation confusion, hard to find destinations, unclear hierarchy on mobile.
7
App vs. Website Inconsistency
"Switching back and forth" frustration. Members forced to abandon the app and open a browser to complete tasks.
6
Needs Modernization
Members explicitly requested updated technology. Language: "outdated," "not up to date," "overhaul needed."
4
Cumbersome / Clunky
General friction. The "320 residences, one by one" quote is the canonical example of browse UX failure.
3
Slow / Loading Issues
Latency called out directly in open text. "Latency is a major issue" is a verbatim quote. Performance is felt.
2
App Crashes
Two direct crash mentions plus several "unusable" responses implying functional failure, not just preference.
Top Mobile-Related Improvement Requests
Member portal ease of use
#1
Mobile app and portal modernization
#2
Integrate app and portal into one experience
#3
Ease of planning and booking a trip
#4
Member Voice
In their own words
"The mobile app is unusable. Its functionality is sub-par and not up to date. Latency is a major issue."
Member · 2026 Annual Survey · Open-text response
"The app crashes basically every time we use it. It needs an overhaul."
Member · 2026 Annual Survey
"The app is still cumbersome... 320 residences available in the next 90 days but you have to go into each destination residence by residence."
Member · 2026 Annual Survey
"I don't like the switching back and forth. I think it should all be on the app."
Member · 2026 Annual Survey
"I find it frustrating and hard to navigate especially from my phone. Lots of glitches and difficulty accessing what's open at a glance."
Member · 2026 Annual Survey
Crossover Analysis
The audit and the members agree
How to read this section
Each row maps a specific technical audit finding to independent member survey evidence. The left panel is what the audit identified. The right panel is what members reported — unprompted, in open-text responses — in the same survey period. These are not the same data source. That they converge is the point.
Audit Finding P0
Webview detection failures + no performance monitoring
Issue #1: The native app embeds The Source v2 as an undetected webview. Errors surface as silent failures inside the native shell. No performance budgets, no crash reporting, no alerting is documented or in place.
Member Survey Evidence
2 direct crash mentions
plus multiple "unusable" and "latency" responses in open text (n=477)
"The mobile app is unusable. Its functionality is sub-par and not up to date. Latency is a major issue."
Audit Finding P0
No active nav indicator; redundant nav rendered inside webview
Issue #5: The mobile hamburger menu has no active-state indicator. The web app also renders its own nav bar inside the native shell — creating two simultaneous navigation systems with no hierarchy between them.
Member Survey Evidence
13 mentions
"difficult to use / navigate" — most common unprompted app complaint in open text
"I find the system very difficult on my phone."
Audit Finding P0
Platform ownership undocumented; duplicate Explore / Search surfaces
Issues #3 + #4: No decision record exists defining what lives in native vs. web. Explore and Search are independently built across both platforms — confusing members about which surface to use and which to trust.
Member Survey Evidence
7 members
described "switching back and forth" between the app and browser to complete a single task
"I don't like the switching back and forth. I think it should all be on the app."
Audit Finding P1
No sticky CTA on conversion flows — keyboard covers booking actions
Issue #7: Booking and search flows lack a persistent call-to-action on mobile. When the keyboard opens, the CTA is buried. Users must scroll to find and confirm booking actions at the highest-intent moment.
Member Survey Evidence
64 members
said booking felt "competitive or stressful to secure preferred dates" (of n=492)
"I find it frustrating and hard to navigate especially from my phone."
Audit Finding P1
Duplicate search surface; no unified browse / filter pattern
Issue #4: Both platforms have a search/explore flow, but neither is designed for the browse-first behavior of a member planning a vacation. No filter persistence, no list view, no way to compare destinations efficiently in one place.
Member Survey Evidence
49 members
said the booking window misaligned with how they plan travel — browse friction compounds this
"320 residences available in next 90 days but you have to go into each destination residence by residence."
Priority Impact
How survey data shapes the roadmap
The survey reinforces — and in some cases escalates — the audit's priority assignments. Issues the audit flagged as P1 on technical grounds alone become more urgent when member friction data is layered in.
Escalate
Booking CTA
P1 → P0 by member data
- 64 members named booking stress
- 13.8% dissatisfied with the portal
- Sticky CTA is an S-effort fix
- Highest impact per sprint day spent
Confirm
Platform Strategy
Aligned P0 — do first
- 7 members frustrated by app/web split
- #3 improvement: "integrate app + portal"
- Document ownership decision publicly
- Single source of truth for feature delivery
Reframe
Browse / Search
Not just UX — it's retention
- "320 residences, one by one" = planning failure
- 49 members: window misaligns with travel habits
- Browse is the discovery surface — fix it early
- Drives satisfaction more than raw speed
The core argument
An overall satisfaction score of 4.04/5 is a false positive. Members are satisfied with Exclusive Resorts as a product — the destinations, the service, the membership value. The 3.50 app score and the volume of open-text frustrations make clear the digital experience is underperforming relative to the physical one. The risk is not that members leave today. It is that digital friction accumulates until the gap between what the product promises and what the app delivers becomes impossible to ignore.