Skip to main content

Talk to us about Snyk CLI

feature-learn-using-snyk

June 6, 2024

0 mins read

At the end of April 2024, we introduced Semantic Versioning and release channels to Snyk CLI, changes that were well received by our customers. Building on that momentum, we aim to design the CLI so that it not only helps you do your job well but also brings you joy in doing so. We invite you to accompany us on this path to discover together.

In today’s blog post, Neil and I, the design and product duo for Snyk CLI, will share the following three things with you:

  • How our research informs product discovery, development, and impact

  • Where we need your help

  • How you can share your experience and pain points with us 

How did we do qualitative research for Snyk CLI?

The objective that we set for ourselves was twofold:

  • Establish a baseline of pain points that our customers consistently feel

  • Establish a feedback loop that delivers verifiable impact

To establish a baseline of pain points that our customers consistently felt, we interviewed fellow Snykers in customer-facing roles. The reason for this method was to identify recurring signals by gathering wider context quickly. We took inspiration from Stevan Portigal’s Interviewing Users, and iterated through a structured interview script. Throughout the process, we asked for input on our technique and introduced changes. We interviewed 24 fellow Snykers and mapped research synthesis with support and feature request data. 

A recurring signal that emerged fairly soon in the process related to the numerous CLI versions in play, with some of our customers wondering when to upgrade and why. Given the scale at which Snyk operates and the wide range of customers we serve, each customer’s appetite for upgrading Snyk CLI varied. The most pressing question that we were confronted with was, how can we help our customers choose a suitable version to install or upgrade to? 

In this context, suitable may imply any or all of the following:

  • Does this version fix the problem that I have been facing?

  • Does this version contain a new feature that I am interested in?

  • Does this version unlock functionality elsewhere in Snyk?

Over the next few months, we pitched our idea of release channels along with the research cross-functionally. We iterated, over-communicated, and ironed out numerous details along the way, such as introducing a Snyk internal hotfix policy to support our engineering teams. We also gathered input and validation on these changes with some of our customers. Upon introducing Semantic Versioning and release channels, we communicated these changes via a blog and product announcement. Where opportunity arose, we also presented these changes in person to our customers with a desire to share progress and evaluate customer appetite to adopt the said changes. This example helped us establish a feedback loop that not only validated a hypothesis but also validated the outcome. 

Given that we now have a baseline and an established feedback loop, the next step in our user research is to become context-driven, aiming to solve specific problems or problems that we might encounter within a specific developer workflow. This is where we need your help.

How might you help or participate?

Two takeaways from our research were that Snyk CLI delivers the highest impact as a release and security gate. A powerful use case that helps cement our partnership with our customers and users. However, we also noted that the local developer experience needs improvement with regard to reducing friction and delivering a consistent product experience. 

If any of the following describes you, we would love to talk to you:

  • You use Snyk CLI within an integrated workflow 

  • You use Snyk CLI locally to get early feedback and prevent vulnerabilities

  • You use Snyk and are curious about Snyk CLI or our research

Our target audience is those who write code and push code to production. You might describe your role as that of a developer or DevSecOps. We are curious to learn what helps you ship secure code. How might you avoid vulnerabilities from hitting production and catch them as early as possible?

We strive to build exceptional developer experience within Snyk CLI for local developer workflows, helping our users ship secure code. For example, we acknowledge that our command line arguments do not follow a defined naming convention yet. As a result, the experience of using the CLI locally is not frictionless and leads to a higher cognitive load for users. Introducing design guidelines to drive consistent naming conventions could be a step that helps elevate the local developer experience within Snyk CLI. Another step could be to give our users one command to scan their code to find open source dependencies or critical security vulnerabilities. How else might we help you ship secure code?

We hope that this discovery opportunity excites you. Between now and the end of August 2024, you can nominate yourself by emailing us at cli-ux@snyk.io. One of us will be in touch with you for an initial screening call. You can also nudge your technical success manager to share your interest. 

We are curious to learn more about you and your experience with our product.

feature-learn-using-snyk

How to Build a Security Champions Program

Snyk interviewed 20+ security leaders who have successfully and unsuccessfully built security champions programs. Check out this playbook to learn how to run an effective developer-focused security champions program.