Summary of JupiterOne work

In his book “Hit Makers” journalist Derek Thompson highlights the work of famed industrial designer Raymond Loewy and the concept of the MAYA (“most advanced yet acceptable”) design. The MAYA design sits in the middle between solutions that are entirely familiar and those that are entirely novel: be too familiar and customers will look right past you, but be too novel and customers will tune you out.

MAYA is the sweet spot. Novel, but familiar. Advanced, yet acceptable.

JupiterOne already had robust functionality when I joined the company. Its struggle was a perception that it wasn’t “easy to use”. JupiterOne excelled at the advanced and failed at the acceptable. The product was very innovative, but too novel.

The core data graph and proprietary query language are powerful but still new for most security customers. JupiterOne’s user interface doubled down on that novelty by diverging from many common UI patterns that might help a new customer orient themselves in this space.

We aimed our design approach at moving JupiterOne toward its MAYA sweet spot; make the platform more familiar via its UI to offset the novelty of its core technology. This means leaning into common, robust UI patterns from other web applications. It means aligning navigation patterns with what customers expect from other tools in our space. It means making color an enhancement rather than a distraction. And so on…

We haven’t stopped innovating, we just now recognize that we must dress our innovation in familiar clothing to make it approachable for the nascent ‘attack surface management’ market.

My CEO might shed a tear at this simplification, but for our purposes, you just need that basics.

First, JupiterOne ingests a lot of data that might be important for your business’s security via our extensive set of integrations. We pull that information into one big ole data graph made up of ‘Entities’ and the relationships that connect them. These could be infrastructure-type entities like AWS resources, identity-type entities like user accounts and much, much more.

Once you’ve integrated some data, we give you the ability to search it deeply via our graph query language (J1QL), letting you save important queries for quick recall into smart query containers we call ‘Questions’. Why ‘Questions’? Because we strive to give you a natural way to ask JupiterOne about your security posture and get a meaningful response. Once you’ve saved a Question finding the data you want, it’s as simple as clicking that Question in your library to get the answer again with current data.

If you’re more comfortable browsing and filtering assets in a familiar tabular format, we also surface every asset of your cyber universe in our ‘Asset Inventory’.

Downstream from that core JupiterOne experience, we let you re-use those saved Questions in a number of powerful ways: as evidence for security compliance standards, as triggers for alerts and automations, and of course as data visualizations on dashboards. All that power from one core set of re-usable, connected data spanning your entire cyber attack surface.

Let’s hit a few bullet points on how we’re addressing our MAYA problem across the platform.

Global Updates

Navigation

Color

Dashboards and Data Viz

Key updates:

Cyber Asset Inventory

Key updates:

Query Interface

Key updates:

Graph Interface

Key updates:

Compliance Frameworks

Key updates:

Policy Reader & Editor

Key updates:

Alerts & Automation Rules

Key updates:

Systems for designers and devs

We didn’t even have a team Figma account when I joined, so we were starting from scratch as far as design team resources were concerned.

On the dev side the team had built much of the UI using the Material UI React framework. We chose to lean into adopting elements from that library, curating and refining our own specific subset to serve as the core of our system. We stood up a separate repo for this J1 specific Material subset (which we call Juno), and maintain it across a Figma library and Storybook instance, ensuring the two are closely in sync.

Color themes

Note: We haven’t achieved this ability within JupiterOne yet.

While dark mode is a crowd pleaser, I think it’s somewhat overblown as a feature within the design community. In my opinion, the most important reason to work toward releasing a dark mode is simply the fact that striving to support multiple color themes requires a lot of diligence to incorporate UI best practices on both the design and dev sides of the house.

So basically I’ve been designing with color themes in mind and dangling the carrot of dark mode out there to keep the team motivated 😇.

Brand Support

I designed the brand’s hero gradient that you see across our marketing site and also reworked the JupiterOne logo into the stoke version you see today.

The color system I established for the product influenced the refinement of our public brand palette.

I also chip in to provide product graphics for the website from time to time and have done some other random things like create Mac app icons.

Design Principles

To align the team on what successful product design looks like at JupiterOne I led the effort to establish our team design principles. This resulted in a current set of six principles: four focused more on the product (in dark blue), two focused more on our craft as designers. (in green).

Figma management

Like I mentioned above, I started our Figma team from scratch. Everything is custom based on best practices I’ve found within the field over the last few years and my own experience installing Figma systems at Signal Sciences, Fastly and JupiterOne.

I write consistently about what I’m up to in this area on my Substack. Of particular note:

How I facilitate workflow within Figma

How I think about file types

Design Ops and Workflow

I’m a big time workflow nerd, so I think about designing systems for team workflow just like I do for the products I create.

At JupiterOne I established the design management systems we use within the Atlassian Suite. I manage the product design backlog in Jira and partner with my counterparts in product and engineering to plan the roadmap to ensure all our application dev teams are working together to deliver a cohesive end-to-end experience. I also continuously improve our team Wiki on Confluence to facilitate better knowledge sharing in a fully remote work environment.

My background as a UI developer puts me in a unique position to be able to break down design work into meaningfully scoped chunks that facilitate better iterative development.

Design Keynotes and Vision Setting

On the flip side of my workflow tactics, my background as a brand strategist puts me in good position to help set the vision for both the product and brand. This could be storyboards to help communicate the vision of our ideal customer journey, slide decks to communicate product design strategy, detailed Figma prototypes to communicate new product opportunities or even just word docs to clearly capture problem statements and design opportunities.

If you’ve made it this far, thanks for sticking around 🙏🏻. I know this isn’t exactly a standard case study format, but I’ve just done too much at this point to have that format make sense as an intro.

I hope this can serve as a jumping off point to talk in depth about any of the areas mentioned. I’ll happily go deep with you on anything that piqued your interest.

I also plan to write and share more substantial breakdowns of individual projects on my Substack, so make sure to check in there if the nitty gritty is what you’re after.

Live long and design systems 🖖🏻,

Pat