Published on <a href="http://ift.tt/2rYMxwc">| Prototyping: From UX to Front End &mdash; Medium</a> Hayden Bleasel <img alt="" src="http://ift.tt/2rehtLC">
Looking back, I haven’t shared or written anything about my time as an intern at <a href="http://ift.tt/2rYYtxU">Palantir</a>. After I came back in January, I became so busy working on <a href="http://ift.tt/2rezbhY">Presumi</a> that I never found the time to write or publish anything.
What you probably know about Palantir is that they’re a data integration and analysis company. They’ve got two main products that they offer to customers — Gotham and Foundry — for enriching, managing and analysing enterprise and quantitative data.
What you’re less likely to know is that Palantir work on a slew of <a href="http://ift.tt/1JnNZvK">custom solutions</a> like Slate, Contour and Foundry that are tailored to specific clients or problems. Many of these new projects were introduced to slowly phase out the legacy systems, replicating their features on a case-by-case basis.
I was a Product Design intern working in Palo Alto. I was on an amazing team tasked with designing a anti-fraud focused pilot project. Palantir was my first purely design-focused role at a company. I can’t talk much about my work out of respect for the company but it did kickstart my design career in an interesting way — designing a platform to visualise and connect petabytes of highly secure information.
What I can share with you is how to think like a Palantir designer.
Data visualisation is at the core of what Palantir does. Anyone can hit up a database and show a bunch of text and graphs on a screen. The real challenge is in figuring out what this data means and how humans naturally interpret it, then transforming those insights into actionable information.
The project I was working on built on the core layout and visualisation techniques of Gotham. The fundamental visualisation of the product was object-node graphing (called Graph View), similar to <a href="http://ift.tt/1s7WePj">Cytoscape</a> or <a href="http://sigmajs.org/">Sigma</a> but at a quantity that neither of these libraries likely support. Datasets would typically be drilled-down and isolated in the Graph View and the subset brought into a relative, time-based visualisation called Stacks.
Stacks helped show object frequency and positioning over time which could be used to find recurring patterns. The level of granularity required for most cases meant we needed a library that didn’t use a bezier curve to simplify things and allowed for dynamic scaling of time range (years, months, weeks, minutes). We had our own open-source library for this called <a href="http://plottablejs.org/">Plottable</a>.
The last part was an Object Viewer — an inspector for individual or small groups objects. It showed the object’s properties with varying visualisation based on property type — string, pointer, geolocation, etc. It also listed that object’s relationships to other important items. By doing this, you were able to inspect a particular object in detail then traverse it’s relationships.
Without context, this seems like a pretty easy task. Just smash some libraries together into a React app and hook it up to a database. But what you have to remember is that we’re talking about rendering terabytes or petabytes or data in a Google Chrome window. At that point, guiding the user to isolate a subset of data becomes more important than rendering everything.
The point of this is that we built tools for analysts, and an analyst is only as effective as their tools. Rather than focusing on aesthetics from the start, just use Bootstrap or something. Get the user experience right first by giving the user what they need to do their work effectively.
Problem-focused interface design was an important aspect of the design culture. At the time, Palantir had so many clients and projects that there was no time to reinvent the button stylesheet. We developed an internal (now open-source) styleguide called <a href="http://blueprintjs.com/">Blueprint</a> to handle the common aesthetics.
This was an important step for the new web-based projects. When you remove the need for designers to craft a user interface and experience, they’re able to focus on solving problems and designing completely new components which could later become part of the ecosystem.
Of course, working on the web means we were limited as much as we were empowered. As the design team mentioned in their <a href="http://ift.tt/2iQgaNX">article about Blueprint</a>, the platform’s interfaces used to run on Java. “When browsers evolved and new web technologies were developed (e.g., Node, Sass, ES6), suddenly we could deliver the full depth of our data analysis software right in the browser.”
But browsers bring their own chaotic background with them. Our apps had to be containerised to support legacy browsers which is a concept that a lot of developers and designers tend to ignore. There’s a trend on the internet now called “Fuck IE” which involves unashamedly and ruthlessly dropping support for older versions of Internet Explorer.
Here’s the thing — if you want to design a platform that’s accessible then you need to support legacy IE. One of the unfortunate perks of the job is that you don’t get to determine who your customers are or what browser they use. I hate to use a cliché “startup vitamin” quote but think about what Steve Jobs said — “if a user is having a problem, it’s our problem”.
This isn’t limited to browser support — consider the deaf, the blind and the colourblind. There’s plenty of ways the web caters for the disabled, through ARIA tags or colour contrast checkers. There’s too many designers that are focused on reinventing the wheel and taking shortcuts where it counts.
Pushing the boundaries is what I found to be the most inspiring part of working at Palantir. Just because something is, doesn’t mean it has to be. One of the biggest things I learned was to get out of your comfort zone when designing, consider all the possibilities and explore all of them.
It’s not just in terms of design. How many other companies can you work at where you wake up in the morning, have breakfast then spend the rest of your day helping expose financial fraud, eliminate slavery, coordinate disaster relief or discover new medicines? It’s unreal.
It was hard adopting to Palantir’s design culture initially. Australia doesn’t have many opportunities like it, so my design career started boxed-in and limited to what I was told was correct. Silicon Valley is one of the few places you can design something because you and your team think it’s right, rather than arguing over how big the call-to-action should be.
I made enough mistakes there but I’m happy that I did. I wouldn’t want to be the same designer I was, not understanding the importance of my work to people’s lives and the value of knowing your craft. I learnt so much there that it’s impossible to summarise in a single Medium article, so maybe I’ll post some more later. For now though, I’ve got many more products to build.
Thanks for everything <a href="http://ift.tt/2rYYtxU">Palantir</a> and to the design team homies that set me on the right path — <a href="http://ift.tt/2renub1">Antoine Llorca</a>, <a href="http://ift.tt/2rZbzLt">Viet Huynh</a>, <a href="http://ift.tt/2reHaeX">Eric Grossman</a>, <a href="http://ift.tt/2rZnJUM">Alessandro Mingione</a>, <a href="http://ift.tt/2re6p0R">Matt Bango</a>, <a href="http://ift.tt/2rZlOzl">Ashley Einspahr</a> and <a href="http://ift.tt/2rem4gS">Joshua Goldenberg</a>.
✌️
<img src="http://ift.tt/2rZ8oTX" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2re11Lk">Data Visualisation at Palantir — how I learned to design at a petabyte scale</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data Visualisation at Palantir — how I learned to design at a petabyte scale

Top Stories