Loading summary
Transcript53 lines
- [00:00]
Amar Reshi
If you're in one of these complex domains or industries, then the data model topic suddenly becomes important. It's like, what are the actual things that the people who use the software think about on a daily basis? Again, I'm sorry to keep talking about the verbs and nouns, but it really is that, like, if you can articulate A what the nouns or the primitives of your business are, and B, the actions you can take on them in a holistic way that you're already halfway there. If your thing doesn't work as a sentence with like a subject, verb and object, something's wrong with your like ment model.
- [00:33]
Rid
Welcome to Dive Club. My name is Rid and this is where designers never stop learning. This week's episode is with Amar Reschi, who's the head of design at 11 labs. And that might sound familiar because it's the AI audio platform that's been brought up multiple times on this show before. So one of my favorite parts of this conversation is just hearing what it's like designing an AI native product and all of the different interaction patterns that they're having to think through, and also just the culture of experimentation that's been birthed out of that environment. But before we get into all of the details of how design works at 11 labs, I asked Amar to give us the backstory behind some of his earliest AI experiments because one of them went completely viral.
- [01:17]
Amar Reshi
It's almost a 20 over 20 year old company now, started, you know, around 2003 in the wake of 9 11, mostly specifically for like government use cases. And I think the idea was essentially that there is a data integration problem, as with pretty much everything, like you and I have one of these, but think of banking or something where I would love to be able to see all of my finances in a single place. And I think the same applies to pretty much any other data heavy concepts or workflows. And I think in the case of the government, the idea was have a single place where you can actually integrate all these various disparate data sources and then take investigative actions on them. And so I think Palantir Gotham, which is kind of the initial flagship platform, was born out of that. And that was kind of roughly the life of palantir for about 10 years where it was like this government program, government software, working closely with various government agencies. And it was actually funded by in Q Tel, like CIA's kind of venture arm. And so there was always that relationship from the outset. But then around maybe like 2014, 15 is when kind of the initial seeds of Foundry began to be kind of planted and that involved essentially just a backend engine that like munges data really well. I think this is what's interesting about Foundry is that it really is kind of like, you know, this like Ferrari engine without the chassis around back then. And it was, it was made to essentially solve a lot of most likely kind of technically complex problems that I don't even fully understand. But essentially Foundry was this like multipurpose like data integration through analytics platform. You can almost think of it as like a data operating system. The funny thing about that one was it was not really clear like where it may get used and it kind of became this almost like application agnostic thing that you can really put any sort of data into clean, transform process and then derive decisions and insights out of. And I think the decisions part is quite important because it's not just a simple kind of tableau or analytics layer like you can be a data analyst, but you can also be like writing back into the system. It really is operational. And I think that's around when Palantir as we know it today was hardened. And so yeah, I think that's roughly what I would maybe say is like the gist of the company. It's really just data OS for any type of organization regardless of size or industry and should allow you to take any sort of unstructured, disparate information and like make sense real quick message and.
- [03:41]
Rid
Then we can jump back into it. So you know how I've been talking about how I use Genway to do research with AI? Well, something surprising is happening and just for context, I use Genway in two different ways. One is contextual interviews. So I prompt the AI with what I'm hoping to learn and it has a dynamic conversation with each person. And the second is usability testing. So I upload a Figma prototype and their AI agent helps me test them with people all over the world. I mean you should see the quality of the follow up questions. It's pretty crazy. But here's the surprising part. At the end of the interview, most people say they're more comfortable opening up to an AI agent than a real human. And it's just another reason why I'm hooked on the product. If you want to try it out, there's even a secret landing page just for Dive Club listeners which Give gets you two months free and 10 credits to recruit people. Just head to Dive Club slash GenWay. That's G E N W A Y. Just when I thought I understood how powerful Raycast is they released their all new AI extension. So you can interact with all kinds of apps using natural language and you can even connect actions to stream together workflows. Like in a single command I can start a focus mode, change my Slack status and press play on my favorite Spotify playlist. And that's just the start. I mean there's already extensions for Shopify, Linear Zoom, Google Calendar, and this is a pretty big time building block for the future of AI and productivity. And it's a big reason why I've never been more excited to be all in on Raycast as a product and as a team. So if you want to learn more, they have a really compelling video that you can watch at Dive Club. Slash extensions. Okay, now onto the episode. Maybe we could start with your early journey. And I actually recently interviewed Amar Reshi who was at Palantir, and one of the things he talked about how he really appreciated the level of autonomy that designers were given on day one. So maybe you could just start by talking about like what was your early experience like when you joined?
- [05:50]
Amar Reshi
Yeah, yeah, I think actually mine was pretty interesting actually. Amar was one of my interviewers, so he was the one of the few people to tell me that up front and I kind of didn't believe it. I experienced it and I think it was completely true. And some more in my first few months I was actually on this team called BD Design, which essentially is a set of designers who work directly with the customer or like deeply embed with different customers. And so I was out here just kind of, you know, going directly to various customer sites and working with them on their products. And I think that's one of the interesting things about Palantir is a lot of the product is built in the field for quite a bespoke use case and then slowly generalized and brought back to the core platform. And I think what you get from this is like you're not solving a problem for a thousand different types of users in one go. You're really just like building this like highly bespoke perfect thing and then worrying about kind of how to kind of bring it back. And this requires a lot of like first order thinking, problem decomposition, systems thinking, workflow, diagramming, and frankly like the boundary between being a designer or a product person or a developer is quite blurry in these scenarios. Especially when you're with a customer, they're going to ask you any sort of question regardless of your job title. And I suddenly have to like speak SQL even though I've never done it. And that's when you kind of realize that, like, you need to be able to kind of embrace the entirety of the platform and its capabilities, regardless of which team you're on or which product you're currently representing. That's kind of how my first few months were. I was working within the healthcare industry and it was just fun to see, like, how they were solving a lot of the same problems on various different sides of this. Like, you know, the domain, the healthcare domain. And you're really like looking at massive amounts of data that is hard to read, hard to parse and needs to be a visualized B, like, tangible. Like you should actually be able to like, filter it, do things to it, get to insights. And I think learning all of that on the job was definitely quite unique. Going back to your, I guess, speaking about, like, autonomy specifically, it's kind of most visible in the fact that we have only like 40ish designers. And, you know, we have maybe I believe 2,500, 3,000 people right now. A little less than half is the product team. And by product team, I mean essentially everybody who builds the core Foundry and Gotham platforms and Apollo as well. And I think if you think about this ratio, what this really means is like, we really do have like large swaths of UI or product that a single designer is owning from day one. It really isn't really about, like your seniority, which, by the way, we do not have levels per se. We kind of have like new hires, industry hires and leads, and that's about it. And you end up kind of owning pretty much a whole app in your first six months. And that comes with, you know, all the complexity you need to suddenly internalize what this app is for. It could be something like a time series analysis product which allows you to first understand, like, streaming and data density and all these kind of derived properties and all sorts of different ontological concepts and then apply them suddenly to interfaces and it's like it's just been six weeks. Yeah.
- [09:07]
Rid
Is it pretty common that the new hires would start off embedded on these teams in the BD platform or so?
- [09:14]
Amar Reshi
That's common. And I would say that I was definitely in a bit of an outlier, I think, at that stage, because of Foundry not being mature enough, we were spending more time in the field putting together, like, exactly what the user needed with a kit of parts that we had. And by kit of parts, you can imagine some sort of like workflow builder or website builder application powered by a strong data model and backend that is also designed and built In Foundry, that used to be a bespoke need back then, because everyone had their own custom workflows. And obviously you need a designer to like, figure out information architecture concepts, hierarchy, layout, all that stuff, including even visual design. Now we have much better tools. Foundry is much more mature, and so the stuff you can do out of the box is so much stronger that you don't really need to send a designer directly to this place and have them build that end use app. An example could be, let's just say a manufacturing company has a factory floor and each, each person on the factory floor has an interface that allows them to kind of scan apart and mark it as like, good or bad. Quite a simple interface. But back in the day, you would have to kind of figure out exactly the ux, go to the factory floor, shoulder surf with the guy and be like, oh, this is what you're doing. This is what you're holding when you're doing this work. This is the resolution of your screen. Now it's like much more easy to kind of just like, deploy an app out of the box that we call maybe, you know, template B of like, you know, triaging app or inboxing app, and you just kind of deploy that app. As long as the ontology is sound, you can customize it just enough so that it makes sense for the constraints of that user. So because of that, we don't kind of send designers directly into the field for one direct use case, but instead have them represent the product. They still go to the field and they still work with customers. But now you're kind of representing the product team more so than kind of representing the business development team.
- [11:11]
Rid
It's fascinating because you truly are having to account for an almost unprecedented amount of use cases, and to do so with the least amount of software created possible, I'm sure, is one of the core challenges of being a designer in this environment.
- [11:28]
Amar Reshi
I kind of see this internally, maybe more as a joke, but it really can be used for anything. Theoretically, you can build all of Airbnb on Foundry. Like, we have the backend infrastructure to allow that level of application to exist, and we have an app builder that would let you actually build something obviously not nearly as beautiful and usable, but still would functionally achieve a lot of the same workflows. And we do have data pipeline applications that allow you to view the lineage of all the data that's passing through. We have an IDE application within Foundry that lets you actually code these transforms and these data pipelines. If you're the data Engineer. I think what's interesting is that the core product that we're building is a product building application in itself and is the thing that allows you to spawn end new units of software. And so I think to your point about in as little software as possible, I actually don't think that's true. It's almost like front end is cheap. It's just this thing that you can emit as much off as you need. In my world, like this is maybe a bit of a segue now I'm like not speaking for Palantir as much as just myself, but I believe that like the bespoke artisanal software should be all around us. Think about like Costco coffee versus like small batch coffee, like which one is more valuable and fun? You know there's a reason for which is the one you prefer. I want small batch bespoke software that's like made just for me and my use case. This is vaguely what Palantir is kind of achieving when it comes to like you're an energy company and you need to understand a thousand sensors emitting tons of gigabytes of data per second and you need to kind of understand there is no other template out there that helps you understand it. We're just going to need to build this for you. And it's not a dashboard, it's not a read only view that's just like oh yeah, like things are going up, things going down, something bad, press red button. It's not that it's like write back based. There's entirely like multi step workflows, inner loops, outer loops. People are making artifacts in this stuff, people are collaborating on this stuff. There are security concerns. So I think at the end of the day, the most powerful part of Foundry is that it actually enables the existence of any of these things. And hopefully in the future, if we do the developer experience right, it would allow anybody to build on top of the Foundry developer platform and really start drafting these artisanal apps for their org, for their companies on their own with relative ease.
- [13:57]
Rid
Okay, I think I'm probably going to summarize a little bit more than I normally do for other episodes and just give you the opportunity to be like, okay, let's make sure that everyone understands where we're at. So we have bd, where the designer is like really embedded on the team. That's where you started. And then we also have Gotham, which is kind of how Palantir started, which is more of like the kind of the government contract origin story. And now we have Foundry, which is like this very open ended, kind of like dev tools platform on steroids. And you're a design lead on Foundry now. Do I have it correct?
- [14:33]
Amar Reshi
Correct, yeah. And I would be remiss if I didn't add Apollo in there. It is definitely a smaller 0 to 1 product right now, but I did spend a chunk of time on that as well.
- [14:42]
Rid
Okay, cool. So now I want to add a little bit more clarity in terms of like, what the heck are you designing on Foundry? So is there some kind of like an example project that we could talk through to understand what it's like to be a designer in that world?
- [15:01]
Amar Reshi
Yeah, yeah, I think Foundry I can maybe analogize to like the Adobe Creative Suite a little bit where, you know, there is like seven or eight marquee apps and you kind of become an expert in each. Like, you know, there's not that many people who are like, oh yeah, I'm like a Adobe Premiere expert and Photoshop and Illustrator. It's like you kind of become like one or two, like one or two workflows become your, your domain. So you're like a raster imaging guy or like a motion design person. So I think Foundry also has these Personas. You have like the data integrator, you have the data analyst, or you have the data scientist. So my point is there's like many different like categories of people who use and play with data and they range from slightly technical to like extremely technical. Now one of the projects that I worked on on Foundry was around making the data integration story clearer. As you can imagine, Foundry is pretty much just an empty shell when you first land on it and you need to hydrate it with data and the more information you give it, the better it gets. And as such that's kind of step one. So I spend a lot of time working on exactly what type of data integration we need to provide, what type of different sources people are trying to connect from, and what are the first few steps people take when they are actually bringing this raw data and like starting to clean it, transform it, join it, and turn it into what we call the ontology, which is essentially kind of an object aware, like data model that helps you make sense of the nouns and verbs in your organization.
- [16:30]
Rid
What have you learned about designing effective new user experiences, especially when your product out of the box is that empty shell that you were talking about?
- [16:38]
Amar Reshi
Yeah, I think overall my philosophy on onboarding is that when you are designing for somebody who is willing to spend the time and willing to kind of get those economies of scale. By first struggling through the learning curve, you just unlock a lot more. And I think I'm almost comfortable, like, following that approach of, like, this is not TaskRabbit or, you know, something where in between me downloading the app and me getting value on Dust Drive, it is like 10 minutes, 30 minutes tops, you know, and that's pretty amazing. It's a testament to their team that they've been able to optimize my click path so well that I don't even realize. And I have somebody at my house. And I think in the case of applications where you're literally buying this expensive, powerful Ferrari and you're going to, like, use it to do Ferrari things, you know, you're not going to use it to, like, drive to the coffee shop. You're going to be, like, taking laps of, like, a racetrack. And I think to me, that allows you to kind of take more time with the onboarding and add more complexity upfront without really worrying about walkup usability in its pure sense. That said, we are obviously optimizing heavily for walkup usability. And from a strategic standpoint, Palantir is obviously pivoting away from sending tons of people to your deployment to help you wire it up and instead allow you to wire it up yourself. And this is abundantly clear in the kind of earnings call data where, you know, we're literally starting to see people, like, time to value is getting down to, like, days. It used to be months or maybe even years in some cases. These pilots used to take a long time. You need to wrestle with the, you know, the company's ID or you need to wrestle with their C suite. You don't even know how many other, like, skeletons that are when you enter an org that you need to maybe like, deal with before they accept your solution. And I think this has become easier to do now. And I think that is a testament to design.
- [18:34]
Rid
I would also imagine there are instances where you have to make decisions that try to strike this balance between abstraction in the name of some semblance of simplicity versus preserving the raw power of the Ferrari. Can you talk about that piece of the design puzzle for a second?
- [18:53]
Amar Reshi
Yeah. I think one tool we use often is like, progressive disclosure. In these cases, there is some amount of concealment of the final thing where, let's say you want to build a streaming data pipeline that requires something to be live. The concept of liveness is suddenly very important. But we don't need to suddenly just because you wanted to build a streaming data pipeline of stock data let's say I have a stock ticker, it's updating every millisecond, the price is changing. You know, all these things are happening and I want to just visualize that and maybe take some actions based on it. Now I don't need to understand throughput and all these concepts of streaming and like stream transforms and pipelines to just be able to put that together. I should technically just be able to like do some sort of like connect stream to dashboard workflow and then if there is a problem or a roadblock or additional complexity or configuration needed, click some sort of advanced button or go one level down and then play with it. And I think that's one approach which is just slowly disclose what's needed instead of throwing the kitchen sink at the user's face. And obviously that's easy to say and hard to do because it's easy to conceal something for the first time. But for the returning advanced user, they're going to be quite mad. But that's where you get into redundancy. So to me, the other angle here is you should be able to achieve similar workflows in multiple ways, or at least from multiple entry points. So today we have essentially one application where I may do some sort of run or build or some sort of write based action like a big blue button that leads to the computer doing a lot of busy stuff. Now that button can either take me directly to the result of my computation, let's say I filtered some data set, or I can click some sort of view progress button and be sent into a whole new app. Which is the only job of this app is to show me the build progress in excruciating detail. That's basically to me like opening the hood of the Ferrari and watching the engine as you're driving it, if that's even possible. But that's kind of my point. So I think like this is another kind of like escape hatch that's available to somebody who cares or knows or wants to debug. And if you don't, that's fine too. You can just hit build, look at the results of your data set, go on with your life. But if you happen to be that data engineer guy who wants to optimize this pipeline a bit more, you might need to see the spark build profile or see exactly what kind of compute is being dedicated to this build. Mess with those constraints, tinker with it, look at the logs, stuff like that. So I think there's a way to serve both user types gracefully.
- [21:32]
Rid
I want to go back to Something that you said earlier. Then you talked about this idea of problem decomposition and maybe you could just unpack a little bit more about like, what that looks like in practice, especially as you're working through deeply technical problems. And for most designers, it's probably pretty unclear where the escape hatches even could exist.
- [21:53]
Amar Reshi
Absolutely. This, firstly, this is a good one because a. We call this internally, we say the word decomp a lot and everyone's always confused by it. But yeah, it basically stands for decomposition and I think is basically one of the most important differentiators of a designer's life at Palantir than compared to other places. And I think, I think this is because there is an abundance, like no shortage of complex problems. And maybe I'll just pick one in Apollo just because it's a little more recent. But essentially we have a software that allows you to manage and ship releases to various environments. And now the problem decomposition part here is that you will have a backend developer who will kind of maybe come to you with some sort of problem statement, which is that users need to be able to reliably ship the same software to a hundred different places without, you know, breaking a sweat. Now, that's a very generic prompt. But then you start breaking it further down and you realize, okay, I need to be thinking about who are the people doing this? Where is this journey starting? How many verbs and nouns is this person encountering on the way? You know, like, now maybe there's primary concepts like a release or an environment, but then there's secondary concepts like recall, where you can recall a release if it's bad, or maybe like promotion pipeline. This is another one where you basically are like moving a release through these stages of like, software quality. But it's like, initially it's like a dev state, then it's a release candidate, and then it's stable. Now these are secondary concepts. So I think the first thing that I would do in terms of problem decom is understand and create some sort of mental taxonomy of all of these concepts and give them some sort of weight of like, what is the main thing that people care about? And what are these like, secondary properties or metadata that they may or may not need to encounter. And if they do, we can maybe wait a bit before we teach them. So I think those are the things that I bring to the table when talking to the backend developer about the ultimate goal. And the way you do that often is by whiteboarding together, really just kind of going through these steps. You know, often it's just boxes and words, we don't really need that many pictures. We can all have a shared understanding of what things might look like. And I think what's most interesting is you do that with a backend dev, but you also do that with a customer user and then you may do that with some other like stakeholder who is maybe more product oriented. And you'll find that the results are always slightly different. And you as a designer, you kind of need to triangulate between these three approaches and either be in the same room and hash it out or understand the delta between these and consolidate it. One of the most interesting things I find as a designer in rooms like this is to, you know, you're sitting there and there's like six people arguing about something and they seem to be agreeing on some aspect and they talk about it as if it's this, like this assumed thing that everybody understands and imagines. And then I draw it out immediately on the spot and screen share or put on the wall. And then they look at the mock or the design and they're like, oh, actually we're all talking about subtly different things. And the difference is actually more than subtle. When you bring it down to the backend layer or the implementation layer, it's like to have this information visible at this stage requires so and so API update. So just the power of an image as the uniting thing that brings disagreement onto one surface is to me maybe where the decomp shines the most.
- [25:21]
Rid
You have a pretty wide spectrum of fidelity levels for what that image could look like.
- [25:25]
Amar Reshi
Yeah, so I used to do a lot of whiteboard sketching, literally on live whiteboards in meeting rooms. And then we got into remote land. I then briefly spent spend time with Concepts and on the iPad. Amazing app, by the way.
- [25:42]
Rid
Oh yeah, that's such a good app.
- [25:44]
Amar Reshi
So I would screen share my iPad directly in these rooms of like eight, 10 folks and just be like drawing live ever since. My figma skills have just gotten faster than Concepts. So I'm like, I just basically do live figma. Everyone else's cursors are already on there and we have a blueprint design system that makes it pretty easy to just like plop in the relevant components and assemble the collage of roughly what I'm thinking about. So in terms of fidelity, I would say it's all like stuff that looks high fidelity but is not. And this is a disclaimer that I need to always make when I share these things, which is like, hey, we put this together using existing components, but that doesn't mean, it's like, ready to ship.
- [26:26]
Rid
Is there anything else that we should touch on just in terms of like your personal process, maybe even like outside of the meeting rooms? I mean, it feels like you are often being handed these pretty hairy problem opportunity spaces. What are you doing to make sense of that complexity and get momentum in the very early kind of onset stages of a project?
- [26:50]
Amar Reshi
Yeah, yeah. And, you know, this is something. It took a little longer for me to learn than I would have preferred, but asking dumb questions early and often is critical. And I think, like, it's easy to get intimidated, especially at Palantir where there's, you know, the subject matter is, is complex and the words being thrown around are heavy. And obviously everyone you meet is, is very, very intelligent. And so you think, oh, this is not the right forum to ask this question. It is. You should absolutely just go ahead and get those clarified questions out, A and B, kind of find the right partner. Because we have a relatively flat structure, we kind of grow our PMs from within. There's a lot of fluidity in the roles and the titles. It's never clear what kind of org chart you're like looking at. And that's fine. Frankly, you shouldn't even worry about that. It's more just like suss out who cares about this and who has the right instincts to actually fill in kind of the gaps in your knowledge. There's three kinds of knowledge gaps that I typically find. One is domain specific. Literally just like, oh, I've entered this new world of healthcare or manufacturing, obviously I need to learn the, the kind of world they are in, what they are thinking of, their level of technical prowess, all of these things. The second one is like the completeness of the actual system. Like, I think sometimes I design an interface and it's good enough. It does like 60% of the job and the workflow is clean and it demos well. But then I show it to the guy who's about to build it and he's like, These are the 15 edge cases, out of which four are actually not even edge cases. These are just like generic cases that you haven't even accounted for. And so I think the completeness part is just like being able to poke holes in the system and the concepts upfront. And it's really a game of whack a mole of like, hey, if I move this thing here, something else is going to pop out and become a problem. So then I have to squash that. And so I think you need to be able to traverse the 5,000 foot view, 30,000 foot view. Zoom in and out and make sure that the whole thing works, but also the details work and you're not stuck in these degenerate cases with funky error messages that don't make sense. So that's the second one and I think the third one is just like proximity to the user flow or what I would call the golden path. So this is the opposite of the second one, which is like worry about edge cases. The third one is like, don't worry about edge cases, just focus on the golden path and then worry about the like, smaller cases. Now I don't really know if there's some order or like science to this. It's just something that you kind of need to like suss out case by case. Sometimes it's easy, sometimes it's not. But I think these are the kind of three things that I personally try to bring to most projects.
- [29:27]
Rid
I love the call out between the golden path versus the edge cases because in my experience that's like one of the hardest parts of being a designer is knowing when to let edge cases steal from the golden path versus when to say, nope, we're going to prioritize the golden path here.
- [29:47]
Amar Reshi
In our case, maybe we're a bit fortunate we're not building an app that is used by 3 billion people for one minute a day or whatever. You know, like that level, it's more like it's 100 people, but they're all PhDs. They're using it 9 to 5 and they're making some crazy stuff on it that's like gonna have more downstream impact than you can fathom. And so I think like, I have the luxury of being able to sit next to that so called PhD person and just literally bother them and be like, why did you click that? What does this word mean to you? Why are you even here in the first place? Why don't you go do this this other way? You know, like really get down to like that level of conversation. And I almost don't even call it like user research at that point because it's more just like I'm just like trying to be best friends with this one person.
- [30:33]
Rid
Yeah, you're like an account executive almost at that point.
- [30:36]
Amar Reshi
Exactly. Except I only know I only care about the design part and not whether or not they pay us money. And I think that's kind of the interesting part of the user side. So I think if you do more of that, these priorities become, they kind of become clearer through that process of like, this edge case was only visible to us internally because of the scale of the data we were hosting. It's not even a problem for our user because they have three environments and we have 200, so maybe let's stop designing for that. So I think it's like basically just seeking the truth really helps winnow out all the unnecessary edge cases and then focus much more on the ones that are truly going to be blockers. When you work with developers, they come up with these cases immediately. They have this amazing systems thinking way of just looking at your design and immediately talking about the three things that are missing from it that will result in a funky state. And I think that is its own great exercise. But I like to balance that against the user side as well. But it's like, yes, obviously we can spend all day ideating the thousand ways in which this can go wrong, or we can just find the two ways in which this will go wrong and design for those.
- [31:49]
Rid
Well, on that note, I have multiple unread emails in my inbox like right now from people who are trying to figure out what good systems thinking looks like and how to grow that muscle. And I'm wondering if I can just outsource that question to you.
- [32:06]
Amar Reshi
The typical things I find or failure modes I find are like not zooming out of the problem that's been given to you. And maybe we can just use a simpler example, like I don't know, like Uber or something not simple but you know, at least user friendly app that everybody knows consumer space. And let's just sort of break down the Uber app through a systems thinking context. What are the main primitives of this app? The rider or the passenger and the driver. These are two things, two sides of the coin. And there's the actual route or the destination. And really these are kind of the three main primitives. Then there are like sub primitives, like the number of the car, the destination, like the estimated time, maybe the type of Uber X versus Excel, what have you. We're already creating a mental model of all of these things. So that's kind of one type of system that you're creating. Literally just a taxonomy or mental model of like what are the main objects, sub objects, what are their properties? Are there many to many relationships? Many to one? One to many. That's important, right? Like when I call my Uber, it's one to many, it's me and 50 cars, one of whom will be my ride. Then it goes from that to one to one and remains that way until the ride ends and there's the life cycle Attached to it where it's like this thing has a timestamp of like the moment me and the driver are now aware of each other's names, details, locations, and the moment the ride ends, that is severed again. So there's a lifecycle aspect. So I think if I were to do like a systems breakdown, one system is the actual nouns, verbs, objects, primitives, whatever you want to call them, and how they relate to each other. The second system is much more transient or like time based. This is typically what people call the user journey or the user flow. But it's not just the user journey. There is like the user journey and the computer journey, if you will, and both are actually traversing this thing together. But it's like, if you ask me how was my Uber ride, I would be like, I was the passenger, I called it, I then waited for it, I got in, I drove, and I got off. Those are maybe the milestones of my Uber journey, right? If you ask the rider, it's slightly different, but it's similar enough. But if you ask the computer what was the computer journey for, like the Uber backend or whatever crazy algos they have, they would be like, oh yeah, we had to run a matching thing for somebody here and somebody there, optimize it based on so many conditions, including pricing, geography, what have you. And then we had to turn on this essentially security switch, which allowed the rider and the passenger to know a lot of information about each other, which is obviously quite scary from a security perspective. And then we had to toggle that switch off in a way that will prevent them from ever meeting again, which is also a security issue. And this is a crazy complex story from the engineer's perspective. And so I think being able to draw both these journeys together will A, make it easier to design for technical spaces and B, actually, I don't know if this is the right way to put it, but like empathize with the computer a little bit and see how your human concepts such as wait time and like, I don't know, estimated time of arrival actually like are derived and how you can actually design for those lags or delays or errors or whatever. So anyway, that was the second one. I think, roughly speaking, there is the system or the data model. The second is like the timeline or the story from the computer and the human's perspective. And the third one, I think from a problem decom perspective is the domain. Just knowing the domain is critical after a certain point. And this is again easy when it's an Uber, right? You've Taken one, I've taken one. We can empathize with each other ad nauseam. This is not true when I'm designing some sort of hospital interface for a doctor who is every night or a nurse who is every night submitting some amount of information about diagnostics or available beds or throughput or something. And so I think understanding these words, concepts, what's going through the user's mind when they're doing it, you know, what are the other tabs on their computer? Are the other tabs like GitHub and VS Code? Or are the other tabs Slack and Asana? That's going to change the data density I designed for. That's going to change the like what we were discussing earlier about like the progressive disclosure, like I can maybe throw more information at you if you already know a lot of computer science terminology, for example. So I think like, obviously user empathy is really what it boils down to, but I think shoulder surfing, being friends with this person, learning that domain, like I became really into manufacturing just like by mistake. Or I became really into like drug development and I was just like reading books about it. And then Covid hit after that and I was like, wow, like everything I've learned about like drug development is suddenly like really topical and valuable. And I think this happened because of just like deeply embedding with the domain.
- [36:52]
Rid
I have a smile on my face because just listening to you talk, like, it's so clear that you have put in the time. Collaborating directly with backend engineers.
- [37:02]
Amar Reshi
Yeah. Oh yeah, I love them. I must say that's like one of my favorite parts of the job is just like, like being able to honestly articulate my own problems. Like, you know, I think it's like two. It's almost like slightly different versions of the same language, like Spanish and Portuguese or something. But it's like we're both talking to each other in this like similar ish language, but we can't get into the nuance together. And that's where my like drawing comes in. So I draw and the engineer kind of talks over it. And those are some of the most fulfilling partnerships.
- [37:32]
Rid
Anything that comes to mind in terms of how you've grown over your now almost six years at Plantir, in terms of like how you foster those relationships with backend engineers and communicate more effectively.
- [37:44]
Amar Reshi
So I never like, not ask questions upfront. Like, even if I'm in a new space, new room, maybe I'm junior or out of whatever, I'm still going to just be like, forgive me for the dumb question. And ask it. And I think that goes a long way. Just the like format of asking. Instead of asking you like an asshole, you can just say it a bit nicely. And I think that's, that's critical. But overall, in terms of growth, I would say the reps, the reps really matter the most. I think when you design similar ish interfaces across various domains, across various technical competencies for different users, and with slightly different like technical, like power, you kind of realize that like a lot of these things can be broken down into kind of a catalog of like workflow types or archetypes you can think of. I'm on my like 10th inbox view and it's like this inbox view comes with a list of notifications which are transient, where if I act on them, they disappear, versus an inbox view where like I act on it and it like remains. So that's a case management view, right? And they look the same. It's just like stuff on the left, preview on the right, click on the thing, take an action. But the state machine is very different because the notification, the moment I click it, it's gone, it's disappeared, it's transient. And that has implications on the API. Whereas if I'm doing a case management work, let's say I'm like a lawyer or a law firm now I have an inbox item called get Ashwin's visa to Spain. And that's going to live for like one month till I get my visa. And it's going to have like states of like, okay, visa in process, visa delivered, visa waiting, whatever. And so I think even though these things look the same, once you start breaking down them, bringing them down into kind of these typologies or archetypes, you can start to apply them regardless of domain. And I think that's the thing I learned maybe like two, three years in and has been very, very useful for me ever since.
- [39:35]
Rid
Hey, it's red. I'm constantly asked about my favorite products. So I want to take just one minute and give you a quick rundown of my stack. Desen is how I ship design changes without having to code. Framer is how I build my websites. Genway is how I do research. Jitter is how I animate my designs and Play is how I design and prototype mobile apps. Visual Electric is how I generate all of my imagery and Raycast is my shortcut every step of the way. Now I've hand selected these companies to partner with me so that I can do these episodes full time. So the best way by far to support the show is to check them out. You can find the full list at Dive Dot Club Slash Partners. Okay, now on to the rest of the episode. There's a density to this conversation that I so appreciate, but again, I kind of want to, like, double click on things just as a way to really help it take root for people. So, yeah, I want to return to, like, the data model piece specifically. Do you have any tips or mental models or just general advice for someone who maybe hasn't spent that much time thinking about the way that the data model impacts their design process?
- [40:48]
Amar Reshi
Yeah, I think before I do that, I just have a disclaimer which is, it's a privilege to have these problems to design. Like, I interview a lot of people and I look at a lot of portfolios and, you know, obviously I'm not out here asking for Palantir shaped projects because there's a finite number of those. Like, I'm more than happy to look at your, like, design for a calculator app and get to why you made a certain decision and use that to understand whether you're going to be a good candidate for Palantir. Like, that's, that's completely fine. But going back to my point, I think it's just that there really isn't that many of these complex data model issues out there. Like, even if you think about, let's say I'm designing a food app, the concepts are already clear. Like, there's already a lot of stuff that's optimized, like E commerce, like, you know, the gig economy. All of these, all of these applications come with, like, predefined templates and like, you kind of don't really need to like, rebuild from the ground up. The place where this gets novel and interesting is a, in the enterprise, where you're designing something for something crazy bespoke, where it's this industry that has not really encountered technology in its full form yet for whatever reason, there are many of them. Y Combinator is out here trying to get all of them. But I think fundamentally the idea is like, okay, if you're in one of these complex domains or industries, then the data model topic suddenly becomes important. It's like, what are the actual things that the people who use the software think about on a daily basis? Again, I'm sorry to keep talking about the verbs and nouns, but it really is that, like, if you can articulate A, what the nouns or the primitives of your business are, and B, the actions you can take on them in a holistic way that you're already halfway there and then you just need to kind of stack rank them of like, which of these are more important than the other. And like, for example, like as a rider of Uber, I want to ride to my destination. That is like far more important than you know, I want to sit in the Camry and not a Corolla. And so I think like to me creating these narratives or and I like to put it as a sentence, some people don't like to me like if your thing doesn't work as a sentence with like a subject, verb and object, something's wrong with your mental model. I think if you start to do those types of things, you can start to pressure test if you got the concepts right. And I think Apollo is a great example here because it really was a novel platform. Maybe I can do a quick summary of what Apollo is, please. So it is essentially internal tool originally actually, which was used by Balenteer to deploy all of our software to the various disparate environments and deployments landscapes out there. And that includes we have Palantir software running on like the edge, so like a satellite or a drone or a submarine, but also a data center, also the basement of a bank. And there really isn't any software out there that lets you, in a few clicks, manage the deployment of the same package to these 50 disparate locations reliably, securely and predictably. Right. And so I think when we were designing that, that's when we were suddenly reckoning with so many new concepts that had never been like in one place before. That was really interesting from like a design decomposition perspective. And I think I went back to kind of the, the release management one where like I have a Release, let's say iOS for simplicity. Now before, before it actually goes out to the billion users, it goes down. It goes out to like a subset of 100k users and it like sits there for three months in the like release candidate state and then it gets bug fixed and then it gets shipped to prod or production. Now this is a promotion pipeline and your releases are being promoted through this pipeline. And as such, the noun we have now is a release. The verb is like promote or recall. So it's like move up or move down. Now when I recall, it's going to have massive second order effects on many other releases because this release has 50 dependencies, which by the way is a secondary primitive but also a noun. Right. So I'm just out here like underlining the words that are like, you know, the data model versus Just words that are like filler grammar. And so I think if you can start to articulate all of these as actions on objects and the ramifications of each of those actions, you suddenly get like an end to end user story or computer story and you can start to like, then design the interface around that.
- [45:15]
Rid
I feel a little bit of conviction because I'm working on a new project right now and I still haven't nailed down some of the core pieces of language. And so like even talking with engineers, like, I don't know what the core nouns and verbs are, and yet I still have a lot of UI created.
- [45:29]
Amar Reshi
And I will say, by the way, that it's not a linear process. Like it's completely fine to just emit tons of boxes and not be sure about like what goes where and why. And that's, that's, that's kind of, to me, the generative phase. And that's actually one of the things I love to do is just make the wildest vision version first, frankly, without knowing how the technology works in my mind. Speaking of Apollo, actually, ironically, the best Apollo is no Apollo. You should not need a software to shepherd your releases from your computer to the target. The computer should do that. If you define the constraints well enough and don't even think about AI, even just in a pre AI world, if you design your constraints well enough, design these pipelines and these rules and policies, it should just flow and it should just ping you when you're needed. It's like, oh, I tried everything as a machine and now I need human help. And then you get a little notification on your iPhone and maybe you just slack it. And Apollo could just be like a chat interface at that point. But instead it's obviously this massive enterprise app with many tabs and low padding. But I think like, overall that's, that's kind of where I would start. So going back to your project, I think it's, it's totally fine to kind of go from both ends of the spectrum and then like meet in the middle. And that's when these like nouns and verbs start to harden, I guess.
- [46:51]
Rid
You mentioned the hiring piece. I want to touch on that briefly. Like, let's say someone's listening to this, they're inspired, they want to join your team, but they have exactly zero enterprise design background. What would you want to see in their portfolio that would make you confident that they could succeed at Palantir?
- [47:09]
Amar Reshi
Yeah, so this is quite a common scenario, obviously. I think firstly, it's completely fine. Like, I think we Already we get a lot of people who have four projects and one of them is a dashboard and it has some charts and they're like, this is the Ballantia project. It's like, no, I do not. We've got that figured out. Like, we've, we've got dashboards figured out. You know, we don't need the 55th histogram design. Like, we are good. I think what we need is somebody to be able to talk about the data that led to those charts. And what happens if I filter that chart and what happens if I, you know, hover on this thing or if it happens to be a billion rows instead of 100 rows? Or like, how does your table work? Can I group by? Can I sort? So, like, basically, if there isn't that much to work with, I'll go deep and I'll ask like highly specific questions about state machines to understand if they've really thought about the details. Because often I'll just see like a tab with the table. And let's say, let's just use ramp as an example. Beautiful app, has lots of tables, nice ones. And I think like, simply speaking, it's a table. Cool. Doesn't look like much, but there's a lot of nuance in there. You know, there's like certain things they allow, certain things they don't. Some types of sorting and filtering are good, some are not. That's opinion. And I think that type of opinion being built into just a generic table is actually enough to talk about for half an hour, whatever the interview length is, and gives me enough signal on whether you are like thinking thoroughly about the system and b, interrogating the actual data and the structure of the information that's being presented. And it's not just like a UI exercise of like cells and columns and rows. So I just picked the table as a simple example because, you know, there's so many of them. But let's say the designer doesn't even have a desktop app in their portfolio. They just have like some mobile app that's fine too. Like even if it's a calculator app or a weather app, there's so much that you can, you can kind of derive second order complexity questions out of anything. Like even the weather app, if you just keep scrolling, there's like so much more in there. There are 50 ways to show feels like there are so many ways to visualize highs and lows. There's like a visual design angle, there's a typography angle, there is like the systems angle. Of like, which information do I show where there is the usability angle of what you said of do I even care about feels like and wind direction or do I just want to know what if my weather app was just like, wear a sweater today. That's all it said. No temperature, no color, nothing. All it says is just a picture of the outfit I should wear. That's the weather app. And that's a conversation I'm willing to have for half an hour of like, hey, I made this insane weather app at the media Lab at mit. I just assumed that somebody there would make an app like this and I would happily discuss it. You know, I think that's fascinating to have a weather app that's just like gaslighting you into wearing clothes. Anyway, I think I got, I lost track.
- [49:59]
Rid
No, no, it's good, it's good. It's like even some of the action items that I'm kind of taking out of this is maybe there is an opportunity for designers to stand out by proactively getting incredibly deep into one portion of a set of designs in order to demonstrate their ability to communicate that level of specificity and where the micro decisions existed and why. And in doing so, that maybe would speak more to what you were looking for than even the holistic presentation of the entire project.
- [50:34]
Amar Reshi
Yeah, and I would say that that's more out of necessity. Like, just to be clear, like, it would be really nice and ideal if you also had a more holistic platform level project, but the reality is that not every 21 year old is going to a have access to a platform level design problem. And we have worked at that job long enough to have designed it. So I think it's unfair to be to somebody out of school to be like, where is your foundry? You know, why don't you have like six years of ramp ui? So I think to me it's like it's completely fine for you to show us your college portfolio. And if it's not about the details and micro interactions, it could be about the user empathy. I would be more than happy to spend 20 minutes going about, oh, we were trying to design a UI to book classes. You know, every college student has an app that's like, book class. Booking UI for my college because the current one sucks. Cool. Sounds good. I mean, even though this has been built 10,000 times, I'm down to discuss this now. It's not about the fact that it's just like yet another booking ui. It's more about like, what are the nuances that makes this booking UI different from the one at five other universities. And maybe it turns out that there's a certain like, like weirdness in the calendar or like there's a like. For example, I went to RISD our first year. We didn't have any sort of classes. We just had to. They just told us what we would do. We would do these three types of studios the whole year. We don't pick anything. You just show up eight hours a day and come back. Now the class booking UI there is very different from like somebody at Brown up the hill who were just spending half their days in this tiny little calendar app trying to pick the right classes and you know, trade offs and stuff like that. So I think like proximity to users and talking about like their problems and how that reshaped your assumptions is also an equally valid and fun interview conversation.
- [52:32]
Rid
When we first talked, you mentioned spending some time mentoring younger designers at Palantir. Yeah, and you know, we've covered a lot of ground in this episode, so I kind of just want to have like one final catch all. So are there any other ideas or learnings that you're instilling in other designers to help them succeed at Palantir?
- [52:54]
Amar Reshi
Yeah, I mean very practically I manage six designers, so that's, you know, obviously through that I get a lot of FaceTime and one on one time with them. I work directly with two or three of them. So we are actually co designing. We're in the same Figma files, we spend hours together just literally like, you know, doing good old designer stuff. And then the other three or four I would say are in other parts of the org. But obviously I'm like well versed in roughly what they're working on. And so with them it's a slightly different like relationship. About half of it is like Palantir shaped stuff like org navigation, the autonomy piece, you know, like the autonomy is a blessing and a curse. Like if you are the kind of person who's like shy or unsure about asking questions upfront or being uncomfortable in large meetings, maybe that's something to work on. And so it's like, okay, as a designer, you are a first class citizen of this meeting, even though you may sometimes be the only one. And there's like five other technical people saying technical things all the time. And it's very common to only understand like 20 minutes of a one hour call. And that's fine, like it's okay to do that and it's okay to just be like, hey, I literally don't understand half of what you said. But this is my question and these are my problems as the UX designer. Can we work on it together? And you'll find obviously everyone is more than happy and helpful. So I think like a lot of the work is like empowering designers to operate in technical spaces where they may sometimes feel like outliers. I think another piece is. And so that autonomy piece obviously has other angles too, depending on the profile of the designer. But you know, it's like again, asking questions early and often. Like drawing being generative. Like it's better to make 10 things without knowing how it works instead of just versus making one thing after spending one week reading 10 books and 15 documents and internalizing it. Like, we don't want academic PhDs, we want just like doing. And I think creating interfaces, no matter how shitty, is a much better way to get to the truth than to ideate and use words and like, you know, kind of talk to people. Like, 10 meetings is not worth it. And if you are having 10 meetings, take a picture to each of them. Take 10 pictures, show all 10 of them. Let the work speak for itself and only speak when the work is unclear. And I think that creates like that starts to become faster over time. Where it used to take me four designs to get to good, now it takes two. And it's the same idea of how can I short circuit the iteration process because I've been there before. So that's kind of the Palantir specific stuff. And I think there's a lot more that falls out of it that's like, hey, this team operates this way. That team is more structured but operates, blah, blah, blah. And I think those are just tribal knowledge things. But the other thing that I like to focus a lot on, and this is maybe a Palantir thing, I don't know, frankly, I've only had two jobs. But I think the thing we optimize for are generalists, design generalists. So maybe you can call them full stack designers. I don't know. Obviously there is no such thing as a designer who's good at all of those things. You may be a user research person. You may be a creative coder who actually loves the CSS and the JavaScript. You may be like a UX decomp person who just revels in the diagrams and you know, the 0 to 1. Or you may be like a visual craft person who just like playing with the drop shadow for like six hours. Like that's fine. All of these are good things. My job is to like identify those spikes and Let you lean into them while also creating some level of baseline on the other things. And I think that's something I actually derive a lot of enjoyment from. Because it's funny, like, every time a new hire joins or like, somebody, you know, I get a new person. They, they kind of, I asked them that, you know, what, what do you think are your core competencies? And then you watch them, like, evolve and realize, like, the difference between what they thought they were and what they actually were.
- [56:59]
Rid
That's cool.
- [57:00]
Amar Reshi
Or they, they just lean really into the one thing that they knew they were amazing at. Like, I had somebody who was just like, been doing graphic design since he was, like, 8, and you could just tell, like, you know, you can tell when somebody grew up using, like, CorelDRAW. That's a different type of designer than somebody who's like a Figma native, you know, and you can kind of like, start to, like, suss that out. And so we spent more time on, like, typography and just like, you know, I showed him, like, Paul Rand, and I was like, read these books. And then with another person, it was much more about, like, like, dogfooding, the software we actually use and, like, business strategy and like, you know, like, maybe almost like product management Persona. And so for that person, I spend more time talking about, you know, the actual business and how Palantir is, like, organizing itself around, obviously, as, you know, like, the crazy, like, surge we've had in demand and value and what does that mean for the business? And I think it really just depends on their interests and how I can grow them as well. Obviously, I have to, like, balance this against the business needs. That's obviously something that I, you know, it's like, oh, we need X Designer and X Place, cool resourcing game. But that's different from the kind of growth conversation that you asked about.
- [58:14]
Rid
Well, this has been cool. I really appreciate you coming on and you've definitely, like, 10x'd my knowledge of Palantir, and it's really, really interesting the types of problems that you're dealing with there as a designer. Super inspiring stuff and appreciate you taking the time to share it with us today.
- [58:30]
Amar Reshi
Of course. Yeah, I, I, I feel like I definitely just, like, spoke too fast and went through a lot of stuff, but hopefully there was something valuable in there for everyone.
- [58:38]
Rid
There was, it was a very practical episode and exactly what I was hoping for.
- [58:42]
Amar Reshi
So thank you. And I mean, for anybody listening, I think we, we, we love, we love design at Valenter. We really need to have a healthy, strong design org as we enter this like next phase. And yeah, just would love to have tons of new applicants or something, you know, coming up.
- [58:58]
Rid
Well, you can check the show notes and I will include your Twitter careers page, that kind of thing.
- [59:04]
Amar Reshi
Perfect. Perfect. That would be great.