Clearing the Path
to First Findings
Meeting AppSec Teams Where They Are
Built a new onboarding experience for StackHawk, giving AppSec teams a clear path to their first security findings.
Phase 1 shipped · Phase 2 in progress
Client
StackHawk
Category
Product Design
Team
Cross-functional
Duration
January to March 2026 (Phase 1)
A drop
in trial-to-paid conversion prompted the initiative
Nearly half
of trial users ran a profile scan in week one
Nearly doubled
app creation rate after new flow launched
I led design for StackHawk's Q1 2026 headline initiative. I sat in on every customer call, tracked sessions in Sentry, iterated directly in code with engineers, and took feedback straight to the team.
AppSec teams could finally run scans and see real findings in minutes without needing YAML expertise or Docker installed. The flow removed the technical barriers that had been blocking teams from ever seeing value. Our product was powerful but required too much technical setup to demonstrate that during a POV. This initiative changed that.
The Problem
AppSec teams evaluating StackHawk were struggling to get started. The product was powerful, but the path to seeing that was too long and too technical.
Other tools in the space let users enter a URL and see results immediately. We had built a hosted scanner with similar capabilities, but it wasn't part of our main flow into the product.
The core issue was that our POV process required downloading our scanner, understanding how it works, configuring YAML, and setting up authentication. Authentication alone was a huge barrier. For our target users, it was a non-starter.
The goal was for every customer to shift left and scan in their CI/CD pipelines. But to get there, they needed to believe the product worked first. I believed a simpler onboarding process could be the bridge, proving value fast so teams would invest in deeper integration.
The old onboarding experience from a trial user’s perspective
Problem Statement
AppSec analysts and engineers need an easy way to onboard with StackHawk and then scale their security program from there. They may not have the technical knowledge to configure YAML, set up Docker, or navigate CI/CD pipelines. They need to run scans and see results without getting stuck.
Target Users
I designed this flow for AppSec Analysts evaluating security tools. These are the people increasingly responsible for championing and selecting tools, but they lack the technical depth to configure scanners themselves.
From our Solutions Architects who run POVs daily, I kept hearing the same things. Users can't get the scanner working without pulling in an engineer. POVs fade out because setup complexity blocks value demonstration. Teams want simple endpoint-based DAST where they can enter a URL and get findings. Users are reluctant to start with API Discovery because there's no immediate value.
Persona: AppSec Analyst
Role
AppSec Analyst
Context
Owns the AppSec program. Evaluating security tools for their team, often championing and selecting the tooling. Responsible for scaling security coverage over time.
Goals
Get started fast, run scans, see findings, triage results, prove the tool works to stakeholders, then scale their security program from there.
Frustrations
Can't get scanners working without pulling in an engineer. Doesn't know YAML, Docker, or CI/CD. POVs stall because setup is too complex.
What they need
Enter a URL and get results. Simple, obvious, no technical prerequisites.
The Process
I needed to meet users where they are. Not where we wanted them to be, not where our product assumed they'd start.
The POV goal was simple. Show them StackHawk works and that it's easy to onboard. That builds trust. Once they believe in the product, we can show them how to scale their security program, shift left, automate in CI/CD, and discover their attack surface. But that comes later. For now, the POV needs to prove they can get started and that StackHawk meets their business goals.
User journey map for the new onboarding flow · Click to enlarge
Getting Oriented
Leadership tasked me with this initiative. Our Head of Product had written background docs outlining the problem and opportunity. I took those docs, combined them with everything I knew from working on the product, and used Claude Code to build my own documentation, form a problem statement, and start problem solving.
From there, I journey mapped the experience several times to fully understand what the user would be doing at each step, and what our platform would need to do in return and in the background. The journey changed as I learned what restrictions engineering had and as I incorporated feedback from the team.
First Prototype and Leadership Feedback
I presented my first prototype to leadership and our new board member in person. The feedback shaped everything that came next. They wanted more positive reinforcement, celebrating what the platform just did for the user. More opinionated actions, showing the next step instead of presenting options. Make it obvious so users don't have to figure out what to do.
This was a fundamental shift in how we guide users through the product. That feedback pushed me to build on what I'd started. The Applications and Oversight screens evolved from presenting data to being deliberate about what comes next, what to fix first, and providing one clear path forward.
Coordinating Four Workstreams
This initiative touched four engineering workstreams at once, spanning automated authentication capture, cloud deployment improvements, signup flow changes, and our domain guesser service.
My role was building screens quickly to unblock engineering, ensuring visual and interaction consistency across workstreams, and maintaining the north star user experience while each team executed their piece.
Keeping the Team Grounded
Our product is deeply technical. Our engineers think like engineers, which is exactly what you want when building a security scanner. But we were designing for AppSec Analysts, not engineers.
When discussions drifted toward technical possibilities, I'd ask whether an AppSec Analyst who can't get Docker working would know what to do with what we were proposing. The engineering ideas weren't wrong. But clever and powerful isn't what this user needs. They need simple and obvious.
Finding the Essential Flow
The early versions tried to do too much. I had domain enumeration surfacing hundreds of subdomains, multiple configuration paths, and decision screens asking users to choose what to scan before they understood what they were choosing. I was trying to surface everything the platform could do, and it was overwhelming.
I started cutting. I removed the subdomain list, the path selection screen, upfront configuration, and domain enumeration as a visible step. Each cut was hard because the features were real. But an AppSec Analyst evaluating the product doesn't need to see everything we can do. They need to see that it works.
By V8, the flow looked similar to V1 in its simplicity, but with one critical difference: the platform does the work automatically. Advanced capabilities still needed to be surfaced, but the first experience needed to be simple. That meant choosing what not to show.
Key Decisions
Profile Scan as a Live Modal
After the user enters their domain, a modal shows discovery progress in real time. Instead of a loading spinner, each step checks off as results come in. App type, path count, API spec detection, testability score, whether authentication is needed.
Users watch items resolve one by one, building confidence that the platform is working for them. When the scan completes, they see final results and can configure further by adding authentication or a spec. This sets expectations before they land on the App screen.
From Optimize Scan to Run Scan
Originally, Optimize Scan was the only prominent call to action on the App screen. The idea was that configuration (adding authentication, adding a spec) unlocks better scan results, so the UX should guide users there first. Running a scan without optimizing was possible but de-emphasized.
The data told a different story. Users were clicking Optimize Scan, landing in the scan configuration panel, and then closing out without running a scan or filling out the forms. The configuration step we designed as a guide was actually becoming a barrier.
I kept the Optimize Scan path available but changed the primary action to Run Scan. I just wanted users to run something, even without any configuration. A base scan with shallow results is still a step in the right direction. It shows the product working, builds confidence, and gives users a reason to come back and configure for deeper coverage.
Configuration as an Unlock
After the first scan, users land in App Details. This is where configuration happens, but only after they've seen value. Add authentication to scan protected paths, add an API spec for better coverage, run again to see more findings. Configuration becomes the way to get more out of the product, not a gate blocking any value.
I streamlined the configuration experience to match. Visual form as the default, not YAML. Advanced YAML still available for power users, but de-emphasized. For the first pass, the visual form gave AppSec Analysts a straightforward way to configure authentication without needing to know headers.
What Customers Showed Us
Once the new flow was live, I started demoing it on customer calls alongside our Solutions Architects. The reactions told us something we hadn't expected. The cloud deployment flow was solid, but what got people excited were two features we'd built to support it: a tool that records and replays authentication automatically, and the form-based configuration panel.
The automated auth capture landed the hardest. One customer called it "the dream." Customers saw it speeding up their AppSec program rollout because configuration was created for them, not by them. They also saw it getting developers to actually test more, since the barrier to adding authentication was gone. The form-based config panel got its own reaction. Our Solutions Architect wanted it in the mainstream product, not just the onboarding flow.
The insight was clear, features beyond cloud deployment could help customers onboard and reach their goals, regardless of their role. We were taking tasks that were complicated or felt like toil and doing them for users. That principle applied to AppSec Analysts running their first scan and to engineers adding their tenth application.
Key Insight
Automated auth capture and form-based configuration weren't just onboarding features. Customers wanted them everywhere. They made scans easier to set up, security programs faster to roll out, and time to first scan shorter.
Evolving the Flow
Based on what customers and our SA validated, I proposed bringing the form-based config panel into the product's Add an App flow. If it simplified configuration during onboarding, it could simplify it everywhere. The excitement confirmed this wasn't a nice-to-have, it was something every user wanted.
I redesigned the "Add an App" experience as a simplified slideout with the form-based configuration panel embedded directly. Users could add a domain, configure authentication through the visual form, and add an API spec, all in one streamlined step. With hosted configuration handling the complexity, local testing collapsed to just running the command we provided. We're actively working on bringing automated authentication capture into this flow next.
The goal didn't change. We still wanted to help users onboard faster and see value. But the solution expanded based on what customers showed us. What started as a cloud deployment initiative became a broader rethinking of how users configure and interact with the platform.
Results
The new onboarding flow shipped in late February 2026. In the first week, nearly half of trial users ran a profile scan, the core action that drives the rest of the experience. Profile scans are new to this flow, so there's no direct baseline. We're tracking against trial cohorts that didn't have the new flow to measure trial-to-paid conversion impact.
App creation nearly doubled after the new flow launched. It's an early signal, not a conclusion. But seeing nearly half of new trial users complete the primary action in week one suggests the flow is doing what it was designed to do, getting people to value fast.
Scanning rates haven't increased yet though. We think the scan configuration step, which includes form-based authentication and API spec fields, is either intimidating for trial users who aren't in a guided demo, or users don't realize they can run a base scan without filling anything out.
To bridge that gap, we're running an experiment. We added Run Scan buttons in the application table and scan table, making the action visible where users already are. For users who close the scan configuration slideout without running, a modal lets them know they can run a scan now or add authentication and a spec first.
The data showed us where the drop-off is. Now we're testing interventions and continuing to iterate.
Learnings
Talking to customers changed the scope. What started as an onboarding initiative evolved into features that helped our entire user base. Demoing the new flow on customer calls showed us that the things we'd built to simplify onboarding, like form-based configuration and automated auth capture, were things every user wanted. That was the biggest learning from shipping this.
It took eight iterations to find the essential flow. The early versions tried to surface everything the platform could do. It took cutting domain enumeration, decision screens, and upfront configuration to find the version that actually worked for our users.
A POV has one job. Prove the product works and that the user can get started. I kept adding features that were impressive but irrelevant to that goal. Every time I cut something, the flow got better.
Configuration is an unlock, not a gate. Our bet is that letting users see value before asking them to configure anything changes how they move through the product. If they've already seen findings, configuration feels like a next step instead of a barrier.
Next Steps
With Phase 1 shipped and customer feedback shaping what comes next, the project has continued momentum.
- Scanning experiment. Data showed app creation nearly doubled but scanning didn't follow. We're testing targeted interventions, including Run Scan buttons in key surfaces and a modal for users who close scan config, to bridge the gap between creating an app and running a first scan.
- Connecting subdomain enumeration with API Discovery. These two features are similar and intertwined. Subdomain enumeration discovers your attack surface from DNS and TLS. API Discovery finds it from your source code. We needed to figure out how these worked together and where each fit in the user journey.
- Path from cloud deployment to shifting left. Once a user ran their first cloud deployment and saw value, how would we guide them toward Discovery or scanning in their CI/CD? The goal was to meet them where they were, then help them mature their security program when they were ready.
- Redesigned add an application flow. Replaced the setup wizard with a simplified slideout that embeds the form-based configuration panel directly. Users add a domain, configure authentication, and add an API spec in one streamlined step. This shipped and brought the same simplicity from onboarding into the core product.
- Automated auth capture. Actively working on bringing automated authentication capture into the product for adding applications. Customer reactions validated that automated configuration isn't just an onboarding feature, it's the way users want to set up scans across the platform.