Why I Ask Why And You Should Too

I have a two year old, that has begun the process of asking "Why?"; ie. "Why can't I put this in my mouth?" "Why do I have to get down from this chair?" "Why can't I use the knife?" These questions usually go with another new statement of hers - "No, I want to do it." The questions are simple, and as an adult, seem fairly easy to answer (given the fact that most of the time it's because I want to keep her safe). But having her ask, made me realize as we grow older, we stop asking 'why' at some point. Probably because we know the answer, but maybe, it's also because we feel we should know. Or maybe it's that urge to want to do it on our own, to want to figure it out without help (that stubborn statement she too is more vocal about). As designer, and as a request to other designers (and developers), I urge you to get back to that simple question, ‘why?'; it's one we should all ask before starting anything.

Knowing your why (The TedX talk)

Simon Sinek became famous for his TedX talk on leaders that inspire action by starting their journeys, speeches, sales pitches by answering why. He delivered this talk over six years ago, and yet it’s still relevant and accurate (could be why it's had over 20 million views). If you haven’t seen it yet, stop reading this, watch it, and come back. If you have, watch it again, it's always good as a refresher. His talk, which we’ve embraced here as a team (watch Why Planet Argon), is geared towards inspiring behavior in others. But this notion can also be applied to inspiring design solutions (ones that will hopefully inspire action from its users).

Knowing your why as a designer

Our team’s focus is to simplify lives through digital technology. As a designer, I design to solve a problem. So when clients/prospective clients walk through the door with “We need this” or “Our users need this”, it’s imperative in my role to first ask, "Why?"

It’s a simple question that I even forget about sometimes. How can I forget, you ask? I too can sometimes get wrapped up in the conversation of grand visions and commiserate over assumed issues. It's easy to be convinced of solutions when 'everyone' has already bought into it (my work is done, right?). Like: ‘Wouldn’t it be great if [insert feature]’ or ‘ I bet they are struggling with this [insert assumption].’

However, without stopping to ask “Why would that be great?” or “Why are they struggling with that” I don’t really have solid footing to design a solution. Later, if I still haven’t asked the question, I synthesize the conversations we had into thoughts and ideas, and quickly realize, I don’t really know why I’m thinking about them. Even worse, I don’t really know what problem it solves, other than it can bring to fruition the grand ideas we all thought up together in our isolated group. That is actually the worst scenario to be in, and one I have been in before. Ideas without a purpose. Ideas without a why to understand how they got there.

What do you do?

Rewind back to the clients that come through the door with “we need this." Back to that simple question. What do you do? You stop. You talk about why. Why do you need this? Why does this align with your company’s mission or vision? Why do your users feel that? Why are we here today? Why do you think we can help? Why is this something that your company wants to do? Ask why until the entire picture is clear, not just the goal at the end.

So...why ask why?

By asking why, you get real answers and issues, issues faced by the company or by their users. And those are the issues you focus on to solve, those are the issues that if solved, will simplify lives. Focusing on the root means you’re not looking at it from the goal down and trying to tie up all the loose ends. By looking from the root up, you can mitigate the tunnel vision that ensues when you try and determine how a goal might solve a problem. Doing that might limit the design’s full potential. Instead you can focus on the best solution; which may or may not be the original request. And this is just the beginning. The why’s can continue to conversations with stakeholders, users, prospective users. And continue through design strategy into testing.

And a word of advice. Never settle for answers or requests like “I don’t like how this works” or “this is much better” or “can this be this way." Ask them to tell you why. And just like we did as toddlers, if the answer is “because we do”, ask "but why?" again.