HearPeers Community · March 2026
Connections
RBAC Cross-Analysis
& UX Recommendations
Gunther Eisen (Gonçalo Ferraz)
Lincoln Alves — Coopers Digital
goncalo.ferraz@coopers.digital
13 slides
Roles & visibility · Task corrections
Production gaps · 5 UX recommendations
23 design changes · 9 open questions
Context
Objective & Methodology
How this analysis was conducted and what it aims to define
Objective
Identify all user tasks the Connections page should offer — per role — for better UX in the redesigned platform.
The Connections page is the primary surface for user relationships. Defining its tasks correctly shapes the entire social layer of HearPeers Community.
5-step methodology
1
Tasks implicit in the mockups
Identified every user task implied by the UI designs MED-EL sent
2
Tasks available in the live platform
Audited the current Connections page for what is actually accessible today
3
Cross-analysis with RBAC permissions
Mapped tasks against the actual role permissions in the current codebase
4
Business rules
Understood platform rules, role hierarchy, and community policies that constrain task availability
5
Task definition for the redesign
Defined which tasks the redesigned Connections page should expose per role for the best user experience
Context
Role badges shown in the UI
What each badge label means technically — and who that person is
Member
Candidate / Caregiver
member
Self-registered user — newly diagnosed, candidate for implant, or caregiver
MED-EL User
Recipient
medel_user
Confirmed cochlear implant recipient
Mentor
Mentor
mentor
Trained volunteer peer mentor
MED-EL
Area Manager
area_manager
Regional manager — one per geographic area. Badge reads "MED-EL" in the UI.
Admin
Super Admin
super_admin
Highest-privilege community governance role
Open question Q4: The Area Manager badge reads "MED-EL" — the company name, not the role. This is not meaningful to end users. Should it be renamed "Area Manager" or a community-friendly equivalent? → Ask Anna / Julia.
Section 1 — Connections
Who can see and connect with whom
Confirmed from can_see_connection_* / add_friend_* capabilities — Lucas Maieski, 2026-03-12. Visibility and connection are symmetrical.
| This role… |
…can see Candidate |
…Recipient |
…Mentor |
…Area Manager |
…Super Admin |
| Candidate | — | — | ✔ | — | — |
| Recipient | — | ✔ | ✔ | — | — |
| Mentor | ✔ | ✔ | ✔ | — | — |
| Area Manager | ✔ | ✔ | ✔ | ✔ | — |
| Super Admin | ✔ | ✔ | ✔ | ✔ | ✔ |
Pattern: Each role can see all roles below it in the hierarchy, plus its own. Candidate sees only Mentors. Area Manager cannot see Super Admin.
Discovery vs. My Connections: This matrix governs browse/search only. An existing connection remains visible in My Connections even if the matrix would not allow discovery — which is why "MED-EL" badges appear in Recipient's My Connections in production.
Correction
Candidate task table — four corrections
Tasks incorrectly marked as unavailable to Candidates after RBAC cross-check
| Task |
Was |
Corrected |
Reason |
| Accept a connection request | — | ✔ | add_friend_* is available to member |
| Decline a connection request | — | ✔ | Same permission scope |
| Cancel a sent request | — | ✔ | Available to all roles |
| Discover / browse community | — | ✔† | Candidate can browse — restricted to Mentor profiles only |
✔† = Limited: Candidate's browse and search scope is restricted to Mentor profiles only. These corrections affect the UI: the Connections page for Candidate must support incoming request actions (accept / decline) and outbound request cancellation.
Production Observation
Area Managers visible in Recipient's My Connections
Explained — and a gap uncovered
Observation
In the production screenshot (Recipient view), several users with the "MED-EL" (Area Manager) badge appear in My Connections — even though Recipients cannot discover or connect with Area Managers through normal browse or search.
Likely explanation: Auto-accept. When the Recipient (or Area Manager) sent a connection request, it was automatically accepted. The platform brief states: "Automatic connection to Area Manager on join — ensures new users have immediate human contact."
Gap identified: Auto-accept is passive — an incoming request gets accepted automatically. There is no evidence of a proactive auto-connection being created when a user joins an area. New users who do not know to send a request get no automatic human contact.
Q1 for Lucas: Is the Area Manager auto-connection on join proactive in the codebase, or only via auto-accept of incoming requests? This determines whether UX-R2 is a new feature or a bug fix.
Recommendation
UX-R1 — Super Admin must not appear for non-Super Admin users
Visibility matrix compliance + closing the invitation loophole
Rationale: The visibility matrix is clear — no role below Super Admin can see or connect with a Super Admin. Super Admin profiles must be filtered out of all Connections surfaces for all roles except Super Admin itself.
Design action
- Filter Super Admin profiles from My Connections, Discovery grid, and search results for all roles except Super Admin
- If a Super Admin connection exists via invitation bypass, suppress it visually until the loophole is resolved
Invitation loophole: All roles can send community invitations — only a login check, no capability check. Any role could invite a Super Admin by email and bypass the visibility matrix entirely.
Fix required: Invitation sending should be gated to Mentor+ or Area Manager+. Q3 to confirm with Julia / Alexandre: Should Candidates and Recipients be able to send community invitations at all?
Recommendation
UX-R2 — Area Manager auto-connected to all users in their area
Proactive system-initiated connection · Dedicated "Find Area Manager" path · Permanent card behaviour
Proposed behaviour
- On onboarding + area assignment → system creates connection proactively (no request needed)
- Area Manager appears in My Connections from day one
- Area Manager card CTA: always Chat — never Connect, Pending, or Remove
- Area Manager card is always visible — cannot be hidden or removed by the user
- Green circle on profile photo = user is currently online
Online presence: The green online circle should be applied consistently to all connection cards — not just the Area Manager card. Consistency avoids it feeling role-specific.
"Find Area Manager" — dedicated flow
- Entry point in My Connections tab (not in Discover)
- User selects country / region from a hierarchical picker
- Result: one profile — the Area Manager for that area
- Only available action: Chat (auto-accepted)
- Fallback: "No Area Manager for this area yet — contact MED-EL for support"
Area Manager profiles must not appear in the general Discovery grid for Candidates and Recipients. The "Find Area Manager" flow is the only intentional path.
Recommendations
UX-R3 & UX-R5 — Profile photo & Home navigation
Two fixes with outsized impact — low engineering cost, high usability return
UX-R3
Candidates must be able to upload a profile photo
The upload_files capability is not assigned to member. Candidates appear with placeholder avatars everywhere — including in the Mentor's My Connections list. This reduces trust in the first human touchpoint and creates inconsistency across user cards.
Confirmed (Gonçalo, March 2026): upload_files will be granted to member. Default avatar placeholder should be warm and inviting during the transition period — not a generic grey silhouette.
UX-R5
Add "Home" as first item in the top navigation
The main feed is unreachable from a labelled nav item. The only path is clicking the HearPeers logo — a hidden affordance that new users consistently miss.
Proposed nav order:
[ Home ] [ Groups ] [ Connections ] [ Chat ] [ Notifications ] ··· [ Profile ]
- Home = first item, leftmost after logo — consistent with every major social platform
- Active state applied when user is on the feed
Recommendation
UX-R4 — Guided onboarding flow
Establishing the three core relationships immediately: Area Manager (automatic) · Mentor (guided) · Groups (interest-driven)
Candidate — 4 steps
Step 1
Account created
Area Manager auto-connected
›
Step 2
Find Your Mentor
- 6 mentors, proximity order
- View profile modal
- Connect in-place
- Show more / Skip
›
Step 3
Discover Groups
- Multi-select interest tags
- Matching groups to join
- Skip available
›
Recipient — 5 steps
Step 1
Account created
Area Manager auto-connected
›
Step 2
Find Your Mentor
- Same pattern as Candidate
›
Step 3
Discover Peers
- Recipients + Mentors
- Area, language, interests
- Same card pattern
›
›
Shared UI patterns: Progress dots always visible · Skip on every step · Show more (6 cards + 2 rows/click) · Profile modal stays in flow · Connect in-place (card updates to Pending) · Re-entry resumes from last step
Referral special case: User arriving via HearPeers website Mentor link → Step 2 opens with referred Mentor in position 1 + profile modal auto-opens. Graceful fallback if Mentor is inactive at load time. → Q9 to confirm param convention with Lucas.
Additional Suggestions
CONN-S1 · S2 · S3 & ONB-S1 · S2
Connections page and onboarding improvements
CONN-S1 — Request inbox entry point
Badge on the Connections nav item when pending requests exist + "Requests" tab at the top of the page. Without a visible entry point users will not discover the inbox.
CONN-S2 — Empty state with contextual CTA
- Candidate: "Find a Mentor — connect with someone who's been through this before" → CTA to Mentor search
- Recipient: "Discover people near you" → CTA to Discover tab
CONN-S3 — Mentor card activity signal
6 Mentor cards look identical. Candidate has no signal of who is active or responsive. Suggested signals in preference order:
- "Usually responds within 2 days"
- Last active: "Active this week"
- Number of Candidates currently supported
ONB-S1 — Pre-select tags from registration
If interests were filled in during registration, arrive pre-selected in Discover Groups — not a blank slate.
ONB-S2 — Fallback for inactive referred Mentor
Do not auto-open modal, show 6 nearest active Mentors, soft message: "The mentor you were looking for is no longer available."
Summary
All changes to the Connections page design
23 items across corrections, recommendations, fixes, and suggestions
| # | Change | Type | Affects |
|---|
| 1 | Candidate can accept, decline, cancel connection requests | Correction | Candidate |
| 2 | Candidate can browse community — Mentors only scope | Correction | Candidate |
| 3 | Super Admin profiles hidden from all non-Super-Admin surfaces | UX-R1 | All roles |
| 4 | Area Manager auto-connected on user join (proactive) | UX-R2 | All roles |
| 5 | Area Manager in My Connections with Chat CTA from day one | UX-R2 | All roles |
| 6 | "Find Area Manager" dedicated search path (by area) | UX-R2 | Cand + Recip |
| 7 | Area Manager not shown in Discovery grid for Cand / Recip | UX-R2 | Cand + Recip |
| 8 | Candidate can upload profile photo (backend fix confirmed) | UX-R3 | Candidate |
| 9 | Invitation sending restricted to Mentor+ (closes SA loophole) | UX-R1 | All roles |
| 10 | Guided onboarding: Mentor selection step | UX-R4 | Cand + Recip |
| 11 | Guided onboarding: Recommended peers step (Recipient only) | UX-R4 | Recipient |
| 12 | Guided onboarding: Discover Groups step | UX-R4 | Cand + Recip |
| # | Change | Type | Affects |
|---|
| 13 | Referral entry: referred Mentor first + modal auto-opens | UX-R4 | Cand + Recip |
| 14 | Onboarding re-entry: resume from last completed step | UX-R4 | Cand + Recip |
| 15 | Add "Home" as first item in top nav | UX-R5 | All roles |
| 16 | Connection request badge on nav + "Requests" tab | CONN-S1 | Recipient+ |
| 17 | Empty state with contextual CTA per role | CONN-S2 | Cand + Recip |
| 18 | Mentor card activity / responsiveness signal | CONN-S3 | Candidate |
| 19 | Pre-select interest tags from registration data | ONB-S1 | Cand + Recip |
| 20 | Graceful fallback if referred Mentor is inactive | ONB-S2 | Cand + Recip |
| 21 | Area Manager card always visible — cannot be removed | UX-R2 | All roles |
| 22 | Area Manager card CTA always Chat — no other states | UX-R2 | All roles |
| 23 | Green online circle on profile photo — all connection cards | CONN | All roles |
Open Questions
9 questions to confirm with the team
Blockers and clarifications before finalising the design
| # |
Question |
Who to ask |
Impact |
| Q1 | Is Area Manager auto-connection on join proactive in the codebase, or only via auto-accept of incoming requests? | Lucas (dev) | New feature vs. bug fix (UX-R2) |
| Q2 | Is Mentor auto-connection on join implemented proactively? Same question. | Lucas (dev) | Mentor in My Connections day one |
| Q3 | Should Candidates and Recipients be able to send community invitations? Or restricted to Mentor+? | Julia / Alexandre | Closes Super Admin loophole (UX-R1) |
| Q4 | What should the "MED-EL" badge say to end users? ("Area Manager" or community-friendly label?) | Anna / Julia | UI label change |
| Q5 | Is there a Mentor auto-connection per area, or do Mentors serve globally? | MED-EL / Gabi | Scope of UX-R2 and "Find Area Manager" |
| Q6 | What interest tags are available for group discovery? Who curates them? | Anna / Julia | Onboarding Groups step (UX-R4) |
| Q7 | How many Mentors are typically available per area? | MED-EL / Gabi | Whether "Show more" is needed for small areas |
| Q8 | Should Mentor recommendations fall back to global if fewer than 6 available locally? | MED-EL | Fallback logic for small areas |
| Q9 | What is the referral URL parameter convention from the HearPeers website? Does it already exist? | Lucas + HearPeers web | Referral onboarding case (UX-R4) |
HearPeers Community · March 2026
Thank you
Gunther Eisen (Gonçalo Ferraz)
Lincoln Alves — Coopers Digital
goncalo.ferraz@coopers.digital
Next step
Confirm open questions with the team before finalising the Connections page prototype.
- Q1–Q2 → Lucas (auto-connection implementation)
- Q3–Q4 → Julia & Alexandre (product decisions)
- Q5–Q9 → Julia (analytics & UX policy)