InGRAIN hero

Designing a product that safeguards the data that matters to you.


InGRAIN is one of the newest products at Red Sift, cybersecurity for everyone. 
The product consists of a monitoring agent in the cloud. It helps you to define how normality looks like and automatically detects unusual activities, malicious workloads, or potential insider threats in real-time.
As a new product, I have been involved in the process right from the beginning, helping the product owner, devs, and data scientists to shape up the product and make it usable. From the architecture until the branding, it has been a very special project, due to its complexity and the quantity of data visualization that was needed. I enjoyed it very much.

The problem

At the moment, on average it takes 206 days to identify a data breach. 94% of organizations suffered a container security incident. InGRAIN wants to help by detecting all these anomalies in a one-stop solution.

The product is really in the early stages and we need to identify what the target user needs. How to display that info in a way simple, and systematic, so they can identify patterns periodically.

Once we have the architecture and key features clear, the next steps are speaking with people and get clear feedback that will help us to move towards the next steps, building up the roadmap.

The solution

Create a product where customers can see patterns, define what is normal and what it is not. Go from the big picture to the detail, until you can find the root of a problem. Educate your machine, and set up alarms in the back of it, so you can find these anomalies faster.

Create a new product that helps you to understand how normality looks like. The product is very technical, and the target user is very powerful. We have to keep this in mind when trying to build the product and cover necessities.

Cyber Security, Saas, Tech

Product design from research to conception. Helping out with data representation as well.

The design process

Understanding the product we want to build.

For understanding well how we want to build the product and anticipate our users needs, we started by:

Interviewing potential customers

Data observability for cybersecurity was a hot topic when we started to work in InGRAIN. It was interesting to speak with potential buyers that used different products for doing that, but they still felt the gap. Gathering data from them helped us when prioritizing key features in the product.

Identify current daily pains

We saw that traditional tools gave you some insight for getting the routes of the problem. Still, for arriving there, engineers and CISOs spend long times, and frequently they had data breaches, as they didn’t see the problem on time.

Targeting potential users

In the beginning, we thought of Dev-ops and potential key users.

Speaking with different people, we could see the value of the product for other technical profiles, as data analysts, IT teams … which helped us to augment the scope and target from a higher level.

After writing down our priority list, the next steps were to try out concepts quickly and test how the concepts were rendering for us and our potential users.​

Double diamond model

In the time I worked in InGRAIN, we had a huge number of variants trying out concepts. In the beginning, we tried to develop them all. After a while, we introduced some usability tests with different people across the business that gave us greats insights for further developments.

Defining our user personas

The research was conducted by the product owner, Peter. By leading meetups, conferences, diverse workshops, and making parts of the product open source, he could figure out where the interest was coming from and the key profiles of people interested in InGRAIN.

The key user personas we found were mainly 3: IT security, analysts, and DevOps people. As a key user persona, we will use CISO Sid.

User stories. How success looks like.

After speaking with the product owner, several potential customers, and having the key features scoped for an MVP (minimum viable product) we can map out some user stories. They will be grouped and prioritized for the roadmap in an affinity diagram.

Information Architecture: key features.

InGRAIN will be always part of the Red Sift platform. There each product is called Sift.

Every sifts are unique and independent. In this case, all the features within Ingrain will be focused on slice and dice data, so then you have a greater level of observability. And you can set up alerts as you are learning.

You will have a big amount of documentation and interactive guides in the help center section.​

User journeys

Having clear the user personas, needs, and goals of the users, normally I will sketch out some user journeys.
When doing so, I always have to keep in mind variable situations:

1. Scalability - how the data looks like with a lot of data, and no so many
2. Empty status
3. Errors
4. What happens when the auto-generated data looks too long

By doing that, we can discuss workflows early on with Product, Developers ... and try to cover as much as possible. In this fashion, when design hands off all the designs to Dev the process will be way smoother, and we will save some back and forth.

UI: Design library and branding.

While the user experience is key for building up the structure of the product and helping the user to get what they need, the product gets its soul and appeal once it has its branding.​

When building the components and style guide of InGRAIN, I had the following concepts in mind.

1. Reuse components.
We will take the atomic components for other existent products as a base for InGRAIN. Having a solid design library helps to move faster.

2. Adapt the components to the user.
The average user of InGRAIN will be more powerful and focus than other products, we will need condensed information, so they can get results really quickly. The components will be smaller for InGRAIN, for taking greater profit of the space. They will be also way more complex, they will use the atomic base of other products and scale into molecules that will align with the customer needs.

3. The product is about observability.
While other products as OnDMARC or OnINBOX are green, we bet for the blue for InGRAIN. Blue is a color that brings you calm, focus, and it is fresh in tech. As we scale colors, we want that each one of them has its own meaning.

4. Fonts, as in the rest of products, will be always 'Raleway' for body copy and 'Source Code Pro' for numbers.

5. Invest time and love in data viz.
Due to the complex nature of the product, we will need a big amount of data charts accessible for everyone and pleasant to read. Using libraries, we were brave and add our own color palette for data visualization with 20 shades of colors. It was a really interesting project to work on.

6. Keep it sharp and simple for the first versions.
Keeping in mind our human bit. After reading lots and lots of data, some illustrations and little details will make a difference in your day, and take you a smile.

The App: Some high resolution prototypes

As a new product, it evolves quite fast. I will attach some images of the latest designs, being well aware it might change and keep growing.

Onboarding and feature tour screens.

Do you feel curious about InGRAIN? You can take a look to the documentation page in
We did a bespoke landing page for it. If you have further questions related with the design process, don't hesitate in reaching out!

Take aways

Working in this product was really interesting and helped me to learn more about new profiles of people (way more technical) and about data visualisation and machine learning concepts. It was fun to start working in a project right from the start, seeing the initial thoughts of the product owners and collaborating together.

As the main challenge as a designer, I would highlight the level of complexity of the product. You need to speak a lot with technical people, and trying to translate these concepts to your field, so you can help. Stretch your mind and try out different concepts over and over. In the end, it is also nice to look back and see how the product grew and evolved.

Next steps for seeing if the product is evolving well is doing user research and conducting some usability test. So we can see what parts are working and what need to change. And keep reiterating.

Let's chat!