Conditional waiver claims and immediate player drops

A player-page Drop action creates an immediate release outside the conditional waiver claim

Proposed mechanism: a manager selecting a player for a conditional waiver claim may navigate to the player's page and confirm an immediate drop while believing the action remains part of the claim.

UX case · Sleeper fantasy football · one screen recording (8 Oct 2026), an interactive reconstruction, and a policy simulation

1recording of the flow in my own account, with observation in one league over about two years

3changes prototyped against the recorded baseline

25,000simulated claim transactions: five interface versions, five behavioral policies, and 1,000 runs per combination

Waiver claim sequence

The drop is conditional on the claim, but no screen says so

Waiver list with the Las Vegas Raiders on waivers — The Raiders defense is on waivers (the W badge). Plus starts a claim.

Add Las Vegas Raiders sheet: select player to drop — "Your roster is full, please select a player to drop." A radio button beside each player.

Confirm transaction: add L. Raiders, drop T. McBride, waiver #1 — Add, drop, waiver #1. The drop happens only if the claim succeeds, and the screen does not say it.

Frames cropped from the recording. Usernames, league chat, and league name removed.

Transition from claim selection to player-page drop

Tapping the name leaves the claim for a page whose main action drops the player now

Claim sheet — Two targets per row: the radio selects for the claim, the larger name opens the player page.

Player page with a Drop button — A different task. Its most prominent action, Drop, starts an immediate, unconditional drop that takes effect after confirmation.

Are you sure? Please confirm you want to drop this player — "Are you sure?" confirms the action without naming its consequence.

The problem is their interaction: a target that leads from a conditional claim into a separate task whose main action appears to satisfy the instruction.

Drop-first behavior as a proposed learning mechanism

A second claim can be submitted, making the preceding drop appear necessary

Claim sheet
roster full

›

Tap the name
player page

›

Drop, then "Drop"
immediate

›

Claim again
open roster spot

›

Confirm
no drop screen

A possible learned rule: drop first, then claim. Nothing says the first drop was unnecessary or could have been conditional.

Consistent with what I have observed in my league. Showing that the interface causes this learning would require following managers over time.

The cost is immediate: the player is released whether or not the claim succeeds.
If the claim fails, the manager has lost that player without the replacement.
Two problems: a mistaken tap during a claim, and an established drop-first habit.

Prototype interface changes

Three changes, prototyped against a reconstruction of the recorded flow

Whole row selects — The whole row is a native radio control. A separate 44-pixel button opens player details.

Player page knows about the claim — The page names the claim and offers "Select for this claim" first.

Dialog states the drop is immediate and separate — The confirmation states the immediate consequence. “Back to claim” is the primary action.

Standalone drop dialog explains conditional drops — A drop from the team page explains that a claim can carry a conditional drop.

Confirmation states the conditional rule — "Dropped only if your claim succeeds."

In the reconstructed interface, whole-row selection removes the tested name-navigation pathway from the claim. Context and protection preserve access to the player page while distinguishing immediate from conditional drops.

Simulated outcomes by assumption

Selection and context eliminate the tested detour. Protection outcomes depend on the assumed probability of following the warning.

Immediate drops	Name	Row	Drop-first
Baseline prototype under assumed behavioral policies	81%	82%	100%
Selection: whole row selects	0%	0%	100%
Context: page names the claim	0%	0%	100%
Protection: dialogs state consequence	33%	33%	40%
Combined	0%	0%	40%

Each policy-version combination contains 1,000 simulated transactions. Every run ended with a submitted claim. Radio-button and deliberate-check policies never dropped. In 38 to 42% of baseline name and row runs, the drop was followed by a failed claim. Drop-first rates follow from its assumption by construction.

Five tapping policies act on the prototype's rendered targets: radio button, middle of the row (then the name), the name, a deliberate check of the player page, and drop-first from the team page.

Assumptions: prominent action 0.7 · confirm "Are you sure?" 0.9 · retry with the radio 0.5 · Back to claim 0.6 · Keep player 0.6 · claim succeeds 0.5.

Sensitivity: protection 60% at heed 0.3, 7 to 9% at 0.9 · baseline 91% at retry 0.2, 73% at 0.8.

The simulation shows which behaviors each design interrupts and which assumptions govern it, not how often real managers make the error.

Identification of candidate errors from event sequences

Candidate error sequences requiring intent validation

Full-roster claim sheet
for player A

›

Own player page
opened from the sheet

›

Immediate drop
of that player

›

Claim for A
no drop attached

Measures

Candidate mode-error sequence rate among full-roster claim episodes
Failed claims, players taken by others, timing
Validation against intent, with managers who completed the sequence
Repeated drop-first behavior over time and a separate experiment testing the selection change

What the logs cannot settle alone

A deliberate manager can produce the same sequence, and persistence does not reveal the belief behind it. Testing differences by age requires a measure of the manager's age. Account age measures time on the platform, not the person's age.

Recommended selection and confirmation changes

Whole-row selection and conditional-drop information at confirmation

Recommendation

First: the whole row selects a conditional drop, with a separate, accessible details control.
Then: a player page that knows about the claim, and a drop dialog that names the consequence.

The habit outside the claim

A drop-first manager releases a player before any claim. A standalone drop confirmation and the claim confirmation both state the conditional rule. Whether that changes later behavior has to be tested.

Observed in a recording and one league, reconstructed, and simulated under stated policies. Open: how often managers take this path, why, and which change alters their behavior over time.