Rich (4:13)

It's kind of cool to be able to look back and probably have quite a bit of gratitude for getting laid off because who knows, there's this parallel universe where you're still a software engineer.

Pran (4:21)

I know I always tell people that I'm really glad that I got laid off at the Time, it felt like my world was like crushing down because I was like, what do I do? This is pretty much all I know. And thankfully I had that tidbit of experience, that little chance at GitHub experience, something that I ended up liking a lot more. And I don't know what I would do if I didn't get laid off. At this point, my career has completely changed directions.

Rich (4:45)

Real quick message and then we can jump back into it. Meet Trevor Nielsen. He's been designing products for the last decade plus. But after 14 months, he canceled his midjourney account because he found a tool that he likes even more after listening to this show. And it's called Visual Electric. It's a new image generation tool that's built specifically for designers. It's the most photorealistic one out there, even more than midjourney. They also have a bunch of beautiful predefined styles. And it's so incredibly easy to iterate because the entire experience happens on an infinite canvas. So you'll feel right at home. Honestly, the whole product is the epitome of taste. So the next time that you need imagery for a project, I cannot recommend Visual Electric enough. Head to Dive Club Slash Electric to check it out today. And if you like it as much as I know that you will, you can use the code Dive Club to get your first month for free. My favorite animation tool, Jitter, just had a game changer of a release. They just dropped their first set of community templates created by some of the best designers and studios that I know. And get this, they're all free. You don't even have to download anything because Jitter is like Figma, only for animation design. Just head to their new community page. It's full of incredible animations and when you find one that you love, you can remix it in a single click and make it your own with their intuitive editor if you want to give it a try. Head to Dive Dot Club slash Jitter. That's J I T T E R. Okay, now onto the episode. Let's Talk about the GitHub experience a little bit, because something that you said to me months ago was you said all of GitHub I spent being a sponge. So what's a learning that you were able to soak up during your time there?

Pran (6:33)

Yeah, so specifically when I got hired at GitHub, I honestly felt a little bit confused because I didn't have a lot of experience. Even the portfolio review that I did was all projects that I had done on the side and like random Explorations that I had done, little apps that I had designed at Berkeley, and a lot of the iOS work I did at Facebook is what I showcased as well. So it was very unrelated. But Manuel, who's. He's also now the VP of Design at Vercel, we get to work together again, which is really awesome. He told me that they hire a lot on potential, and I was one of those people who they kind of saw a little bit more potential in, and they kind of wanted to give me a chance. And so when I went there, I was working with a lot of people who were super, super talented. Copilot was, like, just kind of ramping up. There was a lot of, like, small internal projects happening. So I spent a lot of that time just, like, listening to, like, how ideas were formed, how people collaborated in design. And I got to go in person and meet a lot of the designers in the SF office and stuff, too. And so talking about, like, things that are complicated, like the merge queue and, like, CI and like, the infamous pull request experience, like, in person, and learning how designers thought about these things was, like, I think, really critical to helping me, like, now formulate reasoning and, like, how to approach problems. Now based on the patterns that I've seen from, like, really talented people at.

Rich (7:46)

GitHub, I want to try to drill into that hiring process just a little bit. Because you said Manuel hired you based off of potential, which has been kind of a theme that's coming up. Like, I was just talking with Diego, who's the VP of Design at Ramp, and he talked about the importance of hiring for slope over intercept, and everyone has been talking about that through the lens of the hiring manager. Can you talk about what that's like on your end? What do you think that you were able to do to showcase your potential, especially as someone who's still very early in your career as a designer?

Pran (8:15)

I think it's really hard. Like, I. Now that I've been on both sides and now that I've even. I think I would say I Graphite. I had to convince them that I was, like, the right person for the job because, I mean, from their perspective, they have very limited headcount. It's. They're not able to hire, like, a million people to do a million things and give a lot of, like, support to people who are earlier on in their career. So from their perspective, it's, oh, we want to make one really good senior hire and be done with it, because that person can do the task of, like, maybe three, like, younger people putting their head together. But yeah, so I had to kind of convince them and be like, hey, I have a lot of experience in this, in this field, trust me. Like, there was a lot of trust me, I feel like, and like talking to people. And the thing that I learned though, after especially interviewing a lot of people at Graphite, was that you can tell when someone is really passionate about a certain area. And I think that's kind of what got me in the door at GitHub and graphite, I think more so Graphite, where I like really showed that I cared about this specific area. And I like, love developer tools. This specific section of developer tools is really interesting to me. And I think at least the mentality that I would use from their standpoint is I would much rather have someone who cares a lot about something than someone who's maybe more experienced but doesn't have any sort of empathy or connection to the problem that you're solving, because one person's obviously going to give it their all and the other one may log off after five or six or something like that. I think the other thing I'll say too is that it takes a lot of trial and error. Like after I got laid off, I want to say that I talked to like over a hundred startups. I was like talking to founders pretty much like every single day, talking about their product and like showing them some of the work that I had done and kind of describing this exact story of like why I want to do both engineering and design and why it could be a value add. And through that process I learned what I do and do not want out of a company as well. I feel like you have to have a lot of perseverance and know that it's going to take time, especially when you're earlier on in your career, because all it really takes is like one opportunity to get you through the door and help you start sharing your work and like gaining more building your personal brand. It's like pretty much just one opportunity that will get you there. For me, that was GitHub and I think everyone has like their one opportunity that kind of sets the speed of their career.

Rich (10:20)

Were the ways that you were iterating on your own story or the way that you were presenting your work or anything about the review process as you kind of went through those hundred conversations.

Pran (10:31)

One thing I actually tell people is that I actually really enjoy like design recruiting and like interviewing people because it feels so much more natural than something like software engineering recruiting. So like very like historically software engineering recruiting are like These three or four leetcode questions and it kind of is like a crack crapshoot of are you having a good day? Do you happen to be thinking quickly or do you get a question that like, you've seen before or like something like that. So there's so many variables and it's really frustrating to walk out of an engineering interview knowing that you are capable of the job, but you just had an off day or weren't able to get the question right. But for design interviews, it's really obvious when someone likes what they're talking about. And like, whenever I share like the work that I'm doing, it doesn't feel like I'm interviewing. I'm telling someone about the ideas that I have and wanting them to understand it and feel as passionate about it as I do. Whenever I'm presenting the work I do at Vercel, like, whether it's V0 or like the things that I've done, like with Graphite, I just feel like I'm genuinely telling someone about my life, like, rather than pitching myself to them, if that makes sense. And you can really tell the difference between designers who are more pitching themselves and then designers who are just like sharing things that they're interested in.

Rich (11:38)

I mean, it's coming through in this conversation right now. You have an energy and you can tell that you genuinely love what you get to work on every day, which is cool. It's pretty clear you're wearing a heck of a lot of hats. You're the second designer. It's a small team. If you had to highlight an area of that experience where you feel pretty confident. Yeah, I definitely grew as a result of what I had to work on or the type of people that I'm working around. What would you drill into as a way to kind of just tell us a bit more about that part of your journey?

Pran (12:09)

I actually started off at Graphite as a more of a developer relations kind of person. So the exact title of the role I think was Community Engineer. Where it's like a lot of what I was doing was like auditing our docs, talking to customers a lot, like helping develop content for our marketing site and like also just like literally building the product. Like it was an all around role of that required like design, product and engineering. And I started off doing that because it was just what the company needed at the time. But they knew that I was very interested in like design and that was like my bread and butter. So I went into that role being more design oriented and automatically just creating Marketing assets and like shipping features, like, within the product. I remember at the time that I joined, we didn't even have a staging environment. Like, we would literally just YOLO ship things to prod and if they didn't work, we would just take the site down. Like, it happened many times. Like, it was a very scrappy environment. And because of that, I was able to just get my hand into design really early on and help establish, like, brand guidelines of what do our docs look like and different things like that. We also had hackathons every couple of months as well. So, like, participating in those made it really easy to also just flex my design muscle and tell these people, like, hey, this is what I want to do. So I think around three or four months in, I got to officially transition to design and we hired like a real Debrel who could probably do the job much better than I could, but handed off all of that stuff and then I started just like working on our design, like full time and all things related to the CLI and our web app and all that stuff. But I think the one thing that I really took away from doing all of that community work was developing a lot of user empathy. So I think that was early on. I was able to practice creating relationships with our users and getting to a point where I was really comfortable asking people for feedback and during various steps of the process. Because I also think as a person earlier on in their career, feedback is your superpower. You should just be asking for feedback as often and as annoyingly as you can, because it's the only thing that will help you get better.

Rich (14:09)

What did it take to get more comfortable asking for feedback?

Pran (14:12)

It's really hard. I actually think asking for feedback is probably one of the hardest things, because you don't want to feel like you're pestering someone, but sometimes you need feedback to move forward. I think just especially at companies like Vercel, where it might be a little bit more scary to share things just because, you know, everyone around you is so talented. You're like, what if this is bad? What if someone doesn't like it? I think just developing the confidence to be able to just share things out, like, with no expectations. Any feedback is good feedback, regardless of whether it's super critical or, like, really positive. Like, being able to take that feedback and file it away for, like, just this application, but also for all future applications is like, super important. It's all just about taking a leap, I feel like. And just being able to really get comfortable, like putting yourself out There and failing and then trying again and then failing and then trying again. Eventually it'll be right and like, users will really like it. And that's super, super worth it.

Rich (15:03)

All right, let's talk about Vercel a little bit, because on October 5th you tweeted out, I love my job, and I don't expect you to remember exactly what led to that tweet, but can you give us a little bit of context as to what your role at Vercell looks like and what are some of the things that make you love it so much?

Pran (15:20)

Yeah, I think Vercel is super, super unique place because I have a lot of autonomy over what I want to work on. And everyone is super, super self driven and has all of these like, kind of crazy things they're doing on the side and are just super creative. Like jamming with people at Vercel, I think is like an experience that I haven't had anywhere else. Like, the rate at which people are able to generate ideas, especially on the design team, is like, incredible. And there's. You have all these people who just understand the product so well and are also really talented at creating visual delight. And putting that together, I feel like, has been like an insane experience. I like, already was looking at designs that I did, like when I first joined Vercel versus, like now, and they're worlds apart already. So I feel like the rate at which I've been learning at Vercel is like, crazy. And being able to like, just observe the work that the people around me are doing and work with them has been kind of a game changer. That's. It's pretty evident from just like the quality of the people and the work that they post. But everyone here is like, so talented.

Rich (16:20)

You're basically working every day with people that I would imagine a lot of listeners right now probably follow on Twitter like the best front end specialists that I know. So talk to me a little bit about that design and collaboration and what about it is unique at Vercel?

Pran (16:36)

I think what's unique at Vercel, I think that there's a lot of. First of all, I think the bar for quality is just like really high. We want to set a standard in the industry for like, how it should feel to interact with a really high quality dev tool. Everyone cares a lot about the way that something feels like, I'd say more than the average company. And so that just lends itself to producing much higher quality products. And there's all these things that don't go unnoticed, like from the smallest things, the easing on opening a modal or like whether the background is blurred when you open a modal. Like random things that, that generally go unnoticed. Mostly in depth tools products are like super important to engineers and designers at Vercel. Being able to work with people that just care about that stuff is very satisfying, I would say as a designer and helps me, I think further my taste and like figuring out what feels right and what doesn't.

Rich (17:26)

I want to go even deeper on that part because something else that I saw you say was that you wish every designer had the opportunity to work with Chad CN on a project. What's that like? What makes that special to you?

Pran (17:36)

Obviously Shad is like extremely talented. Like he has probably one of the best UI libraries just to exist right now. And everyone's talking about it, everyone uses it. It's just so easy. And working with an engineer who just like understands like design principles and has that taste. There's a lot of things that you just don't have to lay out specifically for them. Like you can focus on the bigger picture and how the whole product feels like and not have to worry about designing all these edge cases because you know that they're just going to understand like how the disabled button state should feel or like random small animations, like things like that. They just have that, that magical touch that like they turn designs that are somewhat lifeless and 2D into something that feels really good in a real product. And there's not much you have to do as a designer to translate that over to them.

Rich (18:19)

It's kind of cool because I think the majority of people listening their experience probably is they have their pixel perfect mock up in Figma that they've like heavily annotated and then the thing that gets shipped is probably like 94% as good. There's that consistent drop off where it sounds like maybe you're actually having the opposite effect.

Pran (18:38)

What's in figma at the end of the day, I feel doesn't matter at all because the only person that's going to see that is you. And maybe like a couple people that are reviewing your designs. Whatever you can do to get your ideas from whether it's Figma or code or whatever to the user as fast as possible. The medium doesn't matter.

Rich (18:54)

I saw a concept that Rano tweeted and it was like these GUI tool tips where it's like really clear. Like something like that can't really be created in figma. But I know that you two kind of collaborated on it can you give us the backstory there. I'm specifically interested in learning about what it's like to bring something to life that exists outside of the box of what you can prototype in Figma. Easily.

Pran (19:14)

He had done some work and he had actually tweeted something out a while ago of what's wrong with the next JS error overlays? What could we be doing better? And I was like, I kind of just pinged him and was like, hey, I have these ideas about the next JS error overlays. What do you think? And I just showed him a quick sketch of a thing that I had done in Figma, a little prototype, and he just brought it to life. We were like going back and forth of what if it felt like this? Or what if it felt like this? And I think dev tools are like, a little tricky because you want them to feel like, immediate. That's not really an area for all this crazy UI or crazy animations or things like that. So there's like, especially in that area, there's like a fine line between something that's really functional and tells you the status of like, your local dev environment versus something that feels really nice and pretty. So we were just kind of going back and forth and I think one thing he said to me that I think also still sticks with me is just try every single idea that you have, even if you know it's going to be bad, just put it down on paper, put it in code, because you, you never know what it feels like until you like, touch it and play around with it, you know, he showed me like, also just like a bunch of like, crazy ideas that he had related to that, like, little error popover.

Rich (20:16)

Can you talk a little bit about what you do once you have the seed of an idea that you're excited about? It sounds like you almost just sent a dm. Can you maybe even just zoom out and talk about that part of your process at a slightly higher level? Like, how do you get engineers at Vercel excited about your ideas and ultimately steward them along this path to get them into prod?

Pran (20:38)

The culture on the design team, I've discovered has been like, there's not really any structure around delivering an idea to anyone. It's just, hey, I ran into this issue yesterday. Here's a quick sketch of something we could do better. Let's talk about it. And it just kind of starts a discussion with anyone who's interested in that particular area. And adversell, each designer kind of has an area that they focus on and so you kind of know who to go to. Like, when I'm talking about the toolbar, I'll go to Skilly and be like, hey, I have this idea for the toolbar. It links really closely, closely with DevTools for next JS. How can we make this work together? And then we talk about it, and we will jam for a certain amount of time, and we both walk away with maybe the direction that we could take that design in. So it's very unstructured. And I think that I wish bigger companies would kind of use that same strategy. I feel like at a bigger company, it's definitely a little bit scarier to share out your idea because it's way more hierarchical. Like, somewhere like Facebook, I can imagine just posting something that I randomly was thinking, because they'll be like, who is this random engineer trying to comment on the product roadmap of Facebook? You know? But, like, working somewhere like Graphite, where I felt like I had an equal stake as everyone made it really comfortable to just share ideas and get feedback. Again, it all comes back to just getting feedback.

Rich (21:50)

What have you learned about getting better feedback as a designer? Because I think there's this spectrum where on one end, you know, you just hit send on a picture and you say, what do you think? And that doesn't always work very well. So talk to me a little bit about that part of your practice.

Pran (22:06)

That's the biggest difference that I've seen between myself and maybe a more senior designer is that I think senior designers are really good about knowing which feedback to ignore or which feedback to table for later or which feedback to address immediately. Like, the prioritization of feedback is so important. But obviously, as a younger designer, you want to make all of your users happy. And I think for the first two or three months that I worked at Graphite, I, like, fell into this trap of every time a user would give us feedback, I would want to immediately make changes and be like, oh, my God, that's a great idea. Let's ship this right now without thinking about the bigger picture. And maybe if that feedback was like, there was an underlying issue and it wasn't exactly what they were laying it out, as you have to be really good at reading in between the lines and knowing when feedback matters. So I think that's one thing at least I feel like I've been improving on. And I think all junior or early career designers tend to struggle with. But I do think that the more feedback you get, the more you can tune yourself to realize what some certain feedback might actually mean if there's an underlying message that, like, a user is maybe upset with a specific feature, but it happens to be like a chain reaction from, like, a much broader user experience that you need to change. But, yeah, that just comes with experience.

Rich (23:20)

All right, let's use this as a way to launch into V0, then. So maybe first, can you give people just a little bit of context? What was the state of V0 when you joined and what were some of the major things that you've been working on over the last last few months of shipping?

Pran (23:34)

I joined V0 around, I want to say, July or June or July. And at that time we kind of knew that we wanted to take a different direction and we knew chat worked really well. People love, like, chatgpt, like anthropic, like all of these really popular chat tools, and we feel like it would unlock a lot more functionality in terms of not only helping you generate beautiful ui, but also helping you answer questions about next JS and all of these things. It just unlocks, like, a new medium of communicating with our users. So we did the big pivot to V0 chat around that time. It was a very fast pivot and it was very exciting. We knew exactly what we wanted to do, and then we redesigned it and then we pivoted in the matter of a month or so. And since then we've just been iterating on that. It's been working really well. We've been seeing a lot of positive feedback, and it unlocked a lot more power in V0. Now we have full stack applications that can be created from scratch, and there's this advent of code kind of thing that's happening right now too. So lots of people are posting really cool generations that I didn't even know were possible with V0. So it's been cool to go through and see all the different ways that people are using V0 and adapt the UI in small ways to benefit certain things. So it's really interesting though. I feel like I hear a lot of people talk about how tough it is to design for AI, because AI is one of those weird spaces where it's like, you don't know if that should be something that you adjust in your system prompt, or if it's a button that you add to the UI and you go through this battle over and over again of do we task this to your LLM or do you add a button for users to opt into this? One challenge that we see constantly is, do we want modes, do we want different modes for V0? Where you're generating a component or you're just chatting with the LLM or you're generating a full stack app, or does the user not really have an idea of what they want to generate when they're going in? There's all of these more existential questions which are harder to answer, I would say, until you really try out the product and you see all of the different applications that users are using it for.

Rich (25:30)

Can you talk to me about some of the experiments that you've been personally running in V0 even just as a way to figure out what's possible? Because I do think a lot of designers listening have heard of V0 maybe from past episodes, and they're like intrigued by what AI can unlock for them as an individual. And yet it's still a little bit murky. So what have you been building or experimenting with that you could use to kind of give people listening a better sense of what's possible?

Pran (25:57)

I actually started like I had a personal goal for myself to learn more Like WebGL, React3 fiber related stuff this year and I've just gotten busy. I haven't been able to invest as much time into it as I wanted. But v0 has actually been super like the one shot generations. And like react3 fiber are amazing. With v0 people have created like some pretty awesome almost next JS comp style websites with v0 which is like, like insane to see. That's crazy. Before tools like this, creating something from scratch like that was very daunting. And a lot of the reason that I feel like people fall off of these courses and stuff super early on is there's so much that you have to know. You have to know things about physics and modeling different things in blender and stuff like that. That's a very steep learning curve. But if you could just get a really good starting product and just prompt V0 to be like, hey, give me like a simulation of this sphere falling on the ground in gravity within React 3 fiber. That alone, having a starting point for that and inspecting the code and learning how it works is so easy instead of just seeing these cookie cutter examples everywhere. So I've been using it a lot for random 3D generations and just understanding how that stuff works. And then in my day to day I just use it all the time when I'm developing locally. I see engineers on our team also using it as a starting point for a lot of their designs. We kind of have a culture of when we want to ship a feature, someone will usually send like a generation of what it looks like in V0 to me. One of our engineers specifically is very good at this. Max will generate it in V0 and be like, hey, I want to ship this feature. Can you design it? So it's just very good. It's like almost this like infinite canvas, but it's in code directly. So you can just like almost ideate with it in a way that. But rather than like Figma, where like you're putting all of your designs in Figma but they don't feel real yet because they're just in Figma, if you ideate with V0 and like all of these are Encode, you can actually reuse a lot of those that code in your actual implementation, which is really nice. So it gets you kind of 50% of the way there while you're still able to easily ideate. And one of the things that we're trying to do better is make it a little bit easier for people to make no code edits to things in v0. So the tools that they'd be used to in Figma, for example, of editing text or stuff like that, it's not worth like an LLM call to be able to make all of those small changes. We're trying to get better at helping people ideate in V0 because right now I think people see it more as like a. I want to create a production app. Like I'm going to go to V0, but I'm going to brainstorm on the side. Like we want people to brainstorm and create apps in v0, because talking to an LLM is actually very useful for those kinds of things. I feel like as well.

Rich (28:27)

When do you ideate in figma vs encode or v0?

Pran (28:31)

I feel like it depends. There are certain things that you just. There are features that you just don't have to think too much about how they're designed or how they feel. V0 is a little bit different, I would say there's only now I feel like a lot of people trying to solve this problem of what's it like to build full stack applications with an LLM as a sidekick, not in your ide in a web app. So there aren't a lot of examples of how to solve this problem out there yet. Figma ideation has been really huge because you want to see how important should the chat be when you're creating an app? Should it be in a popover? Should there be a floating input over the ui? Should the UI be the center of the page? All of these things are really Easy to create components for and then just drag them around in Figma and create side panels for different functionalities and stuff like that. And then when I'm in code, I'm doing more like very small things, polishing up the UI in like, certain areas. I'd say I stick to Figma for broad architectural kind of ideas with v0 of like, how should we organize the chat, where should it be with reference to the UI generations? And then when I'm in code, it's more like very specific to like the current implementation of I'm adding a button here to make someone's life easier. Or I honestly, at the end of the day don't think it really matters that much, like whether I'm in code or in figma. But these days I'd say it has been a little bit easier to get my ideas across in Figma because we're still in a very, like, casting our ideas very wide and like, seeing if there's any, like, newer UI that comes.

Rich (29:53)

To mind when you're sharing out these more broad, sweeping explorations. What have you learned about getting alignment on the higher level? Bigger architectural decisions Internally, you have your.

Pran (30:05)

Working product, like, you have what you're currently working on, what users are actively using, and then you have ideas for like, where you could take that step further. It's always a good exercise to design products in a very futuristic sense and stretch the boundaries of what's possible. So sometimes I'll just have completely crazy ideas. Obviously when I'm sharing with someone, I'm like, hey, I'm going to preface, this is very different from like our current layout, but what if we did that this. And usually that'll spark like a whole conversation of oh my God, that's a really good idea to like, place chat in this specific area or oh, we should be thinking about like the way that users create blocks or like code in chat very differently than we do now. It just like, kind of helps to come up with crazy ideas and reimagine the entire chat every once in a while just to make sure you're on the right path, because you always again, walk away with some takeaways for what you could be like adding to your current experience with any product. I think it's just a helpful exercise to like, just push the bounds of what's possible and maybe design something very different than you have right now in your current experience. It's a good exercise to constantly do not be constrained by what's currently implemented.

Rich (31:08)

It's definitely one of the common themes that I'm hearing come out of this conversation is I'm sure that you have your cycle work and your PRDs that you're working off of or whatever that takes shape as at Vercel. But it does really feel like a lot of future facing exploration. This idea generation is really a core part of the software creation culture there.

Pran (31:30)

Yeah, definitely. But I think also like one caveat is that you still have to ship something to people. Like you can do all these futuristic explorations as much as you want, but you always have to keep in the back of your mind, yes, this is really cool, but how do I get this to users as soon as possible without like completely throwing everyone off? So I do these like kind of futuristic explorations and I kind of challenge people to think about V0 in like a slightly different way than we're currently thinking about it. And then I'll take like nuggets of those explorations and apply them to our current chat and like how we can improve the current experience based on like a small idea from this very futuristic exploration.

Rich (32:04)

Let's go all the way back to the original explorations that you were doing with V0. You're having this transition to more of a chat interface, a pretty big redesign that's a part of that. How did you think about where the V0 product should fit within the existing Vercel design language?

Pran (32:20)

That's a tough question. I feel like with v0 we have this opportunity to capture an audience that's not just Vercel. So like now all of a sudden you're unlocking these people who have never coded before or who want to create an idea and don't know what tool to start with. I think like one of the experiences that I had actually very recently that really made me realize that we're creating something super, super cool. Here is one of my friends is actually a pre med student, so he's very outside of this dev tools tech bubble. And he was creating a recruiting platform for his class and he was like, oh, I need to just create a front end for it. I just need some sort of ui. I'm going to look for this tool. And he happened to stumble across V0. So when we were at this dinner and I was talking to him and he was like, where do you work? And I was like, oh, I work at this tech company. And he was like, which one? And I was like, oh, it's called Vercel, you've probably never heard of it. And he was like, oh, Vercel. That's the One that makes me zero, right? Like I used. I still make this platform for like my. My pre med class. And I was like, that is so cool. So that means that people who wouldn't otherwise discover Vercel are organically discovering V0. So it ends up making a playground for ideas that we could eventually bring to Vercel as well. It's using a lot of the Vercel brand language and a lot of Vercel concepts. But it's almost like this exercise of what if we took Vercel and made it extremely simple and approachable to everyone? Like, what if everyone knew how to deploy apps? And that's basically what V0 is. It's like taking the Vercel brand and giving it to everyone. That's a good example of just taking what you already have, a product that you already have, like Vercel, which is catered towards a very specific person, and then stripping away all the complexity and putting it in front of someone and seeing what they're able to do with it.

Rich (34:00)

What's that been like? Talk to us about how you answer some of those big questions in your visual explorations in Figma and the different opportunities that you've identified where you can push that visual language forward.

Pran (34:13)

It's actually been really interesting because we recently just shipped deploying to Vercel. So like now you can deploy like full Stack apps on v0 to Vercel. And as part of that process, I realized that I was recreating a lot of the flows for deploying to that we have internally for deploying to Vercel. And I was like, rethinking them and I'm like, oh, like we could simplify this so much. Or like it's constantly this exercise of like, how do we recreate like mini Vercel in a way making the deployment process really easy for someone who may otherwise not understand things like deployment failures and stuff like that. Like, how do you make this process very seamless for someone who doesn't understand a lot of the Vercel infrastructure? So that was a really good exercise again of how do we package this deployment experience into a way that's not condescending to a user? Because you don't want to oversimplify something. Web development is inherently complex and that's just the name of the game. You don't want to oversimplify it to the point where users are not able to learn, but you want to progressively disclose how complex something like this can be. Deployments are a good example of that, that we're doing environment variables as well. So as a result of being able to deploy to Vercel, you're able to input environment variables and do a little bit more complex kind of tasks with V0 than other than just creating static pages. And that's something that's just a little bit more complicated. So it's an exercise of, like, how do you explain these things to people in a way that's easy to digest, but it's also not taking away functionality. This is a good segue into that one book that I was telling you about.

Rich (35:43)

I was going to ask you about that. Yeah, yeah.

Pran (35:46)

I think working on DevTools is interesting because. Because a lot of DevTools are just really complicated and have a lot of functionality. A lot of designers, I've noticed, will have this mentality of like, how do we make it as simple as possible? Or how do we remove all of the buttons? Or do we need a button for this? Do we need a button for that? Or do we need an entire UI experience for this? Like, how do we make it more simple? A lot of the times I feel like that's detrimental to the user in many cases, especially with dev tools, because I think you have to embrace the fact that things like this can be really complex and there's a lot of functionality. And like, by hiding a lot of functionality from users, you may be harming their experience rather than benefiting that. So it's like, how do you take something complex and teach users how to use it, rather than make it less complex and then make it harder for them to learn how to use the product in the future because they're not used to seeing all of these controls. So I think that's One thing with V0 that we're kind of trying to strike a balance on of like, how many things do we show to users at the same time? Do we show them the code immediately? Do we give them all this functionality from the get go? Or do we, like, progressively disclose it to them in a way that makes sense? And as they become better at using V0, they start to unlock all these different tools of deploying to Vercel, using environment variables, like all of these small things.

Rich (37:02)

For people listening, the book that you mentioned earlier to me was Living with Complexity. Yeah, it's this kind of where a lot of these ideas overlap.

Pran (37:10)

Yeah. So it's called Living with Complexity. One of the quotes I think that really stuck with me from that book is that he talks about, imagine being a designer of an airplane cockpit and you have all of these buttons Everywhere it looks so foreign to someone who's not a pilot. But obviously for a pilot, having all of those buttons in the places that they are is super important because if you hide a button in the little compartment somewhere because it looks cleaner, could cause the plane to go down. Who knows if it isn't easily accessible? So I kind of use the same mentality for designing products sometimes where it's, yes, simple is really nice and you want to deliver a really clean and minimal experience to users. But at the same time, you shouldn't shy away from complexity. Complexity is not a bad thing. It's okay to have a lot of functionality, it's just how do you package it in a way that makes sense to users. It's not necessarily what looks the cleanest or the simplest, it's what behaves the best. And how do you wrangle complexity to feel like it's simple even if it's not?

Rich (38:03)

I think it makes a lot of sense, especially when you're talking tooling. And even for myself, you know, I have multiple tools where I've kind of one by one accumulated an understanding of all the keyboard shortcuts and the different capabilities. I think where it gets really challenging is now making sure that every once in a while you're purely thinking through things as like, the new user experience. What does it look like to encounter all of these?

Pran (38:26)

For the very first time, we actually had this exercise at Graphite. It was called Onboarding Roulette, where every week we would go through. I don't remember if it was every day might be excessive, but I think every week we would go through and randomly select someone's GitHub username to delete their account. So they would have to go through new user accounts on.

Rich (38:40)

Love that.

Pran (38:42)

And it was so good because you don't realize. I even faced this with B0 too, where it's like starting from the net, new user experience. We don't do that often at all. So it's like always a bit of a jump scare to see your product when it's completely barren and like all of the empty states because you're like, wow, like this is what people are signing into for the first time. And you always want to make that first experience feel really good and very capturing. I really like that exercise and it's actually something that I want to encourage on the V0 team soon. They don't know that I'm surprise, but I feel like it's like really fun practice and it's a really. I would do that at My next company.

Rich (39:17)

So, hey, it's Rid. I'm constantly asked about my favorite products, so I'm gonna 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 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 Dimensions. Okay, now on to the rest of the episode. I want to zoom out for a second because a few days ago you released a new feature that allows users to import Figma designs into V0 for code generation. You know, as someone who's thinking about the space a lot, how do you think this type of power will shape the way that we view the discipline of design moving forward?

Pran (40:24)

I feel like, like initially there was a lot of negative sentiment towards AI and design on Twitter and on all of the platforms. Everyone was like, God, like there's AI is going to be taking our jobs. There's going to be AI doing designs. Like engineers are going to start referencing AI generated designs rather than the designers they have on their teams. There was like kind of all this concern, but I think like the general consensus whenever I talk to people that I work with or just people in this space, like, we all understand it's not that AI is going to replace, replace design as a concept, it's just the way that you design is just going to fundamentally change. And the same way that like design engineers have like incredible taste and craft, like when they're generating something, there's going to be this concept of being able to prompt. Well, like I actually, I sent this tweet to someone like a couple days ago of someone asking or responding to a thread of a really cool V0 generation on Twitter, being like, do you have a guide on like best practices for prompting? And like, how did you become good at V0? That was a crazy line to hear of. Like, how did you become good at V0? It was like again, so clear that we're creating just a different method of communicating with visual design. No, we're not replacing it like, we're creating just like a different way. It's just like a different figma Or a different, like via a different way of communicating with design. And it's just all going to be about like prompting. Well, and then again, having good taste. Like, at the end of the day, nothing can replace having good taste and having good design intuition. Like, no matter how good your LLM is, is. They're just not going to be able to do that. So being able to wield V0 or Claude or whatever platform you're using in a good way with good taste is going to be the game changer.

Rich (41:58)

Even listening to your talk, it reminds me of a few episodes ago I had Meng Tu on and he actually talked about V0 as like the new design tool was what he called it. And so it's really interesting to see some of these explorations and to think of it as an extension of the design practice rather than, you know, another tool for engineers. Basically.

Pran (42:19)

Yeah, you know, it's funny because I'm using both right now. Like I, I design V0 and Figma, but I also do design V0 and V0 as well. There are times where I'm like, I just really wanted a couple ideas for like how to show environment variables in chat. And I went to V0 and I was like, describing the problem to V0. I was like, hey, I'm designing this feature for you. I want to show environment variables in the chat, I want to allow users to edit environment variables. Basically just design the experience of what it's like to add environment variables to a project in V0. And I went to V0 and I asked, I was like, give me a few options for what this would look like. That's like kind of a different flow than starting. It's, it's a little bit more approachable than starting with an infinite canvas. But I go back and forth. Like I, I've come to the point where sometimes I do that, sometimes I go to Figma. But it's interesting hearing that feedback of like V0 becoming the new design tool while also using both and like comparing it. I still think that there's a place for both of them. I think that they both serve a time and place. This is a constant discussion that I have with the team and other people in AI really often the concept of the infinite canvas, I think is still so golden. Having an infinite canvas, of being able to cast your ideas very wide is something that I still somehow want to bring to be zero. Or the same feeling of starting from a frame. What is the equivalent of that in the AI generated code world?

Rich (43:37)

You know, let's talk about the taste and intuition piece really quickly. I think some of it comes with simply immersing yourself in the space and building up this well of context for your users and the problems that you're solving. What are some of the other ways that you think you've been able to grow your own taste and intuition? Especially as someone who has the engineering background and not a traditional design background.

Pran (44:01)

I think as a designer that's earlier in their career, it's just to your advantage to consume as much stuff as possible with as little judgment. Just like consuming media, consuming like different products, using as many products as possible. Anytime I see like a new product, whether or not it pertains to like what I'm working on, I go in, I create an account, I press all the buttons, I like look at all the different features and I take screenshots. I have an entire folder of like screenshots of products and features or random toasts or like modals that popped up. They're like, oh, that's a really nice modal. Let me take a screenshot like for later. I think it's just really important to be hyper aware of what other people are doing and what other products are doing, because that's the only way that you're going to be able to develop the intuition of knowing if things are good and bad. And then also just in your regular practice, like I said, designing every single idea, even if in your head it seems like it's not going to look good. Putting it on paper, putting it in figma, putting it in code and just seeing how it feels is what's going to help you develop that, that knack for knowing if you're right or wrong. Because then you'll start to get to the point, I feel like, where you come up with an idea and you don't have to put it down to know that it's not going to be great, or you don't have to put it down to know that it's going to be good. Like you can go into it knowing exactly what you want to design or like how you want it to feel. But yeah, I mean, I think I'm still learning there. I'm still very much developing my taste and developing my intuition. But the best way that I found to do so is literally just to be a sponge and over consume all of the ideas and products in the space, which has been super helpful. And there's no lack of inspiration, especially when it comes to things like V0 and AI. It's all anyone's talking about right now. That is like using that to your advantage and like being super plugged in and like seeing the way that other people are solving the same problems that you have is very helpful from like an inspiration and a taste building standpoint.

Rich (45:42)

Any other advice for people who are listening, who want to grow their own visual design chops and become a little bit more confident with some of these fundamentals? Because one of the things that immediately I took away from looking at your work was like, how did she get to the point where she had such an understanding of the basics, which I think, you know, you hear the word basics and you think, oh, that's this thing that you like, check the box in your first couple years, but you continuously learn typography, layout, contrast colors. So what have you learned about strengthening that muscle as a designer?

Pran (46:19)

Yeah, I mean, first of all, I think that's, it's a huge compliment coming from you. I feel like I'm still very much learning in this space and like figuring out what looks good and what doesn't. You can't beat like intuition and like your gut. 30% of design is like your actual skill and like your talent and the rest of it is all just intuition and gut. And that might be a hot take, to be honest, but as someone who I feel like has gone through much of my design career through gut and intuition. If you know that you want something to look a certain way because you think it's going to look good, like you'll do anything you can to make that happen, whether it's learning a new tool or putting it in code or whatever it takes to bring that vision to life. That's easy to learn. And if you have the drive and determination to do so, you can. If you want to be really good at honing in the taste and the skill for what you're doing earlier on, I think it's so important to a, just use a lot of products in the space that you care about, go and actively seek people shipping new products, look at other examples and just absorb it all and then share your work really often. I'm still a little bit scared to share my work on Twitter and stuff like that. It's definitely really nerve wracking because it's like throwing your work into a pool of piranhas. Anything can happen, but it's done nothing but good for me. I feel like. And learning how to take the feedback and getting really valuable feedback on things I share is so good. I shared out an exploration that I was doing for the next JS Error overlays On Twitter. I was so scared to post that because I was like, open source community can be really brutal sometimes. Like, people have really strong opinions. These people use like NEXT JS as their bread and butter for a living. So they have thoughts about it and they have a lot of good feedback. But it was all positive. Like, everyone was like, this is like, one of the best error overlays I've seen in my life. Here's some feedback. And it's actually, like, super helpful when figuring out how to orient yourself. But yeah, I think there's a fine line. You should share things out, but you also should be mindful of what feedback you do address and don't. But yeah, I think my biggest two things are literally just consume as much media as possible. Consume as many products as possible. Use as many products as possible. Even if you don't have a practical use for them. Just use them and see how they feel. And then also share your work as much as possible, whether it's in public or in private or whoever. Just tell people about what you're doing. And even explaining what you're working on is like, such a good exercise for figuring out if it's the right thing. Like, when I explain to people what V0 is or how to use V0, it also helps me figure out how are we orienting this product? Who should it be for? And it's like a good exercise like that. I feel like maybe some designers don't do enough and maybe I get that more from, like, my community, like Debrel kind of like experience. But it helps a lot, I think, to orient how you should be designing a product.

Rich (48:54)

Yeah, I think it's one of the hardest things to do. But it is, I mean, it's so important to share your work. And I continually hear about all of the benefits, even beyond feedback, you know, because most people aren't designing a product where there's this, you know, large user base of people ready and willing to give feedback. On Twitter, most people are not in that category. And yet still time and time again, I hear about the benefits of just getting over the hump and building a practice around continually sharing your work.

Pran (49:22)

Yeah, I think there is a big hump to get over. Once you get over that initial timidness of, like, sharing your first thing, I feel like it becomes a little bit easier to share. Then I think once you start to acknowledge all feedback as good feedback and just really become very invested in what you're building, like, sharing just becomes second nature because it's. I really, again, like, I said, I really enjoy talking about these problems and, like, brainstorming with, like, people who may not even be in the space. And in a way that's kind of sharing your work too. Maybe you're not showing someone, like, a design, but you're kind of talking them through your thought process and just coming up with good ideas that, like, I. There's so many times I walk away from a conversation with a friend, too, and I'm like, oh, my God, I need to sketch that up. That's a great idea. Or random things like that, that, for better or for worse, I feel like I'm always thinking about design. Whenever I'm looking at any sort of product, I'm always thinking about it in the context of, like, why do they design it that way? Or retracing the steps of being, like, how do they get to that conclusion? Or, like, why did they put the button there? Or, like, why is this flow the way that it is when it comes to, like, just random apps that I'm using, like, every day? Like, it's just, like, a good muscle to exercise, and, like, you'll just start thinking that way if you, like, I feel, like, care a lot about. About the field and, like, what you're doing.

Rich (50:30)

That hunger to grow definitely comes through in this conversation. So maybe before I let you go, we could look ahead on your learning journey. Are there any growth areas that you've already identified that you want to invest in moving forward?

Pran (50:45)

To be completely transparent, I think the biggest thing that I've been wanting to improve on these days is, like, learning how to prioritize the different avenues of design that I'm doing. So, like I mentioned for B0, we're doing a lot of exploration, we're doing a lot of R and D and figuring out what the right experience is, but we're also improving the core experience and knowing as a designer when to work on what, especially in an environment that's so autonomous, especially for junior designers. I really struggled with this at graphite for the first two to three months, and it was just, how do I prioritize my time? Especially because design is such a creative thing. Like, you just need your focus blocks. You need two to three hours of time to just sit there and drag things around or figure out what something feels like. And interrupting that time is, like, really bad. And so putting all your meetings on the same day, like, something as simple as that, and, like, leaving time to, like, just focus and think and jam is super important, but then also just much more fundamentally, like, what ideas are most worth my time because I feel like I'm at a point where I constantly have all of these ideas and they all feel good and they all feel like high prices priority to me. I'm like, if I could explore, if I could clone myself like three times and like all of us are exploring all the different ideas I have, that would be awesome. But that's just not possible. So it's picking out the ideas that you think are the highest value and then exploring that to the fullest and then sharing that with people is way more valuable than having a hundred ideas explored. Twenty percent, if that makes sense.

Rich (52:08)

Maybe we'll have to schedule a follow up to see how you progressed on that journey. I think it's a battle that everyone listening is probably struggling with as well. I know been in those shoes before and I just want to end by saying thank you for, for coming on. It's been really cool. I've enjoyed following along with your journey over the last few months and I'm excited to see where you take it from here. Thanks for coming on and sharing with us today.

Pran (52:31)

Yeah, thank you. This is really fun.