Stackhackr
Stackhackr is:
An online malware simulation tool to test your endpoint security.
What I’m proud of:
The design process implemented and seeing its impact on the final result. The initial brainstorm involved stakeholders across the entire company. We were able to use daily user tests to iterate within a short timeline. The team put in extra effort on the details of the vectors and payloads. As a result, we were able to reduce the risk of the shipped product and have a successful launch.
The project:
Context
For a reference, here’s a preview of the entire screen flow. The app has two main parts. First is the web app where you customize the payload and download it via the vector. The second happens once you run the downloaded file on your machine.
Problem
As a company, we had prior success generating leads from online tools with our ransomware decryptor. Co-workers also had success at past companies with similar tools (HubSpot’s website grader). The focus for the team was answering “can we build a free online tool to sustainably generate leads?”
Brainstorm
We kicked off the project with a brainstorming session. A variety of stakeholders attended, including designers, marketers, engineers, and company leaders. Each round consisted of sketching (to diverge), followed by a discussion (to converge). We settled on ideas that covered testing your current security stack. It’s a question IT professionals are continuously asking themselves and would allow us to re-market the tool with each iteration. After a few rounds, we decided on two ideas for the design team to stress test
(tower defense
not being one of them). Next, I converted the team’s whiteboard sketches into a wireframe prototype.
User testing
We scheduled user interviews for a two week period. The schedule alternated between a day full of interviews and a day with none. This allowed us to test with 2-3 users and then implement feedback before the next day of interviews. It only took those few users to identify the largest opportunity for improvements each day. For example, adjusting the tone of content was low-design effort, but had a huge impact. Any feedback that was larger in scope, we addressed during development.
The evolution of the ‘Build’ screen is a great example of the benefits of this process. It begun as a multi-step builder forcing users to customize the payload. We learned users wanted to see both the vector and payload in one view. Additionally, some users wanted a direct route to the test. We implemented pre-selected defaults and made customization optional. To acommodate the defaults and ease user concerns, we added a review screen that included previews of the vector and payload with customziations.
Brainstorm
1.0
2.0
2.1
3.0
4.0
Details
The tone and content was a key contributor to the tool’s success, so a huge thanks to Jonathan Crowe. His level of detail on the payload variations was contagious. We set out for two payload options, but for each option, he delivered two themes with 20+ variations. Once I saw them, I decided to code the vectors in HTML/CSS instead of using full-screen background images. I wish measuring the impact of little details was easier, but our efforts were validated during user testing. On a few calls, users pointed out how much they enjoyed the comedic tone (we did have to dial it back a bit).
Vectors
Payloads
Building
Now that we were confident in our prototype, we proceeded to build it. We built stackhackr as an Angular SPA to leverage existing workflows and knowledge (our main product is an Angular SPA). For its development, my responsibility was to contribute the HTML & CSS. We leveraged Tachyons CSS to shorten development time and provide future flexibility.
Results
This project was a huge success for the business, driving both raw leads and revenue pipeline. In its first week, it had 5,000+ page views, with reddit as the primary referral source. On reddit, the tool received 450+ upvotes on /netsec and /sysadmin (was in /netsec’s top 50 for the past year). That success in driving traffic turned into business success as stackhackr became responsible for sourcing the highest percentage of marketing qualified leads (MQLs).
From a usability standpoint, the screen flow performed quite well. In the following months after launch, stackhackr had a 20% conversion rate from the landing page to submitting the form. Considering the majority of traffic was from reddit, the team was happy to see 45% of visitors proceed to the ‘Build’ page from the landing page. From there, 82% of visitors made it to the ‘Review’ page. Of those, 55% filled out the form and launched the test.
Things weren’t all roses as the tool didn’t perform as well for paid campaigns. We hypothesized this was a result of a lack of social proof. On reddit, it was x-posted organically and those two posts had ~25 and ~50 comments, respectively. To address this issue, we added a landing page for paid campaign traffic that showcased select reddit comments.
Going forward
This project proved how valuable user testing can be. At a basic level, it validated design decisions and enabled us to ship a better product. Without user testing, we would have likely shipped a version similar to 2.0. In that concept, I added more discrete ‘steps’ to create a simple experience; allowing the user to focus on one task at at time. Through user testing, we learned that our audience didn’t care for it. They preferred straightforward controls with all necessary information on one page.
What I didn’t expect and what I’ll use for future projects, is the impact of the user testing schedule. We did not plan the schedule to provide a day on and off from testing. That’s just how it worked out. But that approach created a constraint for us to rally behind. Each day we had to prioritize what we wanted to test based on user feedback. Those proposed solutions were quickly validated (or not). And after two weeks, we felt much more confident in our direction.
P.S.
The tone and humor of the project made it quite fun. I encourage you to check out the malvertising vector so you can read up on The Funyun .