Aashman Goghari - Tackling complex design challenges at Palantir

there is an abundance like no shortage of complex problems what are you doing to make sense of that complexity if you're in one of these complex domains or Industries then the data model topic

suddenly becomes important it's fascinating because you truly are having into account for like an almost unprecedented amount of use cases you need to like be able to like Traverse

the 5,000 ft view 30,000 ft view zoom in and out and make sure that the whole thing works but also the details work especially as you're working through deeply technical problems you're

literally buying this expensive powerful Ferrari and you're going to like use it to do Ferrari things welcome to Dive Club my name is red and this is where designers never stop learning for the

longest time I've been super curious about how design works at paler and what it's like working on critical government use cases and designing for these

massive data intensive Enterprise applications so today we get to do a little behind the scenes with Ashman gagari who's one of their design leads we're going to go super deep into

systems thinking and collaborating with backend engineers and handling all these levels of complexity but before we get into all of those details I asked Ashman

to give us a quick lay of the land so that we can better understand what it's like designing at paler it's almost a 20 over 20-year-old company now um started

you know around 2003 in the wake of 9/11 um mostly specifically for like government use cases and I think the idea was essentially that there is a data integration problem as of pretty

much everything like you and I have one of these but think of like banking or something where like 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 benter Gotham which is the initial Flagship platform was born out of that and that was kind of roughly the life of palente 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 inq like cia's kind of benture arm and so there was always that relationship from the outset but then

around maybe like 20145 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 multi-purpose 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 like 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 like that's around when palent 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 dis unstructured disparate information and like make sense real quick message and 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 gets you 2 months free and 10 credits to recruit people just head to dive. club/ genway

that's g n w y just when I thought I understood how powerful raycast is they released their all new AI extensions so you can interact with all kinds of apps

using natural language and you can even connect actions to stram together workflows like in a single command I can start a focus mode change my SL 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/ extensions

okay now on to the episode maybe we could start with your early journey and I actually recently interviewed Omar Rashi who was at paler 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 yeah yeah I think actually mine was pretty interesting actually Amar was one of my interviewers so he 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 um in my first few months I was actually on this team called BD design um 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 product and I think that's one of the interesting things about penter 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 um 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 squel even though I've never really done it um 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 be 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 are maybe I believe 2500 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 swats 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 you know all these like like kind of derived D properties and all sorts of different like ontological Concepts and then apply them suddenly to interfaces and it's like it's just been

six weeks yeah is it pretty common that the new hires would start off embedded on these teams in the the BD platform or is

so that's actually less 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 a 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 CU everyone had their own custom workflows and obviously you need

a designer to like figure out information architecture Concepts hierarchy you know 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 uh Stronger that you don't really need to kind of like send a designer directly to this place and have them build that like end use

app um an example could be let's just say like 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 um but back in the day you would have to kind of figure out exactly the ux go to the factory flooor 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 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 Anthology 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 in 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 like business development team it's fascinating because you truly are having to account

for like an almost unprecedented amount of use cases and to do so with the least amount of software created possible I'm sure it's like one of the the core

challenges of being a designer in this environment I kind of see this internally maybe more as a joke but like it really can be used for anything like 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 like like build something

obviously not nearly as beautiful and usable but still would functionally achieve a lot of the same workflows and we do have you know data pipeline applications that allow you to like view

the lineage of all the data that's like 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 and new units

of software um so I think to your point about like in as little software as possible I actually don't think that's true it's almost like front end is cheap it's it's just this thing that like you

can emit as much of as you need in my world like and this is maybe a bit of a segue now I'm like not speaking for paler as much as just myself but I believe that like like bespoke artisanal

software should be all around us think about like Costco coffee versus like small badge coffee like which one is more valuable than 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 palente 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 readon 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 it's like right back based there's entirely

like multi-step workflows inner Loops outer Loops people are making artifacts in this stuff um people are like collaborating on this stuff there are security concerns so I think like 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 like developer platform and really start drafting these artisanal apps for their org for their companies

on their own with relative e 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

paler started which is more of like the kind of the government contract origin story and now we have Foundry which is like this very 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 correct yeah and I would be remiss if I didn't add Apollo in there it is definitely a smaller zero to

one product right now but I did spend a chunk of time on that as well 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 that we could talk through to understand what it's like to be a

designer in that world yeah yeah I think Foundry I can maybe analogize to like the Adobe Creative speed a little bit where you know there's like seven or eight Marquee apps um 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 Premier expert and Photoshop and illustrator it's like you kind of become like one or two P like one or two workflows become

your your domain so you're like a raster Imaging guy 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 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 onology which is essentially uh kind of an object aware like data model that helps you make sense of the nouns and

verbs in your organization 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 yeah I

think overall My Philosophy on onboarding is that when you're 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 task rabbit or you know something where in between me downloading the app and me getting value on task trab it is like 10 minutes 30 minutes stops you know and it's 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 a racetrack and I think like to

me that allows you to kind of like take more time with the onboarding and add more complexity up front without really um worrying about like walkup usability

in its pure sense that said we are obviously optimizing heavily for walkup usability and from like a strategic standpoint palena has is obviously pivoting away from sending tons of

people to your deployment to help you like 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 trying 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 it or you need to

wrestle with their seite you don't even know who how many other like skeletons there are when you enter an org that you need to maybe deal with before they accept your solution and I think this

has become easier to do now and I think like that is a testament to design I would also Imagine there are instances we have to make decisions that try to

strike this balance between abstraction in the name of some semblance of Simplicity versus preserving like the raw power of the Ferrari yeah can you

talk about that piece of the design puzzle for a second yeah I think I think one tool we use often is like Progressive disclosure in these cases there is some amount of like concealment

of like the final thing where let's say you want to you want to build a streaming data pipeline that requires something to be live like the concept of live liveness is suddenly very important but we don't need to suddenly like just

because you wanted to build a streaming data pipeline of stock data let's say like 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 B 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 like Advanced button or you know go one level down and and then play with it and I think that's one approach which is like slowly disclose what's needed

instead of throwing the kitchen sink at the user's face right um and obviously that's 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 kind of you know 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 WR based

action you know like a big blue button that like 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 like 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 if you happen to be that

like data engineer guy who wants to optimize this pipeline a bit more you might need to see like the spark build profile or like see exactly what kind of computer 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 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 absolutely this firstly this is a good one because a we we call this

internally we say the word decm 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

palente 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 um 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 backin 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 100 different places without you know breaking a sweat now that's a very generic prompt um 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 a or an environment but then there are secondary Concepts like recall where you can recall a release if it's bad or maybe like promotion pipeline this is another one where like you basically are like moving a release

through these stages of like software quality where 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 um often it's just boxes and words we don't really need that many pictures we can

all like 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 SL 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 you kind of need to triangulate between these three

approaches and either being the same room and hash it out or understand the Delta between these and consolidate it um 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 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 like on the spot and screen share or put on the wall and then they look at the Mark or the design and they're like oh actually like we're all talking about subtly different things

and the difference is actually more than subtle when you bring it down to like the 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 like uniting thing that like brings disagreement onto one surface is to me like maybe where the de Gump shines the

most you have a pretty wide spectrum of fidelity levels for what that image could look like yeah so I used to do a lot of like whiteboard sketching literally like on

you know live whiteboards and in meeting rooms and then we got into like remote land um I then briefly spent uh spent time with Concepts uh and on the iPad

amazing app by the way oh yeah that's such a good app so I would screen share my iPad directly in these rooms of like eight 10 folks and just be like drawing

live um 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 like assemble a collage of like roughly what I'm thinking about so in terms of

fidelity I would say it's 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 um which is like hey we put this together using existing components but

that doesn't mean it's like ready to ship 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 yeah yeah and you know this is something it took a little longer for me to learn than I would have preferred word but asking dumb questions early and

often is critical and I think like it's easy to get intimidated especially at palente where there's you know the subject matter is is complex and and the words being thrown around are heavy and

obviously everyone you meet is is very very intelligent and so you 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 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 or chart you're like looking at and that's fine frankly you shouldn't even worry about that it's more just like sus 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 it's good enough it does like 60% of the job and the workflow is clean and it demo is 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 like poke holes in the system and the concepts up front and it's really a game of wacko 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 like be able to like Traverse the 5,000 ft view 30,000 ft 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 Arrow messages that don't make sense 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 sus 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 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 in our case maybe we're a bit fortunate we're not building us an

app that is used by 3 billion people for 1 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 five and they're making

some crazy stuff on it that's like going to 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 BHD person and just

literally bother them and be like why did you click that what is 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 like I'm just like trying to be best friends with this one person and learn you're like an account executive almost at that point exactly

except I only know I only care about the design part and not whether or not they pay us money you know and I think that's that's kind of the interesting part of the the like user side so I think if you

do more of that these priorities become they kind of become clearer through that process you know of like this Edge case was only visible to us internally

because of the the scale of the data we were hosting it's not even a problem for our user cuz they have three environments and we have 200 so maybe let's stop designing for that you know so I think it's like going basically

just seeking the truth really helps like 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 like looking at your design and immediately talking about the three things that are like 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 where 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 designed for those well on that note I have multiple unread emails in my in box 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 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 the destination and really these are kind of the three main Primitives then there are

like sub Primitives like the the number of the G the destination like the estimated time maybe the type of Uber X versus XL 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 subobjects 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 time stamp 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 that is severed again so there's a life cycle 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 where 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 back end or whatever crazy alos 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 like turn on this essentially like security switch which allowed the Rider and the passenger to know a lot of information about each other which is like 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

engineers 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 weight 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 the timeline or the story from the computer and the humans 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 in Uber right you've taken one I've taken one we can empathize with

each other add nauseum 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 diagnostic or available beds or throughput or something and so I think understanding these words Concepts what's going through the users 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 in theana um that's going to change the data density I designed for that's going to change

the like what 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 minology for

example so I think like obviously user empathy is really what it boils down to but I think shoulder surfing being 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 Co 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 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 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 similarish 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 anything that comes to mind in terms of how you've grown over your now almost six years at planer in terms

of like how you Foster those relationships with backend engineers and communicate more effectively so I I never like not ask questions up front 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 D question and ask it and I think that goes a long way just the like format of asking instead of asking it like a like you know an you can

just say it 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 similarish interfaces across various domains across various technical competencies for different users and with slightly different like technical

like power um you kind of 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 statement 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 ashan's Visa to Spain and that's going to live for like 1 month till I get my Visa and it's going to have like states of like okay Visa in process Visa

delivered Vis are waiting whatever and so I think even though these things look the same um once you start breaking down them breaking 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 2 three years in and has been very very useful for me ever since hey it's red I'm constantly asked about my

favorite product so I want to take just one minute and give you a quick rundown of my stack Destin 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 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. club/ Partners okay now on

to the rest of the episode there's a density to this conversation that I so appreciate but again I 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 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 talenter shaped projects cuz 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 paler 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 why combinators 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 really is that like if you can articulate a what the nouns or The Primitives of your business are and be the actions you can take on them in a holistic way that you 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's

like far more important than you know I want to sit in a Camry and not a Corolla and so I think like to me creating these narratives or and I 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 like mental model um 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 cuz it really was a novel platform um maybe I can do a quick summary of what Apollo is please um so it is essentially internal tool

originally actually which was used by banteer to deploy all of our software to the various disparate environments and deployments Landscapes out there and

that includes we have palar 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 a design decomposition perspective and I think I 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 3 months in the like release candidate state and then it gets bug

fixed and then it gets shipped to Broad 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 endtoend user story or computer story and you can start to like then design the interface around that 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 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 um and that's that's actually one of the things I love to do is just like make the wildest Vision version First frankly without knowing

how the technology works like in my mind speaking of Apollo actually ironically the best Apollo is like no Apollo like you should not need a software to shepher your releases from

your computer to the Target the computer should do that like if you define the constraints well enough and don't even think about AI like even just in a pre- aai world if you design your constraints

well enough design these pipelines and these rules and and policies it should just flow and it should just ping you when you're needed it's like oh like 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 like slack it you know and Apollo could just be like a chat interface at that point but instead it's you know obviously this like massive

Enterprise app with like many tabs and 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 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 paler yeah so this is quite a common scenario obviously um 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 is the paler project it's like no I do not we we've got that figured out like we've we've got

dashboards figured out you know we 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 cuz often I'll just see like a tab with a 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 a are like thinking thoroughly about this 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 cuz you know there's 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 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's 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 like usability angle of what you said of like do I even care about feels like and wind direction or do I just

want to know like what if my weather app was just like wear a sweater today like that's all it said like no temperature no color nothing all it says is just a picture of the outfit I should wear like that's a 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 assume that somebody there would make an app like this and 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 any I think I got I lost track no no it's good it's good it's it's 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 up for than even the holistic presentation of the entire project 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 B 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 um so I think I think to me it's like

it's completely fine for you to show 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 a UI to book classes you know every college student has an app that's like book class booking UI

for my college cuz the current one sucks cool sounds good I'm me even though this has been built 10,000 times I'm down to con like discuss this now it's not about the fact that it's just like yet another

like 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 there's a certain certain like like weird in the calendar or like there's a like for example I went to RDI 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 go 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 tradeoffs 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 um interview conversation when we first talked you

mentioned spending some time mentoring younger designers at paler 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 help them succeed at paler yeah I mean

very practically I manage six designers um 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 um 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 paler shaped stuff like org navigation the autonomy piece you know like the autonomy is a blessing in a curse like if you are the kind of person who's like shy or like

unsure about asking questions up front or like you know being uncomfortable in like large like meetings maybe that's that's something to work on and so it's like okay like as a designer you like 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 1 hour

call and that's fine like it's okay to do that and it's okay to just be like hey I literally didn'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 um I think another piece is and so that 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 um like drawing being generative like it's better to make 10 things without knowing how it works

instead of just all versus making one thing after spending one week reading 10 books and 15 documents and internalizing 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 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 like it used to take me like four designs to get to good now it takes two

and it's the same idea of like how how can I like short circuit the iteration process cuz like I've been there before so that's that's kind of the like paler specific stuff and I think there's a lot more that falls out of it that's you

know like hey like this team operates this way that team is more structured but operates blah blah blah and I think those are just like tribal knowledge things but the the other thing that I like to focus a lot on and this is maybe

maybe a paler thing I don't know Frank I've only had two jobs um but I think the thing we optimize for our generalists design generalists so what maybe you can call them full stack

designers I don't know um obviously there is no such thing as a designer who's good at all of those things like you can you may be a user research person you may be like a creative coder

who like actually loves the CSS and the JavaScript you may be like a ux DM person who just Revels in the D the diagrams and you know the zero to one or you may be like a visual craft person

who just like playing with the drop shadow for like 6 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 I actually derive a lot of enjoyment from cuz 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 you know what what what do you think are your core competencies and and then you watch them like evolve and realize like the difference between what they thought they were and what they

actually were that's cool 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 eight and you could just tell like you

know you can tell when somebody's grew up using like Corell draw 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 sus that out and so we spent

more time on like typography and 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 dog

fooding the software we actually use and like business strategy and like you know like maybe almost like product management Persona um and so for that

person I spent more time talking about you know the actual business and how benter like organizing itself around obviously as you know like the crazy

like surge we've had and demand and 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 you have to like balance this against the business

needs that's obviously something that I you know like oh we need X designer in X Place cool resourcing game but that's different from the kind of growth conversation that you asked about well

this has been cool I I really appreciate you coming on and you've definitely like 10x my knowledge of paler 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 with us today 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 there was it was a very practical episode and exactly what I was hoping for so thank you and I mean for anybody listening I think we we we love we love design at valer we really

need to have a healthy strong design org as we enter this like next pH and yeah just would love to have tons of new applicants or something you know coming out well well you can check the show

notes and I will include your Twitter careers page that kind of a thing perfect perfect that would be great

[Music]