Trust, but verify.

Looking back at my product development career, I’m reminded of a quote from one of my favorite crime TV shows, CSI Miami. Horatio Caine, known for his one-liners and wicked cool sunglasses, delivers a repeating phrase throughout the show to encourage his team to dig deeper and not take any information at face value. It’s a simple quote, but one that still sticks with me today. He says:

“Trust, but verify. “

This is the best lesson I’ve learned as a product designer and here’s why…

At the heart of this quote is the idea that an assumption alone is not powerful enough to prove a case. Instead, it must be investigated, researched, and verified for it to justifyingly hold any merit. As a product designer, this makes my heart sing because nothing is more defeating than ideating a feature that falls short for a user when the information you had at the start wasn’t the complete picture.

Not all assumptions are bad ones, but why leave it to chance? Which of the following statements feels more powerful to you:

• Saying “we hear that most users want XYZ”.

• Saying that in the last 30 days, 80% of users that have joined our experience leveraged tools that support an XYZ use case. We’ve heard from many users that this is the most desired path, and here’s our evidence to support the building of that feature.

One feels measurable, the other doesn’t. What’s the difference? A little research to validate and inform overall direction.

So, then what?

This is where UX Research comes into play and, in my humble opinion, this is the most critical stage of any design exercise because it sets the tone and precedence of the overall design direction. This information helps a designer build empathy, harden perspectives, and understand the core truths surrounding the proposed feature. This is also the stage that helps designers dispel any personal biases that may inadvertently been injected into our line of sight.

Before jumping into any feature, I begin by asking questions to better understand how I can define the users problems and their needs/motivations. From there, I begin diving into raw data and user recordings/interviews to better understand how the defined problem fits within the scope of what the data can tell me. Has the problem I’ve been presented with been factually confirmed by the actual user datapoints?

The balance of qualitative and quantitative datapoints.

I believe that concrete user research must contain a balance of these two types of data points because without both, it’s impossible to paint a complete narrative behind user behavior. For example: only looking at raw data can tell you whether or not an action took place— but it can’t tell you why. The quantitative datapoint that tells you if an action took place is still immensely valuable because it defines the starting point, the measurement you can use to identify if you’ve moved the needle in the right way with the feature you’ll be developing.

Qualitative datapoints, on the other hand, can tell you a lot just by observing users. Did the user miss the primary CTA on the page because they were distracted by something else? If so, what was it? What actions did they take immediately after missing the initial desired behavior? Could this information lead to a new understanding of a use case? What I love most about qualitative information is that it provides deep context into user behavior and interaction and it gives us an anonymous perspective into their experience so that we can see first-hand their successes and, more importantly, the invisible frictions that ultimately build up and cause user abandonment.

As a designer, this process is absolutely critical to the work I do to ensure that the features I build have long-lasting positive impacts on both the users and the business objectives. Don’t take information you receive simply at face value— trust the source, but verify it yourself to ensure you have the whole picture.

Go forth and be cool. 🤙🏻