Endor Labs

Intro

I was the founding product designer at Endor Labs, a dependency lifecycle management tool for software developers and application security people. The product is a combination of a CLI which performs static call graph analysis on source code, a GitHub Action that manages how repositories are scanned, and a web UI that helps people view and prioritize findings in their code.

I owned the design of our first product from conception (March 2022) to launch (October 2022), to our first few customers (January 2023).

Team and collaboration

I reported to the CEO, and collaborated most closely with the co-founders (CEO and CTO), product manager, and lead front-end developer.

Every week, I held a design review with our CEO, CTO, and product manager, to review the current state of design, discuss feedback from prospects, and untangle any misalignment between backend and frontend design. Separately, I met with our lead front-end developer (and occasionally other members of the front-end team) on an as-needed basis to review the current state of front-end development and untangle any misalignment between design and engineering.

Aside from these regular meetings, I worked in a largely async mode, surfacing regularly to share the state of design (using Loom and public Slack channels) and get feedback from internal stakeholders (including backend engineering as needed). We worked with a bias towards shipping, so that our CEO could demo to prospects and so that we could get feedback from early adopters. In general, we avoided long-running discrete projects, and instead shipped incremental improvements in response to feedback we were getting throughout the initial few sales cycles.

Early user journey map

Very early in product development, before we had a dedicated product manager, I interviewed multiple internal stakeholders, including the co-founders, and built a map of personas, jobs to be done, and an initial set of workflows. This helped us establish a starting baseline.

Early conceptual prototype

Starting from the user journey map, I built out multiple iterations of a low-fidelity prototype to help us better visualize the workflows. This level of fidelity helped facilitate internal debates about what we were trying to build, even before real data from the backend was available to feed into the design process. We also began running discovery interviews with external folks to understand if the problem we were solving was real and what their mental models were.

Early data viz exploration

When we showed the early prototype to users, we discovered that CISOs didn't care about the granular details of which packages are affected by which vulnerabilities. CISOs know that the list of vulnerabilities is always long, and the important thing is that the most important vulnerabilities are being dealt with and that the long-term trend is down.

The solution to this is time-series aggregations that help identify medium-term trends so that decision makers can allocate resources effectively. Since the product needed to serve both management and ICs, I decided to explore a dedicated high-level dashboard specifically for the buyers of our software.

Our CEO showed this view a lot in product demos to prospects, and while the initial explorations weren't quite right, over time we iterated to a useful view for these personas.

Usability research results matrix

Throughout the development of the product, I ran discovery and usability research projects with internal and external users. Some of the external users were design partners also interested in purchasing the product, and others were recruited from LinkedIn or userinterviews.com.

Product screenshots

Here's a sample of the work that I shipped during my time at Endor Labs.

Project and default version overview

Once a company onboards their code repositories, either by installing a GitHub app or scanning locally using our CLI, they can view the health of those repositories using our web UI.

Project scan history with CI status

Endor Labs performs static analysis of code. This scanned data is uploaded to our service and the history can be viewed in the UI. Depending on how policy is configured, these scans may block the companys CI pipeline until any violations are resolved.

Policy configuration with Rego editor

Users can configure policy rules using either existing templates or from scratch using the Rego policy language. We use the Monaco editor to embed a VSCode-like experience in the web UI, including a linter. Once defined, policy rules are assigned to projects using tags.

Finding details with call paths drawer

Findings are essentially insights about your projects. Every finding has a type and severity associated with it, as well as a large amount of metadata. Findings can affect a project, one of its packages, or a dependency. Because we do static code analysis, the path to affected code is frequently known and displayed here. Depending on policy, a finding could result in a blocked CI pipeline as well.

Dependency graph with detail drawer

Most software projects depend on a large number of open source dependencies. This dependency graph is used to interactively explore the graph, either starting from the package and working towards its dependencies or from one of the dependencies and working towards the package that imported it. Additional details about any dependency can be viewed via a drawer mechanism.