Hodo-Hodo: The Japanese Philosophy That Could Fix Web Design

The Book That Changed How I See Websites

I have recently read Just Enough Design by Taku Satoh, a slim but powerful book published by Chronicle Books. Satoh is one of Japan’s most respected living designers — he has shaped everything from packaging for major brands to museum exhibits — and in this book he distills decades of work into a single idea: hodo-hodo (ほどほど).

The word is ancient Japanese. It means “just enough,” “moderation,” or “the right amount.” When Satoh applies it to his work, it becomes a design philosophy: deliberately holding back, leaving room for the person on the other side to engage with an object according to their own sensibility.

Reading it, I kept thinking about the web. Not abstractly — I kept thinking about specific buttons, specific modals, specific JavaScript bundles that I encounter every day. Hodo-hodo is not minimalism for its own sake. It is restraint as respect. And the modern web has almost none of it.

What Hodo-Hodo Actually Means

Satoh does not advocate for austerity. He is not telling designers to strip everything away until only a single black link on a white background remains. That is a Western misreading of Japanese simplicity.

Hodo-hodo means that a design should provide exactly what is needed and no more. Not less — not a stripped-down, frustrating experience — but not more, either. The extra is not just unnecessary; it is disrespectful. It assumes the user cannot figure things out on their own. It assumes they need to be managed, guided, nudged, and entertained at every step.

The concept connects to other Japanese aesthetic ideas: ma (the meaningful use of negative space), wabi-sabi (beauty in imperfection), and shibui (unobtrusive beauty). But hodo-hodo is specifically about restraint in service of the other person. It is design that says: I trust you.

The Web’s Abundance Problem

Modern web design has an abundance problem. Not an abundance of content — an abundance of stuff that does not need to be there.

Consider what a visitor encounters on a typical website in 2026:

• A cookie consent banner (even on sites that use no tracking)
• A newsletter popup after 30 seconds
• A notification permission prompt from the browser
• An install app banner
• A “Sign up for free” modal with an X that is intentionally hard to find
• A chat widget that slides in from the corner
• An accessibility overlay that actually makes the site less accessible
• A “Back to top” button that appears before you have scrolled past the first paragraph

None of these exist because the designer thought: “This will make the user’s experience better.” They exist because someone decided the user needed to be captured, converted, or retained. The user’s actual task — reading an article, finding a phone number, understanding a product — is secondary to the business goal of keeping them engaged.

This is the opposite of hodo-hodo. It is more-more design. More features, more prompts, more distractions, more “value-adds” that add nothing of value.

The Framework Trap

The abundance problem is not limited to marketing patterns. It is baked into the tools themselves.

When a developer starts a new project in 2026, the default is to reach for a framework. Need a personal site? Next.js. A blog? Astro or Gatsby. A landing page? Probably still React, because that is what the developer knows.

Each of these frameworks ships with a runtime. Hydration logic. State management conventions. Build tooling. Configuration files. The developer spends hours setting up the machinery before writing a single line of meaningful content.

Satoh would call this design that serves the designer, not the user. The framework makes the developer’s life easier (or more familiar), but the user receives a page that is heavier, slower, and more complex than it needs to be. A blog post does not need a JavaScript runtime. A contact form does not need a virtual DOM. A portfolio does not need server-side rendering.

The hodo-hodo approach would be to ask: What is the minimum technology that serves this content well? For most websites, the answer is HTML, a small amount of CSS, and vanilla JavaScript for the few interactions that genuinely require it. Everything else is excess.

What Hodo-Hodo Looks Like on the Web

It is easier to describe what hodo-hodo is not than what it is. So let me try to describe what it looks like when a website gets it right.

System Fonts, Not Font CDNs

A hodo-hodo site uses the system font stack. Not because custom fonts are wrong, but because loading a 400KB font file to render a heading in a slightly different serif is a trade-off that rarely benefits the user. The system font is instant. It is already there. It respects the user’s existing environment.

If a custom font is genuinely necessary for the brand — a newspaper, a design studio — it should be subset, self-hosted, and loaded with a proper font-display strategy. Not shoved through a Google Fonts CDN with seven weights and three styles.

Dark Mode as a Quiet Option

A hodo-hodo dark mode toggle does not announce itself. It does not slide in from the side with an animation. It sits in the header, a small button that respects the user’s system preference by default and allows manual override when requested. The transition is immediate — no flashing, no animation, no drama.

Content That Breathes

Whitespace is not wasted space. A hodo-hodo layout gives content room. The line length stays between 60 and 80 characters. Paragraphs are separated by generous margins. Headings have breathing room above and below. The page does not feel crowded, even when it is dense with information.

This is ma — the Japanese concept of negative space as a design element itself. The space between things is not absence; it is presence. It is what allows the content to be read, understood, and remembered.

Interactions That Disappear

A hodo-hodo interaction is one you do not notice. The copy button on a code block appears on hover and disappears after use. The search bar opens with a keyboard shortcut and closes with Escape. The mobile menu toggles without animation, without a backdrop overlay that dims the entire page.

The goal is not “no interaction.” It is interaction that does not call attention to itself. The user performs a task and moves on. They do not admire the animation. They do not think about the UI. They think about what they came to do.

No Dark Patterns

A hodo-hodo site does not trick the user. The “unsubscribe” link is as prominent as the “subscribe” link. The close button on a modal is in the expected location and is the expected size. The privacy policy is written in plain language, not in legal jargon designed to obscure.

Satoh’s point is that restraint is a form of respect. When you manipulate the user — when you make the “No thanks” button gray and small while the “Sign up” button is blue and large — you are telling the user that you do not trust them to make the right choice. You are designing for yourself, not for them.

The Paradox of the Hodo-Hodo Website

Here is the uncomfortable truth: achieving hodo-hodo on the web often requires more engineering, not less.

A clean, fast, accessible website is harder to build than a bloated one. It is easier to add a React dependency than to write semantic HTML. It is easier to install a cookie consent library than to ensure your analytics respects privacy by design. It is easier to add a chat widget than to write a clear, findable contact page.

The simplicity the user sees is the result of disciplined engineering behind the scenes. This is exactly Satoh’s point. Hodo-hodo is not laziness. It is not cutting corners. It is knowing where to stop — and that requires a depth of understanding that casual excess does not.

A developer who adds seven npm dependencies to build a button has not thought enough about the button. A designer who adds a particle animation background has not thought enough about what the page is for. Hodo-hodo demands that you think before you build, not after.

A Practical Checklist

You do not need to adopt a Japanese philosophy to build a better website. But if hodo-hodo resonates, here are some concrete questions to ask before shipping your next project:

1. Does this feature serve the user or the business? If it serves the business at the user’s expense, remove it.

2. Can this be done without JavaScript? If the interaction works without JS, do not add JS. If JS is necessary, use the smallest possible amount.

3. Is this the right amount? Not “can we add more?” but “is this enough?” The answer is usually yes.

4. Does this respect the user’s attention? Every element on the page competes for attention. Be deliberate about what you put in front of them.

5. Would this make sense to someone who has never seen a website before? If the design requires explanation, it is too clever.

6. Can I remove this without the user noticing? If yes, it should not be there.

7. Am I designing for the user or for my portfolio? Be honest.

Closing Thought

Satoh writes that hodo-hodo is not about achieving a specific aesthetic. It is not about making things look minimal. It is about a relationship — between the designer and the user, between the object and the person who uses it.

The web has forgotten this. We design for metrics, for engagement, for conversion rates. We A/B test button colors and measure time-on-page and call it “user experience.” But the user did not come to have an experience. They came to read an article, or find a recipe, or check a bus schedule. Everything we add between them and their task is a failure of hodo-hodo.

The quietest website is not always the best website. But the website that provides exactly what the user needs — and nothing more — is the one they will trust. And trust, in the end, is worth more than any conversion rate.

I will leave you with Satoh’s simplest insight, translated from the Japanese: “Just enough is not less. It is precisely enough.”