Claudio Lassala's Blog

Years ago, I heard that Behavior-Driven Development (BDD) was a better version of TDD. A more structured way to write tests before writing code. Over time, that view shifted completely. What changed wasn’t the tooling or the process; it was what I noticed happening in the room before any code was written.

BDD, at its best, is a communication methodology. The automated tests are a byproduct. The real value is what happens when a business stakeholder and a delivery team sit down together and try to complete a story (“In order to… As a… I want to…”) and discover they can’t meaningfully finish that first sentence, or that they can’t articulate those “Given… When… Then…” phrases.

The Napkin Test

A common misconception I run into is that BDD requires a sophisticated CI/CD pipeline or a specific testing framework to be valid. It doesn’t. You can do BDD on a napkin.

The structure, “Given this happened, When this other thing happens, Then this is expected in the future,” is a spoken language before it’s a code syntax. Its job is to surface misalignment before it becomes expensive. The automation comes later, as a side effect of having had good conversations.

When I’m asked why I still advocate for BDD in teams that resist it, my answer is simple: I do it because it improves communication and collaboration when I’m trying to build the right thing, not just when I’m building things.

A Surprising Connection: Sinek Meets Clear

Something clicked for me when I started drawing arrows between two books I’d been reading separately: Simon Sinek’s Start With Why and James Clear’s Atomic Habits.

Sinek’s Golden Circle moves outward from Why to How to What. Clear’s layers of behavior change work similarly. The deepest, most durable change happens at the identity level, not the outcome level.

I pondered that to understand why I’m a BDD/TDD practitioner:

• Why = Identity: What you believe, who you are. The most powerful change starts here.

• How = Process: Your methods, your habits, your BDD and TDD cycles.

• What = Outcomes: The code, the documentation, the deployed feature.

Most teams work from the outside in. They focus on the What, the deliverables, without examining whether their processes serve the right Why. BDD is one way to force that inward look.

There’s also a feedback loop worth naming. Learning a new Why reshapes your identity. And as your identity evolves, your Whys become clearer. They aren’t separate layers you climb through once; they walk together, constantly rebalancing.

Flip the Story

This is a recurring theme I bring up. The standard user story format is: “As a [user], I want to [action], so that [value].”

The value statement is tacked on at the end. That placement matters more than it seems.

When the business starts with what they want, teams often build exactly that, even when it’s the wrong thing. The value is treated as an afterthought rather than as the foundation.

For nearly twenty years, I joined the group that flipped stories on their head: start with “In order to…” instead.

“In order to [value], as a [persona], I want to [action].”

This small change does two things. First, it exposes what I call “business silence.” If a stakeholder can’t complete that first sentence, the story has no reason to exist. Refusing to build features without a clear purpose saves money and protects focus. Second, it empowers the delivery team. When the goal is stated first, the “I want to” becomes a space for options rather than a prescription. The team can offer multiple paths to the same outcome: faster ones, cheaper ones, architecturally better ones.

Systems Don’t Have Behaviors. People Do.

This one comes up in code reviews more than anywhere else. I see stories written from the system’s perspective: “As a system, I want to…”

Systems don’t want things. Systems exist to serve human needs, which means BDD has to be built on empathy and an honest look at how people actually behave.

Think about why Uber works. It’s not because of its map or its payment processing. It works because someone understood the human anxiety of waiting for a ride you can’t see. Where is it? Is it coming? How much will it cost? Those aren’t technical problems; they’re emotional ones.

Or consider an example I use in workshops: a warehouse worker who doesn’t know what cilantro looks like needs a photo next to the label, not just text. The system that only shows a word is failing a human being.

Most developers focus on the Happy Path. Empathy means designing for other cases, such as the Angry Path, the scenario where a user loses 40 minutes of form data because of a server error. It also means thinking about:

• The Greedy Path: The user who fills out every field and checks every box.

• The Forgetful Path: The user who abandons a cart and needs a gentle nudge to return.

• The Anxious Path: The user who can’t estimate weight in pounds because they grew up in a metric country.

Each of these is a human story. BDD is the practice of writing them down before writing code.

Where UX Meets the Speed of Trust

The most unexpected connection I’ve found is between UX design and Stephen M.R. Covey’s The Speed of Trust.

Covey describes behaviors that build trust between people, such as Talking Straight, Creating Transparency, Confronting Reality, Setting Clear Expectations. When I laid those out, I realized they describe great user experiences almost word for word.

A system that gives honest, specific error messages is Talking Straight. A progress indicator is Creating Transparency. A form that tells you which fields are required before you hit submit is Setting Expectations.

This is what technical expertise starts to look like when it matures into something broader. The patterns show up in more places, not fewer. A well-designed interface and a high-trust conversation are solving the same problem from different angles.

Finding Your Core

Domain-Driven Design gives us a useful concept: the core domain versus the supporting domain. Your core domain is where your business’s real value lives. Everything else supports it.

The same filter applies personally. The “What” of daily work, the emails, the tickets, the pull requests, should be an expression of a deeper “Why.” When those things get misaligned, the work starts to feel hollow even when you’re doing it well.

What I’m learning is that looking around a topic, rather than directly at it, tends to reveal more. BDD led me to communication theory. Communication theory led me to identity and habits. Identity led me to trust. And trust keeps circling back to the human beings on both sides of the screen.

Does your current “What” actually serve your “Why”? That question is worth sitting with.