Foundry is for data engineers, scientists and analysts

 Before, our users’ workflows would span across different applications and websites where their workflow would be segmented. For example, they would use one tool to import their data, but scramble to another application to analyze the same data.

With Foundry, our users now had one cohesive ecosystem where all their data lived in one place. You can think of Foundry as a web-based ecosystem with a suite of products that lets users ingest, analyze, build, and report data at a large scale, all in one unified system.

The suite of products include tables, dashboards, reports, and data ingestion/transformation tools.

 

During my time there, I spent most of my time working on Foundry. There are two different areas of the ecosystem that I wanted to highlight below -

Foundry’s foundational layer that was responsible for search, file management, notification, and etc.

Foundry’s foundational layer that was responsible for search, file management, notification, and etc.

Code Authoring, which is a data transformation tool used by data engineers and scientists to clean, explore and build data through code. It’s a powerful tool that lets users build automated data processes that predict business patterns.

Code Authoring, which is a data transformation tool used by data engineers and scientists to clean, explore and build data through code. It’s a powerful tool that lets users build automated data processes that predict business patterns.

How would a data engineer at Airbus use Foundry?

 Sam is a data engineer at Airbus. She ensures the quality of airplane engines before every flight by writing scripts to automate this process in Foundry.

She navigates to her project space to find the right repository (A Code Authoring file) to begin her analysis.

finalworkflow.gif

Projects

 

What / Projects is a file system update to the foundational layer of Foundry.

Why / Our users were having a difficult time locating their files with the old file system.

Search wasn’t helpful at the time.

Role / Lead designer and led research.

Timeline / 4 weeks from exploration, ideation to shipping to customers.

Team / Worked with PM, engineers and other designers for contextual feedback.

How did we get here?

How did we know if this was an important problem to work on? 

Our PM at the time was the best at keeping communication channels with customer sites (with embedded Palantir analysts to help users with Foundry). We’ve been consistently getting feedback from many different deployments that the file system wasn’t helpful for guiding users to find their files.

After many conversations with both customers and Palantir analysts, who were both daily Foundry users, we decided to redesign and build out an entirely new file system.

How did I collaborate with my PM?

I relied on my PM to help me cover the business needs of the project by connecting me with the right deployments in her network to conduct initial interviews to gather data on how users are currently using the Foundry file system today.

What did my exploration and process look like?

Below are some different directions I sketched out when I as trying to go broad, before going deep in one or two directions.

process5.png
process3.png
process6.png
process4.png

How did I work with engineers and how did we measure success?

I was lucky to work with really talented front end devs where we didn’t need to spend a ton of time adjusting visual or interaction details after implementation. We debugged and shipped quickly, so our users could have access to Foundry’s new file system.

We got a lot of qualitative feedback from Palantir analysts out at deployments saying that customers now had an easier time finding their files. They spent less time emailing Palantir analysts to ask to help them find their files. This way, they became more autonomous in how they use Foundry.

Build progress in Code Authoring

⭐I got to work on this project as a result of spending 3 months at a customer site where I was a Foundry analyst. I was there to lead Foundry workshops, onboard users, answer questions on Foundry and gather feedback and observations to relay back to the product teams ⭐

What / A progress overview that outlines what happens behind a build.

Why / Our users didn’t know what the build operation in the tool did, even though it was the magic button they pressed daily after they were done writing code.

Role / Lead designer and led research.

Timeline / 2 weeks of research at deployment + 2 weeks of exploration, ideation to shipping to customers.

Team / Worked with engineers for shaping product direction and implementation.

How did we get here?

How did we know if this was an important problem to work on? 

I spent around 3 months working at a client site in the banking industry to observe how clients are using our product out in the field. It was incredibly rewarding to see use-cases at first hand. While I was observing our customers’ workflows, I noticed that almost all of them clicked the ‘Build’ button every day, but would often be frustrated if their build process failed.

What did my exploration and process look like?

After I came back from the rotation, I joined the Code Authoring team to help out with their design needs and this was one of the first projects I worked on with the team.

Screenshot from a working Sketch file

How did I work with engineers and how did we measure success?

I was lucky to work with really talented front end devs where we didn’t need to spend a ton of time adjusting visual or interaction details after implementation. We debugged and shipped quickly, so our users could have access to the build progress panel.

We got a lot of qualitative feedback from Palantir analysts out at deployments saying that customers could now debug their build process if it failed.. They spent less time emailing Palantir analysts to ask to help debug through error logs. This way, they became more autonomous in how they use Foundry.