Good Systems Do Not Need Explanations

Clarity is a property of design, not of communication.

We inhabit a world increasingly obsessed with explanation. Business decks, onboarding tutorials, enablement sessions, storytelling workshops. All crafted to "make things clear".

Yet perhaps clarity is not the issue. Perhaps the system itself lacks coherence. No amount of storytelling can resolve that.

True clarity does not arise from clever slides or confident delivery. It emerges from the system itself. When something has been crafted with care, it makes sense without requiring a narrator. One feels it. One trusts it. One uses it. There is no need to be persuaded.

A great system explains itself through use.

Craft Reveals Itself Without Commentary

A bicycle requires no keynote.
A firearm needs no onboarding.
A light switch does not warrant documentation.

Such systems succeed because their form and purpose align. Their interfaces carry intent. The user understands, not due to external explanation, but because the system has been designed with clarity.

The best systems are legible not through words, but through interaction. Each part tells a story: the grip, the balance, the feedback. These systems speak directly to the nervous system. Not to the intellect.

Craftsmen do not optimise for explanation. They optimise for experience.

And in doing so, they embed something else into the system: not just functionality, but care. Care in proportion, care in detail, and care in restraint. The result is not only usability, but calm. What feels effortless to the user often reflects an engineer's discipline made visible.

The More One Explains, The Less It Works

In contrast, fragile systems survive through theatre.

You will recognise them:

• Internal platforms that rely upon champions to continually re-explain their purpose.
• Agile processes sustained by ritual rather than outcome.
• Knowledge bases that expand faster than the product evolves.

These systems demand explanation not because they are complex, but because they are incoherent.

If a diagram is required to understand how to open a door, then it is not an intelligent door. It is a poor one.

In engineering, this is known as affordance. A well-designed object or system suggests its own use. It invites the appropriate interaction. When affordance is absent, explanation becomes a crutch.

In software, one of the most elegant expressions of this principle lies in LISP's homoiconicity: the idea that code and data share the same structure. This alignment makes reflection and metaprogramming intuitive rather than forced. It mirrors the purity of mathematics, where form and function intertwine. In such systems, the interface and its behaviour are so aligned that the system becomes not only usable, but almost self-revealing.

It is a masterclass in making things simple, not simplistic. A distinction that underpins all durable design. Moreover, it speaks for itself, remains simple, and therefore will likely prove resilient over time.

The Intuitive Mind Is Not the Enemy

When someone remarks, "It just feels wrong," they are often right.

This intuitive "affect-priming" reaction of a thoughtful user or engineer is frequently more accurate than a thousand hours of design theatre. Intuition enables us to process systems holistically. It operates quickly, before language, and speaks with honesty.

The difficulty in many organisations lies in how we have trained people to suppress this honesty. We reward compliance with broken systems rather than listening to the friction.

We encourage people to remain open-minded, when in truth we mean: "Please cease resisting the flawed construct we have produced."

Yet resistance is not the problem.
Resistance is a signal.

Design Is the Real Explanation

When systems have been designed with care:

• Trust forms without persuasion.
• Outcomes align without pressure.
• Navigation requires no handholding.

The system itself provides the explanation.
Its structure shapes behaviour. Its constraints offer guidance. Its flow builds confidence.

The true cost of poorly designed systems lies not merely in inefficiency, but in the perpetual need to explain, defend, and correct what ought to have been clear.

Each repeated explanation is a tax.
Each enablement session is a symptom.
Each workaround represents a lost opportunity for structural clarity.

This stands in stark contrast to systems bloated by misaligned abstractions: tools that require layers of documentation to bridge the gap between what they promise and what they actually do. In many enterprise stacks, one finds platforms so verbose, so entangled in configuration and ceremony, that no one dares touch them without hours of prior reading.

These systems are not resilient. They are brittle. Their survival depends on guardians, translators, and gatekeepers. And the moment those leave, the system decays.

Such designs fail because they are neither simple nor coherent. They may be powerful, but they do not speak for themselves. They require interpretation, and therefore, they erode trust over time.

Consider Kubernetes, a modern standard, yet rarely questioned on its merits. Its strength lies in flexibility, but that very strength comes at a cognitive cost. Even experienced engineers rely on layers of YAML, command-line tooling, and tribal knowledge. The system may scale infrastructure, but it does not scale understanding.

Enterprise resource planning systems such as SAP offer another cautionary tale. Designed to enforce structure, they often impose obscurity. Their workflows are rigid and their interfaces arcane. Organisations that depend on them frequently lose internal competence over time, adapting not to excellence, but to dysfunction.

Internal platforms are no exception. Many begin with the ambition to streamline and unify, but without relentless clarity, they drift into overreach. Tooling once meant to empower becomes something engineers tiptoe around. Verbose, slow, and burdened by undocumented edge cases. What was built to enable ends up controlling.

These examples differ in scale and domain, but share a fatal flaw: they rely on explanation to compensate for poor affordance. They expect trust without coherence. And over time, they decay, not through failure, but through exhaustion.

Clarity Is a Property, Not a Pitch

Clarity does not occur when the right person speaks.It occurs when no one needs to speak.

This is why storytelling cannot rescue broken systems.
It may obscure the flaws. It may delay scrutiny. It may generate buy-in.

... But it cannot repair the system.

One cannot explain one’s way to trust. One cannot narrate a system into adoption. One cannot teach their way out of incoherence.

The only meaningful path forward is to improve the system.
To realign the interface with the underlying intent.
To redesign until explanation becomes unnecessary.

You Know It Works When You Become Invisible

The most effective infrastructure teams are those rarely mentioned because everything simply functions.

The best internal tools require no office hours.
The best platforms operate without advocacy.

And the finest product experiences do not make users feel clever. They make them feel calm.
Because nothing obstructs their intent.

That outcome is no accident.
It is the highest expression of design, and, unsurprisingly, it reflects the mindset of the people who built it. Systems shaped by craft tend to carry the imprint of humility and focus. These are not features one layers on. They emerge through the rhythm and rigour of engineering practice.

"The calm a user feels is the echo of care. The simplicity they enjoy is the product of restraint. And the trust they place in the system flows from the quiet discipline of those who chose to build what works, not what dazzles."

That trust is not accidental. It is the emergent property of humility practiced consistently at every layer.

Rethinking Design as Embedded Craft

Let's agree on this :

• If your system requires a champion, it likely needs a redesign.
• If your strategy demands a pitch, it may lack structure.
• If your team continually seeks alignment, the issue may not lie with the individuals.

Perhaps the system ought to speak more clearly and without words.

And perhaps, provocatively, we should also revisit the idea of design as a distinct function. Not to diminish its importance, but to embed it more deeply within the craft itself. Just as we now expect engineers to own quality through automated testing, the notion of "design" might also evolve from a standalone discipline to a foundational competence.

In this view, the best systems emerge not from handoffs between roles, but from coherence within them. The engineer who shapes the system must also feel responsible for its legibility, usability, and flow. Design, then, is not a role , but a responsibility.

Those who call themselves designers may well become stewards of a broader design platform, one that equips others to build with intent, not one that guards intent from others. The future of craft is not siloed excellence, but integrated clarity.