Welcome to Step One of our series on how to kickstart user testing of your security product.

We’ve written in the past about how user testing is one of the most powerful tools to building a product customers will actually buy. So we created a step-by-step guide to kickstart the process.

Start with your riskiest assumption

When kicking off your first round of user testing, it's important to start by identifying your riskiest assumption about your product. This is the thing that, if you get it wrong, could really hurt your product's chances of success.

Ask yourself:

  1. What problem is our product trying to solve for users? What do we assume is their biggest pain point?
  2. What functionality or workflow do we assume will be most important to solving that problem?
  3. What elements of the design or user experience do we assume are critical to get right?

Consider what you want to learn

Once you've identified your riskiest assumptions, consider what you are wanting to learn from the testing session. Are you looking to improve usability, identify bugs, enhance specific workflows, or validate new features?

Example

If your product is a new cloud-based security dashboard, your biggest assumption might be that IT managers will find the dashboard intuitive and can quickly drill down to investigate security events. Make sure your test includes having real IT managers try to use the dashboard to complete realistic security-related tasks and observe where they get stuck or confused.

Prioritize Features and Workflows

In addition to testing your biggest assumptions, it's also helpful to prioritize testing your core features and workflows. Make a list of all the major features and key workflows in your product, then narrow it down to the 2-3 features that are most critical to the user experience.

Example

Continuing with the example that your product is a new cloud-based security dashboard, the core functionality of the dashboard is to monitor and investigate security threats and events. 

So the main workflows would likely involve:

  • Getting an overview of current threats and security alerts
  • Drilling down into details of specific alerts
  • Conducting searches to investigate threats
  • Creating reports/exports for further analysis

In one set of testing session, you might narrow your focus to only validating 

  • Getting an overview of current threats and security alerts
  • Drilling down into details of specific alerts

Warning: Be cautious about overloading a single test session with too many features. Focus on your riskiest assumptions first.

In later testing sessions you can validate a few other features like: conducting searches to investigate threats, and creating reports/exports for further analysis.

Get stakeholders to guess what they’ll learn from the testing sessions

Finally, get input from stakeholders across your company on what they hope to learn from user testing sessions. This will help uncover assumptions and knowledge gaps across teams like product, design, and engineering.

We learned this approach from the GOAT, Jared Spool. He stressed the importance of gathering stakeholder perspectives before testing. This informs what you test, while still keeping the sessions focused on your core assumptions and user tasks.

It shows them firsthand how this research allows the team to make better-informed decisions, rather than relying on assumptions or guesswork.

It all comes down to this

The bottom line is: your users understand their problems better than anyone. But you have to ask the right questions in your testing sessions to get insights that will help design the right solutions. Focusing on your riskiest assumptions first is the key to kickstarting productive user research.

If you need help, ask us anything at hello@sodiumhalogen.com

Your bottom-line called and wants to know how
our Designtific Method can help.

Tell us about your project