Randall Hansen

Toni de la Fuente has been building open source Prowler since 2016. It has become the gold standard for AWS security scanning and resource discovery. In 2021 Toni started work for Verica, and in 2022 we made plans to build a SaaS.

Here I walk through the user-facing process: user interviews, roadmaps & product design, workflow & wireframes, and final visual design.

We started, as always, by listening. Toni knows his users and community as well as any software lead I’ve worked with, but paying customers have different needs and expectations. So we started talking with startups and enterprises who might pay for a Prowler SaaS.

We learned how much people love Prowler

Prowler is often the first tool SREs install to understand existing cloud infrastructure. Users consistently trust Prowler to give them a complete and correct picture of their cloud infrastructure. This point cannot be emphasized enough. Most cloud operators are used to environments that are opaque and difficult to manage. Prowler gains a lot of credibility by helping cut through that noise.

Discovery is at least as important as security scanning. In fact, they’re often entirely different use cases. It’s notoriously difficult to get a full picture of what you’re running in AWS. Prowler is the preferred tool of teams inside AWS for this sort of discovery.

We heard few security concerns

Very few people raised security concerns with us hosting the results and reports from Prowler scans. This surprised me. We attributed this to a few factors:

• Prowler is trusted — Prowler and Toni have a great reputation already. People have trusted Toni and his tool with their security posture for years. The SaaS got a lot of benefit from that halo effect.
• SaaS security tools are not exceptional — It’s no longer exceptional for enterprises to trust SaaS providers with important information. There’s collective knowledge that the industry is moving this way, partly enabled by better tools like Prowler.

We learned how we could make Prowler more attractive to commercial and enterprise customers

• Documentation was lacking.
• GUI reporting was rudimentary.
• Installation was too difficult.
• A CLI tool doesn’t work well for stakeholders.
• It’s difficult to see, compare, or correlate results across multiple AWS accounts.

Combing through this feedback gave us the first sketch of a service offering. We thought we could make a simple SaaS that elevated a lot of the value of Prowler without exposing the complexity of setting up and maintaining the tool.

We made a roadmap to the first release. Breaking pre-release work into small stages makes them easier to test. After each small step we made sure of our progress, so we weren’t at risk of pushing an untested, big-bang first release.

Free is easy; paid is hard

This was the minimal product that we could launch as a free tier service. We knew we needed many more things for paying customers.

• Multiple AWS accounts.
• Multiple users per account.
• More control over reports.
• Better filters to prevent surfacing noise and false negatives.

As of July 2023 these first two features are live.

One of my early steps in any design project is a search for prior art: who else has solved this problem, and how? It’s arrogant to think that I’ll design a first-class solution in a vacuum. Many people have more experience than me in this domain, and I’m happy to stand on their shoulders.

We knew what other SaaS tools our customers used, and which were considered best-in-class. So we onboarded with as many of those as we could and took good notes.

I love that we didn’t find any dark patterns

There were no dark patterns in any of these products: companies know how important trust is, and tend to be very clear and explicit about expectations. Almost all these products asked for the bare minimum information, described each step and its effects well, and allowed free trials.

Workflow is the most important part of UX design: where do your users start, and how do you meet them there? How do you lead them towards success while still allowing them to maintain agency? Onboarding is an easier problem than most, because you know exactly where users will start, and where they want to end up.

It’s worth optimizing onboarding

I started niavely, examining every possibility and doing effort analysis on each flow. This is in my blood, I think: my father was an industrial engineer, and spent many years doing time and motion studies of Goodyear tire builders.

The point of examining each possibility is to find a truly optimal solution, not just the first solution that works. Even a few percentage points of success vs. failure in onboarding can make a huge difference, so it’s worth optimizing it hard. We ran many possibilities, testing with ourselves, friends, colleagues, and prospects until we had the simplest flow we could construct.

Subscriptions are more complex

Next, of course, we wanted people to give us money. Workflow is again the most important element here, and this workflow has multiple entry and exit points. We were offering a 14-day free trial, so we had to model the passage of time. People could cancel at any time, so we had to model escalation and de-escalation of privileges and features.

I made the simplest set of wireframes I could, including the bare amount of detail. I wanted to communicate with engineering only about data and flow control, so the visual design aims only to distinguish elements. This allowed engineers to build a working prototype fast without getting stuck early in small details.

I made an interactive prototype so we could see how this felt. No diagram will give you the visceral experience of clicking through a workflow. This also gives us a cheap way to prototype error flows and error screens.

The Dashboard — two types of use cases

The Dashboard is the first screen users see after they login. We had talked with enough users to know what they wanted, and we saw two distinct types of use cases.

Users who come regularly looking for details

• What important things have changed recently?
• What happened during the last scan?
• Where do I start fixing things?

Users who come sporadically to see summary information

• Are we making progress, or falling behind?
• What are our most important failures?

I separated these use cases by column, expecting that I could distinguish them further during visual design.

Notice that it’s ugly?

The typography is terrible. Nothing lines up. None of the graphs are final. Some of the elements are labelled, but not detailed with even basic data. All of this is intentional, and like polished visual design it tells a story – “Very rough; lots of ambiguity; not production-ready.” This type of artifact is not customer-facing, of course, but it works very well to communicate with engineers. There’s enough here for them to start working in the right direction while I define more details.

A mockup with more visual polish will get worse functional feedback — even from engineers! This may be counterintuitive, but it’s easy to see people behaving this way when you pay attention.

Visual polish repels functional criticism

Most people don’t have a nuanced view of design, and are overly impressed with visual consistency and polish. That’s why visual polish is such a super power, and why designers strive for it. The legendary Don Norman writes about this at length in Emotion & Design: Attractive things work better.

I learned this in the 1990s, working with architects. Their first computer renderings looked too perfect and clients didn’t like to critique them. Clients were afraid that the visual polish meant the work was already complete, and they deferred to the expertise of the architects rather than offer criticisms. The architecture firm employed a visual artist to redraw the renderings in a sketchy style; this encouraged much more useful feedback.

Visual feedback	Functional feedback
That link isn’t our brand blue.	We should have a link to documentation here.
The loading spinner on step 2 doesn’t have a transparent background.	We could combine step 3 into step 2 since we already have the data.

Visual design done well is communication, not just decoration. This always seems like the most straightforward stage to me. We understand what our customers want; we’re confident in following best practices they’re already familiar with; we’re presenting the most important information.

With additional visual vocabulary we can tackle the last set of problems:

• Emphasizing important information.
• Distinguishing important details.
• Affording comparisons between related things.

Another good reason to save visual polish for the end is so that engineering doesn’t have to wait. The team was building graphs and optimizing queries while I was iterating on visual design. Small details can take a lot of time to work out. Often you have to see things concretely to judge them, or compare them with alternatives.

Toni de la Fuente created Prowler and has curated its community as well as I’ve seen it done; hats off to him! (He even names his releases after Iron Maiden albums).

Toni put together a great team in Spain which made huge progress on Prowler over the last year: Nacho Rivera, Pepe Fagoaga, and Sergio García.

The SaaS itself was built almost entirely by Drew Kerrigan and Jon Young. Their months of pragmatic focus and good technology choices enabled us to launch something useful in very little time.