Provide a constraint checklist for design decisions. Every design choice should be traceable to one of these principles. If a decision cannot be traced back, it needs re-examination.
The tool adapts to the person, not the person to the tool.
Most tools are designed as: “The tool provides features, the person learns to use them.”
The correct approach is reversed: “First understand what the person actually does, then decide what the tool looks like.”
This is not marketing copy. It is the litmus test for every design decision. If a feature makes the user feel “I am accommodating this tool,” the feature is wrong.
Physics: The second law of thermodynamics – entropy (disorder) in a closed system only increases, never decreases spontaneously.
Applied to product development: Without active management, features only accumulate, complexity only grows, and systems never simplify themselves.
Entropy increase is the natural state. Entropy reduction is an active choice.
| Area | Entropy Reduction Practice |
|---|---|
| Feature design | Only build what solves a validated core pain point |
| Interface design | Eliminate every unnecessary operation step |
| Code design | Do not add dependencies unless unavoidable |
| Development workflow | Eliminate unnecessary waiting time (e.g., mock backends) |
Before any “should we add this?” decision:
All three answerable -> then consider adding.
Should we add this feature?
|
What pain point does it solve?
|
Is this pain point validated (with real users)?
|
What is the maintenance cost?
|
Maintenance cost < pain point value --> add
Maintenance cost >= pain point value --> do not add
Before adding any package, ask:
Design order: First ask why it exists, then design how it works.
Wrong order (Outside-In): See what competitors built -> copy features -> rationalize after
Right order (Inside-Out): Confirm the core pain point -> define “what solving looks like” -> design features
Reasoning chain: Why (purpose) -> What (corresponding feature) -> How (specific design)
Reverse must also work: How (why designed this way) -> What (which requirement) -> Why (back to user pain point)
If the reverse chain breaks, the design has a problem.
The user must always know three things while using the tool:
When these three are achieved, the user has a sense of control.
Failure is not an identity verdict. It is a debug record.
Two layers of application:
| Layer | Practice |
|---|---|
| Product design | When the user makes a mistake, the UI says “try this instead,” not “you are wrong” |
| Development workflow | When you hit a pitfall, record it in lessons, learn, do not repeat – failure is learning material, not shame |
| Aspect | Serotonin Design (recommended) | Dopamine Design (common in industry) |
|---|---|---|
| Goal | User finishes and leaves calmly | User keeps coming back |
| Means | Sense of control, feeling understood, clear next steps | Notifications, progress bars, infinite levels |
| User feeling | “The tool did its job” | “I need this tool” |
| Long-term effect | User trusts the tool, recommends it | User depends on the tool, but also resents it |
| Example | Document is done, session ends, no “come back” hooks | – |
Core of serotonin design: The tool completes the task. The user continues with their life.
| Entropy Increase Thinking | Entropy Reduction Thinking |
|---|---|
| Add features to make the product stronger | Only add features that are truly needed |
| Users asked for it, so add it | First ask what the user’s actual need is |
| More complex code = smarter | Simpler code = harder to break |
| Build first, figure it out later | Define the correct standard first, then build |
| More dependencies = more powerful | More dependencies = higher maintenance cost |
| Documentation comes after | Documentation is part of design |
After every design decision, run this two-way check:
Forward:
User pain point --> which feature --> specific design --> which principle it embodies
Reverse:
Design decision --> which principle --> which need it serves --> is the need real or assumed
Reverse chain breaks = design has a problem, or the principle needs updating.
| # | Engine | Judgment Question |
|---|---|---|
| 1 | Entropy Reduction | Is the system cleaner after than before? Does every addition have a clear responsibility? |
| 2 | Underlying Migration | Strip the labels, keep the skeleton – can it transfer to another domain? |
| 3 | Inside-Out | Did we ask why it exists before learning how to use it? |
| 4 | Externalized Meta-Framework | Is state visible? Is the next step clear? Are errors guidance, not verdicts? |
| 5 | Serotonin Design | Does it let users finish and leave calmly? No addiction hooks? |
| 6 | Failure = Log | Is failure a debug record, not an identity sentence? |
| 7 | Three-Question Test | Simpler for users? Easier for engineers to maintain? Better for future extension? |
| 8 | Opinionated Design | When there is a best answer, does the system decide without asking the user? |
| 9 | Separation of Concerns | Does the system manage its own chaos without overstepping into user decisions? |
| 10 | Discrete Code, Continuous Validation | Does deterministic logic produce a “this understands me” feeling? |
| 11 | Four-Layer Architecture | Built from the principle layer up, not guessing down from the experience layer? |
| 12 | Gray-Scale Thinking | Marks applicability boundaries instead of binary right/wrong judgments? |
Before finalizing any design decision: