Hey guys, it's Non here.
Coffee in hand. The Four Noble Truths are, structurally, a design brief: name the suffering, find what causes it, define what its ending looks like, build the path there. It is two and a half thousand years old, and it is better organised than most briefs I have been handed this year.
Think about that feeling of constant, low-grade irritation. You know the one. It is that nagging sense that something is slightly off. Maybe you are sitting in a chair that feels just a bit too stiff.
Or maybe you are using an app that requires three extra clicks to do something that should only take one. It is not a tragedy. It is not a crisis. It is just a persistent, dull friction in your day.
I see this every time I look at a product or a service that fails to work with us. I spend my days hunting for these moments of friction. I see a poorly designed door handle and I feel a tiny spike of annoyance. I see a website that confuses the user and I feel a different kind of irritation.
This is what we are dealing with. It is a chronic unsatisfactoriness. It is the gap between how things are and how they could be. If we don't address this friction correctly, we waste our lives.
We spend energy fighting against the furniture of our own existence. We end up exhausted, moving slower and feeling heavier, without ever knowing why. If you just keep trying to "work harder" without identifying the source of the friction, you are just spinning your wheels in the mud. You are burning fuel but you aren't moving.
This is why the structure of a design brief is so powerful. It forces us to stop complaining and start diagnosing. It demands that we name the problem before we try to fix it. We need to know exactly what is making life feel heavy.
If we get the diagnosis wrong, every solution we build will be useless. It will be a feature that nobody actually needed. We are going to look at how a two thousand year old framework handles this exact problem.
The Venerable Ajahn Jayasaro writes the following about the meaning of Buddha's Four Noble Truth: "There is dukkha -- a chronic unsatisfactoriness of unenlightened existence; There is a cause of dukkha." When I say "chronic unsatisfactoriness," I mean that feeling of being slightly, constantly out of sync with your own life. It is not a tragedy that hits you like a lightning bolt. It is the low-grade hum of a refrigerator that never turns off.
It is the friction of a shoe that rubs your heel every step you take. You eventually stop noticing the shoe, but your foot still hurts. In my work, I see this in products all the time. You use a piece of software that is technically functional, but it feels like a chore to navigate.
You are doing the work, but you are also fighting the tool. That fight is the friction. It is the "dukkha" of the user experience. It is a persistent gap between the way a thing works and the way you actually want it to work.
If we don't identify that specific friction, we just keep building more things that make your life slightly more annoying. Now, if you want to understand why this friction exists, we have to look for the source. We have to find the "cause." There was a man named David Hume who spent much of his life worried about how we can actually be sure of anything we know.
He was a bit of a skeptic, and he lived in a world where he saw people constantly making huge mistakes because they believed things that weren't true. He called this problem the problem of induction, which is the fancy way of saying we assume the future will look like the past just because it always has. If we take his worry and apply it to our own lives, we see something profound. We assume that if we just keep doing what we have always done, things will stay the same.
We think our habits are our identity. We think our desires are just "who we are." But Hume would suggest that these are just patterns of cause and effect. We are reacting to things based on a script we didn't write.
We see a craving for a new phone, or a need for status, or a fear of being alone, and we think these feelings are the boss of us. I think the cause of our dissatisfaction is our inability to see the script. We are like people trying to fix a leaky pipe by mopping the floor. The mopping is our reaction.
The leak is the cause. We see the "want" as the problem, but the "want" is just the symptom. The cause is the underlying condition that makes us react to the world in a way that leaves us feeling empty. It is the habit of looking outward for a feeling that can only be settled by looking inward at how we process reality.
If we don't find that specific leak, we are just going to keep mopping forever.
You might be right to push back on this. A smart person looking at my argument would say that I am oversimplifying how we actually live. They would tell me that sometimes the friction isn't a "script" or a "leak" in our psychology. Sometimes the friction is just a broken chair.
Sometimes it is a literal, physical shortage of food, or a corrupt government, or a disease that doesn't care about your internal processing of reality. They would argue that by focusing on the "cause" as an internal habit, I am letting the people who actually cause our suffering off the hook. They would say that if you have a broken leg, the cause is the accident, not your "unawareness" of the physics of falling. They would call my view a luxury of the comfortable.
That is a fair point. If we only look inward, we risk becoming people who try to meditate our way out of a famine. We risk becoming so obsessed with our own "scripts" that we ignore the very real, very external walls of our world. If I tell you that your dissatisfaction is just a trick of your own mind, I might be ignoring the fact that your mind is reacting to a very real, very painful environment.
But here is the part worth stealing. Even in those external problems, there is still a structural logic at work. If we only address the external symptoms without ever looking at the mechanics of why we are reacting to them the way we are, we are still just mopping. We are treating the floor, but the water is still coming from somewhere.
"It is dependent upon certain causes and conditions; There is a cessation of dukkha; and, There is a path leading to the ending of dukkha. Now, to me, I think that is quite obvious the similarity between the 4-fold process of design thinking and the 4-fold process of the Four Noble Truth." When I say that similarity is obvious, I mean that both systems are trying to do the same thing: they want to move us from a state of "not-quite-right" to a state of "right." In design, we look at a user who is frustrated by a confusing button.
We don't just want to change the color of the button. We want to understand the condition of their confusion. We want to define what a seamless experience looks like. And then, we build the path to get them there.
We are trying to solve for the human experience. If we don't do that, we are just making pretty things that people hate using. We are just creating more friction.
Think about the last time you sat in a meeting to decide on a new project or a way to change a process. You were looking at a list of requirements. Maybe you were looking at a list of "pain points" from a client or a customer. Now, look closely at that list.
Is it a list of actual problems, or is it just a list of things people are tired of complaining about? There is a massive difference between the two. One is a symptom. The other is the cause.
Most of our work is spent on the symptoms. If a customer complains that a software interface is too slow, the immediate reaction is to buy faster servers. That is the "mopping the floor" approach. It feels like progress because the floor is dry for a moment.
But if the reason the interface feels slow is actually a fundamental confusion about what the software is supposed to do, faster servers won't fix it. You are just building a faster way to be confused. You are creating a more efficient way to feel that low-grade irritation. I want you to think about a specific moment this week.
Maybe it was a request from your boss, or a comment on a design you submitted, or a task you had to complete that felt like a chore. When you looked at that task, did you ask why it existed? Or did you just ask how to do it faster? Most of us are trained to find the fastest path to a finished task.
We are rewarded for checking boxes. But checking a box doesn't mean the friction has disappeared. It just means you've moved the friction to a different part of the day. This is where the design brief of the Four Noble Truths actually matters for your work.
It asks you to be a diagnostician. It asks you to look at the "chronic unsatisfactoriness" and refuse to settle for the first thing you see. If you are asked to build a new feature, stop and ask: what is the actual condition of the person using this? What is the underlying "leak" in their experience?
"I particular like the idea of Dukka (Pli; Sanskrit: dukha; Tibetan: ) !% being "a chronic unsatisfactoriness of unenlightened existence" (also translated as "the lack of true happiness." I mean, how many times that we have complained about a product, service, and experience that cause us some kind of chronic dissatisfaction? As someone who constantly looks for good design, this is the dukka that I have to deal with daily." When I say this is the dukkha I deal with daily, I mean that my job is to be the person who points at the fact that "good enough" is often just a way of hiding a deeper problem.
It is easy to build something that works. It is much harder to build something that feels right. If you can learn to see the difference between a loud complaint and a deep, structural friction, you stop being a laborer who just moves dirt around. You start becoming an architect of experience.
You start solving for the human, not just the ticket.
But the obvious question (AKA "the elephant in the room") is shouldn't we be asking the most basic question: Is your noodle delicious? This is a great example of an instance in which if we only have a hammer all problems will be nails. When I say that, I mean that we often mistake our tools for our goals. If your only skill is "making things faster," then every slow process becomes a "speed problem" to be solved with a faster server.
We treat the symptom because it’s easy to measure. We ignore the deeper, structural friction because it’s harder to name. But if we keep using the hammer of efficiency to fix a problem of confusion, we aren't actually designing anything. We are just rearranging the furniture in a room that’s on fire.
So here is the question that keeps me up when I look at a project that’s "done" but still feels wrong. If we strip away the features, the buttons, and the "fast" interfaces, what is the actual human experience we are trying to protect? How do we know if we’ve actually removed the friction, or if we’ve just found a more sophisticated way to ignore it?