"Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it."

Bruce Lee wasn't talking about design processes when he said this.
But he might as well have been.

One of the first questions I’m asked when joining a new team is:
“What’s your design process?”

It’s meant with good intent—usually to understand how I work or how I might bring structure. But it’s the wrong question. Or at least, it’s incomplete.

Because the truth is: there is no one design process.
Not really.

There are frameworks, patterns, rituals, and phases that show up across mature orgs. But if you’re asking me to drop in and run a perfect double diamond or a clean five-day sprint, you’re assuming the team, the product, and the company are all shaped to accommodate it.

They usually aren’t.

And that’s fine.

Bruce Lee understood this. He didn’t create a rigid martial art—he created a philosophy that could adapt to any situation, any opponent, any constraint. The art of fighting without fighting.

I think of it as the art of processing without process worship.

“Empty Your Mind. Be Formless, Shapeless—Like Water.”

Process fails when it’s rigid.

I’ve seen beautifully diagrammed workflows fall apart in the real world:
Because the researcher was overloaded.
Because engineering was shipping weekly and couldn’t wait.
Because the PM had already committed to a roadmap.
Because the product was on fire and discovery wasn’t the priority.

Process breaks when it demands compliance instead of enabling collaboration.

A rigid process is often just a design leader trying to prove they’ve done the reading. But good teams don’t need a design textbook dropped on them. They need a process that meets them where they are.

Water doesn’t resist the shape of its container—it becomes the container. It moves with what’s in front of it. It adapts while staying true to its nature.

So the better question is:
What kind of process will actually help this team move forward?

“Absorb What Is Useful, Reject What Is Useless.”

If you want a process that works, start with what’s real.
These are the variables I look at before proposing anything:

• Team Size & Composition
  A solo designer can’t work like a five-person team with dedicated research and writing.

• Stage of the Product
  A 0→1 product needs exploration and bets. A scaling product needs optimization and clarity. A legacy product needs maintenance and forgiveness.

• Org Culture
  Is this a top-down, engineering-led org? Or does design have a seat at the table? What’s rewarded—speed or rigor?

• Cross-Functional Maturity
  Do PMs want to co-create or just receive wireframes? Do engineers care about UX or just ticket throughput?

• Time & Resources
  Do we actually have time for research? Access to customers? The ability to ship experiments?

These factors shape not only what’s possible—but what’s useful.

Bruce Lee studied every martial art he could find. He kept what made him faster, sharper, more effective. Wing Chun gave him close-range speed. Boxing gave him footwork. Fencing gave him timing. Everything else? Left behind.

The same applies to design process.
Take the research methods that match your timelines.
Use the documentation people actually read.
Keep the rituals that build trust.
Lose the rest.

“Adapt Like Water. Strike Like Lightning.”

Some examples from teams I’ve worked with:

• Early-stage startup with no research support
  I ran short interviews with internal teammates who used competing tools. Not perfect, but directional. We shipped based on patterns and adjusted post-launch.

• Enterprise product with heavy stakeholder involvement
  We mapped design deliverables to decision gates. Every review had rationale slides. The process was really stakeholder management in disguise.

• Distributed team with async schedules
  Every concept had a Loom walkthrough. Figma was annotated. Research plans lived in Notion with prompts for async feedback. Meetings were the last resort.

Each of these worked because they were tailored—not in spite of it.

Water takes the shape of whatever holds it, but it’s still water—whether it’s in a glass, a pipe, or a stormcloud.

Your process should be the same.
The core principles don’t change:
Understand users. Solve real problems. Collaborate early. Iterate often.
But the tools, timelines, and touchpoints? Those should bend to your context.

“The Art of Fighting Without Fighting.”

You don’t need a grand overhaul. You just need to be thoughtful.
Here’s how I usually approach it:

• Start with what’s already working
  Don’t reinvent—observe. Where’s the team already getting value? Where’s the friction? Like Bruce Lee studying an opponent before engaging.

• Design for the gaps, not the ideals
  Instead of building an end-to-end process, look for the missing pieces:
  Are we skipping research? Failing to test? Losing clarity in handoff?

• Co-design with your peers
  Ask PMs and engineers what they need to feel confident. The best process is one people want to use. Bruce didn’t just fight alone—he taught others to adapt his ideas to their strengths.

• Prototype it, don’t preach it
  Introduce one small change. A kickoff doc. An async critique. See what happens, get feedback, adjust.

• Stay flexible
  What works today might not work in six months. That’s not failure—that’s growth. Even water changes state when conditions change.

“The Highest Technique Is to Have No Technique.”

Design process isn’t a badge. It’s not proof of thoughtfulness.
It’s a tool—meant to help people work better together.

The goal isn’t to follow the process.
The goal is to move the work forward with clarity and care.

And the best process?
It’s the one that fits the team you actually have—not the one you read about.

Bruce Lee’s martial art wasn’t about form. It was about function—about responding to what was real, not what was expected.

Your design process should be the same.
Formless, but not aimless.
Adaptive, but not directionless.

Be like water. Find the way through.