The why

I figure it was during summer (winter for those of us who grew up in Ecuador), the hot season, when my father called us into the living room to explain how a car’s clutch works. Our fascination — my two older sisters’ and mine — probably came from having taken one more step toward the crazy idea of driving the family car on our own. Apparently, in my father’s mind, the most important thing for us to take on responsibility was understanding how an engine works; the other dangers of letting kids aged 13, 15, and 17 behind the wheel didn’t seem to matter much… Oh well! Different times.

The thing is, with the cheerfulness that defines my father, he told us — with drawings and theoretical explanations — how a combustion engine works and, above all, how the gear shift works so we wouldn’t wreck the clutch.

I start my reflection this way to validate my beliefs — I’d say it’s a textbook case of confirmation bias. I’m convinced that first you need to understand the why, the context, and then land on the practice. And this, which seems obvious, gets skipped more often than we’d imagine.

Bringing this exercise to design, in the current landscape full of automatisms — call them Artificial Intelligence, solution catalogues with “best practices,” frameworks, or standardized design systems — I get the feeling there’s a real risk of not understanding the why behind things, processes, and the roadmaps a product or solution is pursuing.

Losing depth in that initial reflection exposes us to conceptual definition risks that are hard to correct. It’s important to understand challenges from the root; this exercise often forces you to unlearn, to fight your biases, and to squeeze your brain a bit to formulate hypotheses that actually add value to the design.

Tools

• Design thinking: Or rather, reflection through 3 easy-to-approach methods that work well for getting a good “snapshot”:

• Business Model Canvas: Yes, it’s old school, and there are surely newer and more effective approaches, but using this tool lets you understand much of the context very simply.

• Interviews: Interviews, interviews, and more interviews.

• Personas: The key is understanding that the goal isn’t filling out an endless report. It’s a real reflection, based on data — collected analytically — and deeply understood. This video is worth watching to go deeper on this topic:

Attitudes

• Interest in the “language”: I’ll be direct: show interest in understanding the technological environment where the project lives. It’s common for development teams not to speak your language. It’s like traveling to another country — if you make the effort to learn their language or jargon, they’ll welcome you better. You decide whether to just “get by” or become an expert.

• Open your mind to learning: You’ll do better if you take on your expert role with humility, recognizing that your client — or any stakeholder — knows a lot about the product, service, or project you have in your hands. No, you don’t know everything. You’re probably good at thinking laterally, but there are always biases and perspectives you need to identify and manage. What’s truly valuable is your ability to make information flow, allowing the team to reach the best solution.

At Elastic we don’t have a universal recipe or a “method” applicable to everything; we have artifacts — key tools and prototypes — and we have an attitude. The key is to drive with order the obsession with understanding the why.