Part 1: Translation into UX Requirements

(From lived friction → system-level requirements)

A. What the current role model claims to do

Help users quickly signal sexual compatibility

Reduce friction by simplifying preferences into labels

Enable efficient matching through shared terminology

B. What it actually requires from users

Over-disclosure: Users must collapse situational, relational, and contextual preferences into a static identity.

Performative legibility: Users are pressured to choose labels that are readable to others, not accurate to themselves.

Defensive self-curation: Users anticipate misuse of labels and pre-emptively withhold or distort information.

Emotional labor: Users must repeatedly explain, renegotiate, or correct interpretations created by the system.

C. Where responsibility is displaced

The system:

Treats interpretation errors as interpersonal misunderstandings, not design failures.

Offloads the cost of ambiguity onto the user (“just communicate better”).

Rewards users who ignore nuance (e.g., “tops” who expect versatility from “verse bottoms”).

Normalizes entitlement by making certain roles appear functionally available on demand.

In short:

The system enforces clarity for browsing, but ambiguity for accountability.

---

Part 2: UX Requirements (Concrete)

Requirement 1: Separate Preference from Availability

Sexual role ≠ perpetual consent

System must not encode liking something as always accessible

UX implication

No role label should imply default availability

Preferences must be explicitly framed as conditional, not guaranteed

---

Requirement 2: Reduce Interpretive Load on the Receiver

Users should not have to decode what others “really mean” by labels

The system should carry semantic precision, not users

UX implication

Labels must be operationally constrained

Free-text explanations should not be the primary repair mechanism

---

Requirement 3: Prevent Role-as-Commodity Behavior

The current system allows users to “shop” for bodies/functions

This disproportionately burdens people labeled closer to receptivity (e.g., bottoms, verse bottoms)

UX implication

Role indicators should not function as filters that imply service

Matching should not imply entitlement

---

Requirement 4: Make Misalignment a System Signal, Not a Personal Failure

Repeated misunderstandings indicate a structural issue, not bad communication

UX implication

The system should surface contextual mismatch early

Ambiguity should pause interaction, not accelerate it

---

Part 3: One Draft Alternative Role Model (Prototype-Ready)

Replace Static Roles with a Contextual Compatibility Model

Instead of:

Top / Bottom / Vers / Side

Use:

Interaction Preferences (Contextual & Conditional)

Each user sets preferences across three independent axes, none of which imply default access.

---

Axis 1: Primary Enjoyment Tendency

(What you generally enjoy most — not what you always do)

Options:

Primarily receptive

Primarily insertive

Flexible depending on connection

Not role-focused

Tooltip: “This describes enjoyment, not obligation.”

---

Axis 2: Situational Availability

(How often this preference applies)

Options:

Rarely

Occasionally

Often

Context-dependent

This explicitly breaks the “if you like it, you’ll do it” assumption.

---

Axis 3: Negotiation Requirement

(How much discussion is needed before sex)

Options:

Requires conversation every time

Requires mutual initiation

Comfortable with spontaneous alignment

Not applicable

This makes consent and pacing visible before messaging.

---

How Matching Changes

Matches surface compatibility ranges, not exact matches

Messaging prompts acknowledge conditionality:

“Your preferences overlap in some contexts. Want to talk about what that looks like for you?”

---

What This Model Fixes

Removes role-as-service assumptions

Prevents “verse” from becoming a loophole for entitlement

Makes ambiguity explicit and shared

Transfers interpretive labor back to the system

Allows users to remain truthful without overexposing themselves

---

Final Note (for the product team)

This is not about adding complexity.
It’s about moving complexity from people to structure.

The current model optimizes for browsing speed at the cost of:

consent clarity

emotional labor

misaligned expectations

user burnout

The proposed model does not propose better behavior. It proposes better containment.

If you want, next step we can:

write this as an internal product memo

turn it into acceptance criteria

or stress-test it against edge cases (e.g., hookups vs dating, kink vs vanilla, new users vs experienced)