The Override Button We Deleted

The book club picker had an override button. You could skip the random selection and manually choose the next book.

We deleted it.

Not because it was buggy. Because it worked too well.

The Sacred Principle

Our book club has one inviolable rule: series order is sacred.

You cannot read Book 2 before Book 1. You cannot skip to the finale because it sounds interesting. You cannot "just peek" at the next book while we're in the middle of something else.

This sounds obvious. It's not.

The temptation is constant. "I really want to read The Drawing of the Three, but we're in the middle of The Broken Earth."

The override button made that temptation actionable.

So we removed it.

What the Override Enabled

The original interface had a "Manual Selection" button. Click it, choose any book from the list, confirm.

The intent was flexibility. Sometimes you know what you want. Sometimes the random selection feels wrong.

Here's what actually happened:

Every override had a reasonable justification. Each individual override seemed fine.

But the pattern was clear: the override undermined the entire system.

Why Removing Options Improves UX

Counter-intuitive claim: good UX sometimes means removing choices.

• ● The paradox of choice: More options create more decision fatigue. Every selection asks "is this right?" When there's only one option, that question disappears.
• ● Commitment design: Some decisions should be hard to reverse. Making them easy invites second-guessing.
• ● Argument elimination: If the override doesn't exist, neither does the argument about whether to use it.

The picker isn't just selecting books. It's settling debates before they happen. The machine's authority prevents human negotiation.

The Continue/Pause/Drop Decision

We didn't eliminate all choice. We concentrated it.

After finishing any book in a series, the picker presents exactly three options:

• ● Continue: The series becomes ACTIVE. The next book is automatically selected. No randomness until the series completes.
• ● Pause: The series goes dormant. Not in the random pool. We can unpause later.
• ● Drop: Done. Not finishing it. Removed permanently.

+-----------------------------------------+
|       You've finished Book 2 of 6       |
|           The Broken Earth              |
|                                         |
|   What would you like to do?            |
|                                         |
|   [Continue]  [Pause]  [Drop]           |
|                                         |
|   Continue: Next pick will be Book 3    |
|   Pause: Series exits random pool       |
|   Drop: Series removed permanently      |
+-----------------------------------------+

This is a real decision with real consequences. But it's scoped—about this series, not an open-ended choice about what to read next.

Can't Be Undone

Pause can be undone. Continue can pause.

But Drop is forever.

This is intentional friction. If dropping is trivially reversible, it's not really dropping—it's "maybe later." The commitment isn't real.

When you Drop:

• ● The series disappears from all interfaces
• ● Its books are not in the random pool
• ● There's no "restore" button
• ● The decision is logged but not revisitable

This sounds harsh. It's actually freeing. Once dropped, a series doesn't haunt the list. You never have to think about it again.

The Paradox: Rigid Rules Create Freedom

Here's the thing: the book club is more fun now.

Before the constraints, every pick sparked micro-negotiations. "Are you sure?" "Maybe we should..." "What about instead..."

With the constraints:

• ● No debate about series order. The system enforces it.
• ● No override temptation. The button doesn't exist.
• ● No guilt about dropping. We explicitly decided.
• ● No ambiguity about what's next. The machine told us.

The constraints removed cognitive overhead. We spend less energy managing the system and more energy reading.

Freedom through constraint isn't paradox—it's design.

User Research Sample Size: 2

I sometimes worry this whole project is over-engineered for two people.

Then I remember: sample size doesn't determine validity, relevance does.

We are the users. We know exactly what we need. We can iterate instantly based on real usage.

Most "user research" tries to generalize across populations. Our research asks: does this work for us?

That question has a sample size of 2, and that's enough.

When to Be Flexible vs. Strict

Not every feature should be rigid. Here's the framework:

The picker is strict about what it does (selection, ordering) and flexible about how it looks (themes, display preferences).

The Error When Trying to Skip

If someone tries to access a later book directly (via URL manipulation or API), they get an error:

Cannot select Book 3: The Stone Sky
Series prerequisite not met.
Book 2: The Obelisk Gate must be completed first.

Series order is sacred.

The last line isn't snark—it's documentation. The system isn't broken. It's working as designed.

The Takeaway

"Discipline equals freedom."

— Jocko Willink

Removing the override button improved the product.

Not because overrides are always bad. Because for THIS product, for THESE users, the override undermined the core value proposition.

The rigidity IS the feature.

Consider what options your product offers that might be undermining its core purpose. Sometimes the best UX improvement is deletion.

Part 11 of "The Craft of Small Tools" series.

Textstone Labs — AI implementation for people who build things.