Digital Gardenux-methodsdesign-engineering

Escaping Tool Obsession: Why Fundamentals Matter More Than Ever

Explore why design fundamentals matter more than tools. Learn how focusing on methods over software can make you a better designer who solves real problems, not just pushes pixels.

A few days ago, Richard Mills asked on LinkedIn:

"What happens if you take Figma away from your design team?"

The follow-up questions are the interesting part. Without their main tool, can your designers:

  • reframe the business problem?
  • align stakeholders in a workshop?
  • sketch with users instead of polishing pixels?
  • defend why a feature exists?
  • challenge the assumptions behind the roadmap?

If yes, you have designers who think. If not, you have delivery without direction.

It's the same outside design. Take the SUV out of a city commute and life doesn't collapse. Better options show up. We've normalized overkill and forgotten how powerful simple can be.

Fundamentals before tools

The Carpenter's Paradox: rely on power tools long enough and a hand saw feels alien. When the power goes out, does the work stop?

Klaus Krippendorff, in The Semantic Turn, frames design as the making of meaning, not the operation of tools. Don Norman, in The Design of Everyday Things, makes the practical version of the same argument: good design starts from how people think and behave, and the tool bends to that, not the other way around.

The tech version: Azure, Vercel, Adobe and GCP by default, yet who can still spin up a small VPS over SSH? The design version: who can sketch a sitemap or a user flow without a plugin?

Dieter Rams' principle of "less, but better" applies to the toolbox too. Tools should serve clarity, not add complexity.

Don't be the person who can microwave a meal but can't fry an egg.

Why I pick bikes over planes

Bikes and kayaks are human-scale MVPs: understandable, repairable, empowering. You feel the bumps, read the weather and adapt in real time, with no autopilot to dull your senses.

Gear acquisition syndrome vs. getting moving. People buy a €2,000 gravel bike to "finally tour," ride it twice, then stall. I toured 500 km on a €250 folding bike. It was cheap to lock, easy to fix, and good enough to teach me what actually mattered.

John Maeda's law of simplicity says it well: subtract the obvious, add the meaningful. A modest tool used well takes you further than an expensive one you never start with.

My rule of thumb: start small, move early, upgrade when reality demands it. More in my series The Power of Tiny.

The map isn't the territory

Tools are maps. Useful, but not the journey. Tourists follow the route; explorers ask questions, wander and understand. The phrase "the map is not the territory" comes from the philosopher Alfred Korzybski, and it fits design neatly: the tool is not the outcome, and meaning comes from the questions you ask along the way.

Too many teams optimize for speed over insight and end up efficient at the wrong thing.

The gardener's lens

Great gardeners don't start with the fanciest irrigation. They read soil, seasons and signals. Tools amplify judgment; they don't replace it.

Ag-tech shows the same pattern. Farmers say they want "more automation, fewer features" that they can trust. "Shit in, shit out" still applies: without fundamentals, dashboards lie. Recent research backs this up.

When tools become crutches

If every problem turns into a UI screen, you're designing the tool, not the solution. Don't let your stack become a bloated Swiss Army knife with many blades and none sharp.

Itamar Medeiros makes a related point in an article on building thought leadership: designers grow by moving from executing tasks to shaping the "why" before touching the "how."

Wrap-up

Whether I'm fixing a bike, paddling or sketching a flow, I look for methods that give me clarity and ownership.

Give a kid crayons and you get a storybook. Give a pro every tool and they may still stall without a question worth answering.

My best work started in messy conversations, whiteboards and honest field notes, not in Figma.

So avoid chasing shiny tools, churning out endless mockups without feedback, or hiding behind jargon. Start with a real problem, sketch and brainstorm quickly, test early, favor clear flows, and pick tools that speed up learning: pen and paper, v0, a quick Figma prototype.

AI is great. But the only metric that matters is still: did we solve the user's problem?


Want tactics, not vibes? Check out my favorite UX heuristics and methods.


References: