One of the most powerful tools that a UX designer or director can employ is the ability to ask “why?”.

From an agile perspective, it helps to break down user stories to their core requirements, narrow the scope of work, prevent scope creep, and avoid technical debt.

From a feature perspective, it can help to break through a wide range of biases that would otherwise lead to cultural or business-driven UX decisions, and not decisions that are best for your users.

In regards to user testing and feedback, it can help you to truly interpret what the user is asking for (as opposed to taking precisely what they say at face value).

“If I had asked people what they wanted, they would have said faster horses.” — Henry Ford

There are countless applications where asking why can make the difference between mediocre and amazing. Here are a few examples of projects that I’ve worked on where asking why made all the difference.

FINDING YOUR WHY

The popular TED video “Find Your Why” can be applied to a wide range of use cases, from product marketing to mobile app user experiences. In regards to UX, it’s critical to shape the user experience to solve for that why.

For example, let’s say your company makes a smart alarm system. The typical response is “We want to create an app that works with every smart home product on the market”.

Me: “why?”.

Response: “We want to make smart home device management more convenient by bringing everything (typically spread across multiple apps) to one place.”

Me: “Well, that didn’t really answer my question. Convenience is a happy consequence, but the lack of convenience may not be a problem yet. There may also already be companies that have a far more strategic position on the market such as with Apple and Google — both of which have apps just like the one you want to build, and own the actual operating system on the mobile device everyone already uses”.

Response: “Ok, so we want to on-board more users — and we can take advantage of the popularity of other products and competitors to attract them.”

Me: “Still not an answer. An uptick in user acquisition is a consequence of a solid user experience on an app that solves a real problem, backed by both a solid marketing strategy and happy customers”.

Response: “Ok, well, we sell Alarms, so we want to make people more secure.”

Me: “Bingo. So how does integrating with every app in the market actually make people more secure?”

Response: “…[silence].”

Now, we can get to work.

Continuously asking why is an essential tool to help break through bias and overreaching business strategies to simplify user stories, avoid technical debt, reduce scope creep, stick to a product roadmap, and actually build an app that people want.

MINE EDGE CASES FOR OPPORTUNITIES

While edge cases are valid ways that a user might use your app, they typically apply to less than a fraction of 1% of total use cases. They’re often complex scenarios with a lot of conditions that are extremely rare and unlikely to occur frequently. And while edge cases shouldn’t be ignored (especially when there is added risk to the user), they also shouldn’t overly influence and/or compromise the integrity of the overall user experience either.

This is why it’s extremely important to write user journeys, create user flow diagrams, develop user personas, and know your why. Doing so will help you to identify edge cases early-on, review them with your team, and decide if and how you want to modify the user experience to fit.

Using the example in my previous article “Granularity, the Great UX Debate”, applying the “asking why” method helped to expose major issues and flaws in the logic that would have otherwise put the company and its users at risk. It also lead to the discovery of a much simpler solution without compromising security for everyone else.

Here’s the narrative:

Goal: “We want the admin to be able to choose each permission for every user they bring into the system.”

Me: “Why?”

Response: “All of the other companies in the market use roles to enforce rules, and we want to innovate by empowering users to have as much control as they want.”

Me: “Ok, but why?”

Response: “Well, what if I had a child who is old enough to have a phone, who is interested in smart home products and has a science fair project coming up in a few weeks. In preparation for the science fair project, I bought him Smart Home Product X. I’d want him to be able to connect that product to my account (because science), but not do things like be able to turn off the alarm when he’s not at home.”

Me: ”This is a Smart Alarm system. Why would you potentially compromise your home’s security by allowing your child to casually connect a non-security related product to a product created specifically for security? This isn’t Philips Hue, and the use case isn’t magically changing the color of the lights before we watch the newest episode of Game of Thrones.”

And that’s when it came to me…

Instead of exposing permissions, creating more roles, and allowing users to defy roles later on by going back and changing permissions at the user level (which could potentially compromise the level of security for all users), what about “Parental Controls”? Parental controls would allow us to maintain the integrity of the system with fewer roles. It would give parents the ability to use an entire different set of “rules” to override rules that, by default, keep our users safe and protect them from themselves. Parental Controls, as a feature, is a much tidier solution that allows us to utilize a simple toggle switch somewhere in the settings.

Always resist letting edge cases overly influence and shape the primary user experience. Sometimes you’ll find that by asking why, that you can mine opportunities for new features that might just make your app better.

MINE COMPETITOR STRATEGIES FOR OPPORTUNITIES

Sometimes during the research stage you may come across something that seems unusual or counterintuitive. Instead of outright claiming “well, I’d do it differently” and changing it to what you think is better, ask yourself “why would they make that decision in the first place?”. Never presume that your “creative intuition” is superior to the hard work and man-hours put in by your competitors. If the company you’re researching is a legitimate player in your market, you can rest assured that this wasn’t an oversight. It was a deliberate decision that was based on user testing, user feedback, and likely months or years of analytics that likely revealed pain points and friction.

For example, on a recent client project we discovered an app who had a feature we were looking to adopt for our users; giving the user the ability to upload a photo during account creation. In the app we researched, once the user uploaded and cropped their photo, the call to action changed from “Upload Photo” to “Looking Good!”.

Someone on the team called out “so, how do I change my photo if I don’t like the one I picked?”. Feeding off of that question, another member called out “exactly, I have to take 100 pictures just to get the right one”.

In this case, we could have opted to move forward by changing “Looking Good” to “Remove Photo”, and moved onto the next task. However, asking “why would the company do that” lead to the discovery that during the steps where you choose and crop your photo, the user had plenty of time to change their photo and preview it before moving forward. After further investigation, we also made the discovery that “Looking Good” was a form of positive reinforcement that likely resulted in an increase in sign up completions and reduced the likelihood of a user getting hung up on taking the right photo.

Competitor research and feature benchmarking are critical parts of the UX design process. There are always going to be people who throw out ideas that, if not put in check, can quickly snowball into a “group consensus” and lead to a poor user experience. And while it’s good to incorporate the feedback of your peers and stakeholders, asking “why” will help you to stay the course to a stellar user experience.

MINE CUSTOMER FEEDBACK FOR OPPORTUNITIES

One of my previous clients was a company that made learning software. The admin could use the tool to create courses, added course content, group related courses together as “Curriculums”, and could set due dates for completing the course itself.

One of our customers requested that we add a checklist feature that allows admins to include non-course material and course material together, in a checklist.

Since it was a small startup company, the CEO (whom I worked directly with) asked me to design a new feature where clients could click “New Checklist”, add items to the checklist, save it, and share it. They could add in external links to new employee on-boarding forms, embed rich media, include course content, and more.

If I had taken the customer’s feedback and the CEO’s interpretation at face value, we would have developed an entirely new content type for links to external content, new features that would allow for embedding rich media content, and an entirely new primary experience that would compete with the one we already had for course content. To make matters worse, the developers gave an estimate of approximately 3 months to build that feature — something that would have cost the company over $60,000 to complete.

Instead, I brought that information back to my team where we used the “ask why” technique to break down the project into basic requirements.

What we discovered was amazing!

First, as a learning platform, we already had a grouping construct called “Curriculums”. We already had a content type called “Courses”. Courses already supported links, images, video, and other content. We also already had a feature that allows admins to add due dates. The only thing we were truly missing was a new content type and a cleaner UI. So in the end, the client was really asking for a more intuitive user experience using mostly existing features (improvements to the UI and content hierarchy to make it look and function more like a checklist), and a new content content type (basically, just a stripped down course). The resulting change utilized a lot of existing code and took 3 weeks instead of 3 months to create. Not only was it a huge success that met the client’s expectations, it also saved the company almost $50,000 in development time.

LEAD WITH PURPOSE, NOT WHAT YOU WANT THE USER TO DO

Credit: Getty Images

On a recent project, the client was asking for a revision of their sign-in page (the default page that you’re taken to after downloading the app). On the previous version, they had a fairly traditional layout: email, password, forgot password, login, and sign up.

After taking the request back to my team, we used the “asking why” technique to analyze this part of the user journey. First, who are our users? We discovered we had three basic user types — people who already had accounts, people who bought a smart alarm and needed to create an account, and people who received an invite.

Next, we asked “Why did they download our app, and what are they trying to do?” The person who had no account was most likely to have bought a product, and wanted to get it connected. In this case, creating an account was a consequence of getting a device connected.

The person who was invited simply wanted to accept the invite in order to start using devices. In this case, creating an account was a consequence of accepting an invite.

And for users that already had an account, “Sign In” worked perfectly.

At this point, we had “Connect a Device, Accept Invite, and Sign In”.

Prior to pitching the idea, we did some competitor research to see if anyone else was tackling this issue. Right away we found an app that had “Connect First Device, I Received an Invite, and Sign In”. Perfect!

However, after I pitched this to one of our stakeholders, “Connect First Device” was shot down because “Connecting a device should happen after we capture the user’s details. After all, we’re a business and the company needs signups.” So, despite the fact that the “Connect First Device” flow included account sign-up, we went into user testing with “Create Account” instead.

Several of the users, when prompted with “You just received an invite”, instinctively (yet, mistakenly) clicked “Create Account” and were confronted with various checkpoints in the user flow that were distinctly not for them. They became confused, frustrated, and often had to click back to the beginning to make sure they had not made a mistake. Only after correcting users did they realize they should have clicked “I Received an Invite”. Shortly thereafter, we made the change to “Connect First Device.” After applying the change, future testing participants were 100% successful at clicking the right option pertaining to their intent.

This is just one of many cases where the business interest took priority over the user experience, and a great example of why it’s critical to use “why” to create a better user experience. Had we taken this to market without user testing, we could have potentially created a major point of friction for users that would ultimately lead to a high abandonment rate.

SUMMARY

Always know who your audience is and what they are there to do. Use natural language to explain what’s going on, and speak to their intent — not what you want them to do. Do your research, pitch your case, and if you still fail — at least you have user testing to settle the score. But whatever you do, asking “Why?” is the single most powerful tool a UX designer or director has for crafting stellar user experiences.

Michael Sim

Website | LinkedIn | Twitter | Behance