transcribe

Andy Madrick - Why AI changed design handoff forever

Dive Club 🤿 · 52m · transcribed Jun 2026
More from Dive Club 🤿 Business
𝕏 Share ▶ YouTube 📥 PDF 🤖 .md

Transcript

0:00 How is AI changing the way that we collaborate with engineers? I took the directory that this was in in the playground, fed it to an LLM, and said, "Make this work in production." And it one-shotted it and did it like perfectly. It was like >> [music] >> flawless. That engineer, Rob, and I were both like, "This is so sick." I now have the skills, using these tools, to [music] do most of the front end, and then ship PRs that I can get really high-quality reviews from these folks on. What are the best designers doing to own that last mile of craft in code?

0:32 >> These LLMs are not very good at the last mile of design. And that's still like our superpower, needs to be our superpower. Our engineers will bring it all the way like up to 80 to 90%, and then it's up to us as designers to just own the outcome, is what we say here at Notion. And I think we have no excuse anymore to not be responsible for those changes that we want to see. Welcome to Dive Club. My name is Rid, and this is where designers never stop learning.

0:59 This week's episode is with Andy Madrick, who's leading the design of Notion meeting notes. We're going to do a deep dive into his workflow with AI and all of the ways that it's changing what collaboration looks like [music] at Notion. I mean, it's a super practical conversation with a lot of screen sharing, [music] and we're going to start with a behind-the-scenes look at how Andy designed one of Notion's most viewed interfaces. At Notion, we have our Make with Notion conference every year, where we announce certain features. So, the in-product touchpoint for that is always a modal. We announce everything via this big modal that you see on the top left, um that announces, you know, all the features that we that we are excited about this year. And at Notion, I don't know if it's so much a rite of passage, but it's like, "Who wants to build this modal?" And there's a ton of eyeballs on it. Ivan is very involved, which is so cool, cuz like I I started on this a month after I started at Notion, and then I got to work with Ivan like every day. New subs. That's awesome. What does it take to actually go from zero to this modal that is celebrated and that everybody's going to see? We have this modal. Now, this is what we ended up getting to, our final most polished version. We were really excited about it. We thought it had a lot of visual like intrigue, you know, make with Notion. It's really exciting. Ivan was talking with Alan Kay, two heroes of mine, same place. But to get started on this, we just jammed on a lot of different iterations. And for me personally, what was really nice is I was working with a really great PM who's also named Ivan here at Notion. And he was able to kind of triage a lot of this stuff for me and I got to just build.

2:37 So, I started out just creating bunch of different iterations, right? So, I have this guy, but then I have like a million different ones in parallel, jamming on all of them, more or less fidgeting in tandem. Are these mock-ups? Like are you doing this in Figma or are you building So, this is this is all in Figma. So, my workflow is I do a lot of pixel pushing in Figma still. I'm showing you slides right now because I'm a bit of a control freak. And so, when it comes to like crafting things like this, I'm pretty fast in Figma still. I'm actually migrating more and more toward my initial prototypes or my initial explorations being in code.

3:15 But at this point, this was like September of 2025, I'm still doing a lot of Figma. So, I do all these iterations in Figma. And then instead of just sharing like Figma links with a bunch of people, I create this prototype in our prototype playground, which is like a very lightweight version of our Notion code base. Where I I just mock these up in code and now I have a bunch of different versions that I can send out to whoever is interested in seeing this.

3:43 So, it's a lot easier for sharing, right? Like I have this all in one space. It's click-through. I can just send a URL to folks and make them look through [music] this. Never in a million years did I think my design workflow would change so drastically in the last few months. And a big part of it is Paper's new snapshot tool. It's a Chrome extension that lets you copy any component or element from your live website and then paste it directly into Paper as editable layers.

4:10 So, all the time I'll grab something from prod, have Claude immediately spin it up six different ways on Paper's canvas, and then when I'm ready to send a concept back to Claude, it's seamless because Paper's canvas uses real HTML and CSS. That workflow feels a lot like the future of design to me, and you can start doing this [music] today. Just head to dive.club/paper to try it out. People are getting answers from tools like ChatGPT and Perplexity a lot more than they're clicking on Google lately. So, if your site isn't AI-readable, then you're losing visibility that you can't see in your analytics. So, Framer just launched a free AEO tool, which shows you how these AI systems read and understand your website. So, [music] in 10 seconds it can scan your site, score it on AEO readiness, surface what's hurting your visibility. I ran it [music] on the diveclub website, and I only got a 50 out of 100, but thankfully Framer gives me the exact steps that [music] I need to take to fix it. So, definitely take a minute to use Framer's new AEO scanner on your website. You can head to framer.com/aeo to [music] get started. Now, on to the episode. What happened from here is that people start deciding what they like, what they don't. Like, we started to find that this was the motif that we started to gravitate towards, right? We have the nosey faces on the left with some kind of asset on the right. And we're like, "Okay, we're getting close to what we want." So, I go in Figma, refine it a little, and then I go back into our prototype playground, and I create an additional prototype that uses that motif, and then I allow other people to edit this however they want. So, instead of someone giving me feedback on a on a Figma file, I'm able to like allow a certain level of customizability here, and then different folks at Notion are able to go in, click around, you know, change the titles, change the the the number of assets here, change the section headers, whatever, and then they can take screenshots and send it back to me.

6:15 And then we're all like co-designing together, but it it's kind of like uh you know, the home screen on on your iPhone, where you can drag stuff around and drop stuff how you want it to be, but at the end of the day, you're still like on Apple's rails, and you're still like okay, I'm in this world that's a little curated and opinionated. I love this because I was just talking to a designer who is having so much difficulty collaborating with content teams again, because when it was in Figma, somebody could just click and just edit the text. And for a content designer, there's so much value in being able to write within the context of where it would exist, and yet they're doing everything in code now, and so they didn't have this. Really, really cool what you built here. Building this was was really pretty simple. I took the chrome from our sidebar, and I was like, "Hey, we need to make these text inputs that are links to the the content on the screen."

7:05 And I think at the time I was using uh Composer 1.5, or maybe it was Composer 1 at the time, and it handled this no problem. >> Um that's cool. I have not seen something like this before. It makes total sense to me. Oh, cool. Nice. Um so then like we got feedback from Ivan, uh CEO Ivan, and he said, I was jamming with him one day. He's like, "Make it feel like a video game." And he started pulling things around, and we got into Figma, and he's like, "I want the nosey faces to be off the screen like off the modal. Like I want this to feel like I'm playing a video game, and I got like a prize or something like that. and make it really exciting. So then it's like, "Okay, a little bit back to the drawing board."

7:47 But that's that's like the fun part of this, right? We took all these pieces, moved them around a little bit. And then I was thinking about like, "How would I How would I animate this? And what would it look like and feel like?" For me, I'm showing this screenshot because I still like doing a little bit of animation in Figma. I don't do a lot, but like I said, I'm a control freak. I feel like Figma still gives me a little bit of an ability to control things in a deterministic way. So I did a little bit of prototyping in Figma, like very little. I never make click-through prototypes in Figma, but I will make really simple things like this. It's like, "Well, if this face does that, then the text moves like this." And for someone like me who's been using Figma for years, this is a lot of the time can be faster than code. I've been doing front-end for, let's say, 10 years. When I started doing this, Figma was still a lot faster. But now these coding tools are getting so good that like the speed is starting to increase. So like at the time, this is faster for me than Figma. But then I'm I'm starting to sketch out like what this animation should look and feel like. And instead of telling an LLM, I want the nosey face here to move to the this pencil nosey to move to the right and shrink and then fade out and then this will move in. I've had a lot of success sketching key frames, taking screenshots, and just feeding it to an LLM. Mhm. And it rocks. Keep computer vision is so good these days. So I start polishing the UI a little bit here. And it's like, "Okay, we've got a composition we really like." I'm going to get into the nitty-gritty even more.

9:27 I'm going to show like, "Okay, I want the text to move with the nosey faces." And then I'm going to show like, "Okay, this is step one, two, three." And I want it to move in this direction. So again, I'm taking screenshots of this and feeding it to composer. And then I get really, really nitpicky about >> Oh, this is super granular. Yeah, I I mean, like I think with a lot of this motion design stuff, coding tools are so good at executing it, but you have to be very, very descriptive about what you want, otherwise you're going to be fighting these things for like hours. You're going to be pulling your hair out, going in circles. So, for me, it's like a picture's literally worth a thousand words. And so, like I can just do this, make like, okay, here's what Nozi is going to do at the end, it's going to come back over here, and I'm going to label what state this is in. And then, like we we come out the other side, and we actually have something that works in code. This wasn't one shot, it's like you have to refine it over time, but like the animation actually like worked really well. And what was really, really cool is when I when I go and I speak with, you know, our engineers who are working on this, it's like, how do we translate this from simple playground code to production code? All I did was I took the directory that this was in in the playground, fed it to an LLM, and said, "Make this work in production."

10:45 And it one-shotted it and did it like perfectly. The animation was like flawless. Like I like it was so simple that engineer Rob and I were both like, "This is so sick." And then I tell Max, our head of product, about that, he's like, "This is so sick that we can do this, right?" >> I feel like that's kind of the dream setup for so many teams, but you kind of we're still in this phase where everybody has to build it out of the box right now, but like what you just described, where you have like the lightweight prototype playground, I'm assuming it's probably even more than the 80/20 of Notion. Like you really get the front end that you can kind of play with, and then that translation step, like if it's anything even close to a one-shot, like what you just described is it feels like the ideal workflow for teams kind of everywhere. It's really, really cool to see your process even involving the canvas, too, like that full pipeline is neat. It's neat. We have to build our own workflows for each other in these organizations. Giving people the tools to make really strong decisions is the strongest thing for us, right? Like, we as designers, we can do that, right? So, we can we can create these prototypes that give people enough freedom to involve them in the process, but also like relying on our own training as designers to set some rules up the opinion. We ended up actually like we had a hedge, right? And so, we had to build three different versions of this because internally we're like, this new modal variant is really sick, but it could be confusing to people. Why is it a square? Modals aren't usually square. Like, we were worried that it might not convert super well. So, when it came to ship this thing, we had to be like, okay, we need one with three heads. We need one with four heads that doesn't like animate as like interestingly. And then we had, you know, what I call the safe version on the right where it's like, here's our our nosey faces and some kind of video playing on the right. And when it came to ship it, we had static gains for each one and we were watching these really intensely. We shipped all three at the same time. We were seeing which one would convert the best. And I was left to ask you, Rid, what are your guess which one of these converted the most, like the highest? What would be your guess? I really want it to be the one on the left.

12:54 >> [laughter] >> But, I'm nervous that you're going to say the safe one. Well, before I tell you, I want to say like Ivan and then our our head of product, Max, had a bet. And they're like, okay, let's bet like 500 bucks on which one's going to win. And I was like, well, we can't bet money. Let's bet like a gift. And they they both So, Ivan bet on the one that you bet or on the four-head version and Max bet on the three. But, I I hate to say that the safe one did. Yeah, I knew it.

13:18 I knew [laughter] it. I I did I was just like almost dreading the reveal. The the the thing about it the thing about it that my hypothesis Look at the size of the buttons, man. Like one had a huge button, the other had like tiny buttons. So we sweat the details on this for like a month, right? And then it just turns out like it's probably just the size of the button. Could you just made this button bigger, it would But yeah, that's that's that little digression.

13:45 >> Uh that's good. But I appreciate you giving a little behind the scenes of the workflow and it's fun to see the full end-to-end process for a product that I use every day. Like that's always one of my favorite parts of even doing this podcast. You touched a little bit on like showing how you made it so people can like edit the content inside of the modal, that kind of a thing. I'm wondering if maybe there's another layer that we can go into around just given this shift, you know, you talked about how it's a little bit faster to do things on the front end. Now you're moving toward code, maybe starting code more often. How's that changing the way that you are collaborating with team when you can't just, you know, hop into a Figma file and spotlight someone anymore. If I'm working on a really big like reframe, which which we're doing right now at Notion, it's like we're rethinking a really big foundational concept at Notion.

14:40 And I could just go into Figma and redesign every single screen and like get feedback on that. But I found that it's so much faster to just spin up a crude representation of Notion with an LLM that allows people to click around and feel all these new proposals that we're making. So the bigger the feature, the more likely I am to start in code. But if it's a smaller thing, like a modal or polish, visual polish, something like that, I find Figma to still be really helpful. And like personally, I'm logged on Figma because you can just directly manipulate everything with your hand, you know, your mouse. But I still feel like it's an extension of me rather than like feeding an LLM or writing some front-end. And so, if it's a tight feature or visual polish, like I said, I'm going to get into Figma, sketch something out, and then share that with the team. But, like I said, if it's something really big, like we'll just sketch out like having an LLM, sketch out all these different flows, and then we can evaluate and work through those together, essentially. The collaboration part of things, it's more about like and and this is a question that's come up a lot lately. You really have to suss out what the people you're working with, like how they want to work with you.

15:55 And there's no one-size-fits-all answer. If I'm working with an engineer who really doesn't want to work on the front-end, and and this person just is obsessed with doing a deep dive on the back-end making this thing efficient and performant, I now have the skills using these tools to do most of the front-ends, and then ship PRs that I can get really high-quality reviews from these folks on, and kind of share the work in that way, right? Like these titles are kind of breaking down a lot.

16:21 But, if I'm working with a team and they have bandwidth to just fly on the front-end, I can build a crude prototype or even like quick Figma mocks, and then we go in and we can iterate on the code together and like even take screenshots, redline stuff, and then sometimes like the the source of truth is it's kind of like floating up there, and it's more like, "Well, we wanted to, you know, polish this thing. We didn't put it in Figma, but it looks good in code. So, like let's take a screenshot that's our source of truth." And I think you'd be surprised how many Figma files in Notion are just screenshots of the product, and then like a little chunk of it is, you know, a new Figma frame on a little tab.

17:03 So, Yeah, I did my share of screenshotting prod and drawing something over it, but also I'm a bit of a control freak when it comes to a design file, too. So, I was almost always had like this is the source of truth or at least a really good representation of what is in prod and it's neatly organized and I would almost feel this this lack or FOMO when I knew that a piece of the design was not up to date with what is in prod. And now that is just completely went out the window.

17:33 Like there's basically no documentation that lives in the canvas. The only time is like I'll use like the paper Chrome extension to just like copy a component from prod and paste it in. Like yeah, maybe you can kind of get there. But the source of truth is entirely shifted to production code and my canvas is now the messiest that it has ever been in my entire career and it was freaking me out for a little bit but I totally settled into it now. It's like I just don't really care what's in the canvas anymore. That's what everyone says when you're you're applying to a job as a designer.

18:04 It's like, what is the number one skill we look for? Dealing with ambiguity, right? Like how do we live in this world where everything's changing and how the road map might be nebulous and you might be like grasping at different, you know, objectives and things like that and I think to your point, I I honestly want you to teach a lesson on how to use paper cuz I'm following your journey with that. I'm like I feel like I'm in the stone age sometimes, but uh yeah, you just have to be cool with you know, looking at the thing that users are going to actually see and obsessing over that artifact and making sure whatever form of like iteration on that takes, like make sure that is going to be 100% right? And then like Figma and these mocks, they're just reference tools at the end of the day. And so they have to be accessible by your team and they have to know what they're looking at, but I know the answer is it depends, but I want to go a little bit deeper just to understand how often you as someone your job title is just designer, right? You're not a design engineer or anything. Okay, so given that, how often are you actually responsible for some element or some piece of the front-end that is shipping on a given feature.

19:14 Like, is code just a better prototyping tool? Are you owning the front-end at all? Or, you know, how often is it just pure mocks? Like, cuz I'm kind of experiencing that, too, right now, where it feels like every single project has to be completely ad hoc, where I message the engineer and I'm like, "How do you want to work on this one?" Cuz we're all just kind of figuring it out. So, can we get one level more specific in terms of how the concrete deliverables change for you project to project and roughly what the spread is? For the majority of our projects, I would say our engineers take things to 80%. Some will go 100% if there's bandwidth, but I think that what I've found, my personal workflow here at Notion, is I think our engineers will wire thing up everything up, make it very performant, make it actually work, but then it looks like we call it like the T-move version of the product, right? Where it's like it's not 100% there. Yeah. And so, what we can do is parallelize the work, where I could come in and make itty-bitty PRs for just visual polish and finish that last mile, right?

20:23 These LLMs are not very good at the last mile of design. And that's still like our superpower and needs to be our superpower. Our engineers will bring it all the way like up to 80 to 90% and then, you know, working at a company like Notion, where where we are obsessed with craft, taste in delivering a very like well-boxed tool, well-packaged tool, it's up to us as designers to just own the outcome, as we say here at Notion. Like, it's just on us. If it's not going to get done, then someone else someone has to do it, right? And I think we have no excuse anymore to not be responsible for those changes that we want to see. And and at the end of the day, these artifacts are extensions of us. I'm on a tangent now.

21:06 But, like, these digital artifacts are extensions of our work and our practice. And we have the ability now to just own how that gets delivered. So, yeah, the answer to your question is most of the time for me I'm picking up the last 20, or let's say 5 to 20% of the front-end work. And I'm not doing a lot of building features from scratch. I'm not building a lot of wiring things up, but I am doing a lot of animation, a lot of visual design, and just anything that an LLM can be really good at if I'm very descriptive and have the language to tell it what to do. So, is it safe to say then that if your process is going to start in code given something larger where you want to have an LLM to scaffold a bunch of different concepts, all of that is going to be throwaway.

21:57 That's not going to be much of a handoff. At some point you're just going to be like, "Okay, this is what we're going to do." The engineer is going to probably start from scratch, and then you're going to come in again at the end. Does that feel correct, or is there situations where that doesn't apply? I think that's it exactly. But But I I wouldn't say that necessarily that that initial like scaffolding work, the big prototyping that you're doing, like even if it's a massive prototype, I I think like the the classifying that as throwaway work, I don't know, it might be a misnomer because at the end of the day like I don't think I'd want anyone to build the app I use every day just one shotting it with Claude, right? I would want a very thoughtful team of engineers to like do what they do and go to town on it. And then the the work that I put together, it was just a different medium of putting something on canvas. I kind of want to hang out here for a second cuz this is so top of mind for me. I know we're going really deep, but it's so it's challenging. Like I'm experiencing this too. There's just so many different sequencing ideas to play with, and like when do you insert yourself, and what do you own, and who actually ships the thing, and cuz I'm right now like before we jumped on this call, I have a Teemu version of something and I'm doing the exact same thing that you're describing.

23:09 Like I'm probably the last like maybe 15% and I'm owning everything about the front end. I'm going to be the last person that touches this code, too. Like before this goes out the door, I'm the one that's owning every single piece of the UX, how it feels, how it looks, and I love that. That is a little bit more cut and dry for me. Where it gets trickier is, you know, yesterday I'm doing a prototype where I'm going to introduce an entirely new visual primitive that doesn't exist in the code. And I have no idea if it's even going to be good. It's the whole point. I'm prototyping to explore it. I want to send it to people. I want to have them use it, record themselves playing with it, and give me feedback.

23:42 Then it gets a little bit trickier because I can get 80% of that prototype wired up using the production code base perfectly. But then there's like one schema level change and one or two little mutators that have to be added and I don't really want to go down there if I don't have to. I'm just trying to make a quick prototype. So, now I'm making something that is maybe 50% mock data. Feels really enough, but like it's obviously not production ready. But the visuals are pretty good, you know, like the engineer definitely does not want to have to start over on this. And so, now we've kind of flipped the sequencing a little bit where it's like, "Hey, I've built the scaffold. It's good. Can you just get the data layer to work on the back end?" And there's so many different pros and cons and it just keeps changing, but I I don't know how much you're like experimenting with that type of stuff, but it's it's really changes the process depending on when and how you insert yourself when you're playing in code. Selfishly, I'm curious, has that been resolved? Like how do you like working like that? I think it goes back to what you were saying where you almost have to message the engineer, have an understanding of who they are, too, and just like "How do you want to handle this thing, you know?" And I I don't have a good answer yet. I'm I'm actively exploring a lot of things, which is why I kind of seeing what you're thinking about cuz I'll give one other shift that I've noticed in my own practice, and you can tell me if this resonates or sparks other ideas, too. But like, when we are building a smaller feature that the goal is to actually put something out the door, most of the time like if it's just front-end code, like it's it's good, you know? Like we're not It's not hard to make good UI-based code as soon as it touches anything else more strategic is where it gets iffy. I've seen some PRs where the engineer is like, "The fundamental premise of how you built this is wrong. Like why am I looking at a code diff right now? Like the fundamental approach that you took is wrong." And it doesn't matter how many little Claude and Codex reviews you had, this is wrong. So now more of the review is actually shifting to planning mode rather than the code itself. Where I will like go through a planning mode, get an idea of what I want to do, and then I'll just send that as an MD file.

25:52 The engineer will review that. If the plan looks good, he can mostly trust that like this is going to not destroy things, you know? Like everything else is designed at this point. That I I'm starting to do that a little bit more, but this is why I was bringing it up and why I'm talking way more than I normally do cuz it's like I'm really trying to figure this out right now cuz I don't know what to do. We're all in this state where you start talking about this, I'm like, "Give me Give me like give me the pitch." Yeah, [laughter] same. I want to steal these I want to steal these. One thing that I found personally is like what I'm going to tell an LLM to do, that like an agent to do in our production code base, I don't know a lot of the language that I need to use to get it to do the right thing for me, right? Like >> Mhm. I'm just not a software engineer by trade. These like agents can be really good at acting as translation layers. So like I could build something that like just absolutely sucks in production code base, but man, it looks so good. Mhm.

26:51 And then what what I found is like we can do that. And then an engineer can build like the actual feature. And then, instead of throwing away all the work that we did, is like have an agent be like, "Okay, I have this feature. I built it. I'm a designer. It sucks, but but it looks so sick." And then we have a engineer's feature that's like so performant, but it's the team version of this. Can you keep all the functionality of the engineer's version and give it all the styling that I have here. And I think that can get you so much closer than I think like our intuition says it would. Cuz like all of a sudden, like it just is it doesn't have to translate anything. It already has the front-end code. It just has to apply the right values to the right things. And so, like even on the make with notion mode when we did, that was a totally different code base, right? Like notion doesn't use Tailwind or shatsui.

27:49 But the code base I built that in used both. And this was like 6 months ago with I think it was Opus 4.5. It crushed it. It did it in one shot. So like >> That's surprising. I wouldn't have expected that. I mean at the end of the day it's CSS and JavaScript and Opus in particular and Claude in general really really great at front-end. Composer really great at front-end, right? Like And they're only getting better every day. And one of the reasons why I've really enjoyed using Cursor is cuz their harness is incredible. And I just know if I like if I have Composer do a front-end feature, I'm like ultra confident that it's going to do a really good job at that, right? Rather than me hacking in like Claude code and trying to like find my way to the right thing.

28:32 I think there are these tools where you can kind of use them as scaffolds. And like there's a bunch of pre-work that already went in there that I can just kind of steal from and vibe with, essentially. It's the first time somebody has actually said that to me where maybe the harness from Cursor is making front end a little bit easier. So I'm just sitting with it as somebody who yeah, I used cursor 6 months ago, but I I'm still in conductor, which I know you have you've recently abandoned me and my back to cursor. So it's it's hard to keep up today.

29:01 >> [laughter] >> In your conversation with Brian Love, he was very astute and said we cannot get tribal about these tools, right? We just have to use the right tool at the right moment. I'm still driving with conductor every now and then. I think it's an amazing tool, but I think for the past month or so, one of the designers at Notion here was like, "Have you tried cursor 3.0, cursor glass?" I was like, "No, dude. I am a conductor life. Like I'm never going to turn." And then I open up cursor and I'm like, "Holy shit." And like of course like Rio made it. Like the the team over there is just like so good. Composer is such a fun model to jam with. And then, you know, they have work trees, they have multi-agent workflows. Something about cursor that I'm loving these days is plan mode. So I have like whatever model make a plan, creates an MD file, and then it renders it really really beautifully, and it even includes things like mermaid charts and things like that. And I'm like, "Oh, as a visual person, this is a beautiful representation of what you're going to do."

30:06 >> Yeah, that's cool. And it's all in one frame, right? I've got my browser window, my terminal there. If I want to run it in the cloud, I have a VM there, and I can just shut my laptop, go do my thing. I know conductor's working on the same thing. As a designer, seeing cursor just absolutely they're cooking with gas over there. Like really really sick. And I feel like we have beautiful tools to create beautiful tools. And I think that that is like a a feedback loop, and it's always inspiring to see people who are creating these things are so creative and interesting.

30:38 It just adds another layer of inspiration. [music] There's one question that I can't stop asking myself. What if companies applied to talk to you rather than the other way around? And that question is the foundation for the all new Dive Talent Network. [music] And it's working. Like, right now, I'm helping many of the most exciting startups that I know to hire the designers and builders who listen to this show. So, if you're curious what might be out there, and maybe you want to get on my list, or maybe you're even looking for your next design hire, head to dive.club/talent to join today.

31:15 Can we talk about the last mile piece? Maybe the last mile is as big as 20%, which in that case, that's a lot, you know, 20% of the design, really, in the front end. Like, that's a lot. So, I guess I'm kind of curious, when you are prompting, I'm assuming there's some you're actually like getting into the code and writing CSS in Cursor. I would also assume there's still a decent amount of prompting too. So, in the prompting category, how much of this Like, I guess there's like this spectrum, right? On one end of the spectrum is you are creating granular diagrams in Figma to describe exactly what you want, like you were showing with the modal animation. On the other end is allowing for a little bit of wiggle room with AI, where maybe I'm intentionally going to not be as descriptive because I kind of just want to see what comes out. How often are you moving between different parts of that spectrum? How do you think about landing the plane on some of the finer front-end details right now? But, when I started using Conductor, I got really freaked out because I was not looking at code 24/7, right?

32:23 And I think this is part of their mission, right? They want people to not use to like not write code. Cuz I was writing a lot of front-end code before Conductor, and still just working in Cursor and doing, you know, tab complete, all this all these different like manual coding methods. But now like if I'm doing the last let's say 20 to 15% of a feature, I let the LLM build it and I get it to where I want it to be.

32:49 And I'm not trying to fight it and do a bunch of stuff manually while it's working. And then once it gets it to where I want it to be, I just look at a lot of diffs. Okay, what did it do here? What did it do there? And some of the advice that I tell a lot of folks who are asking you about these exact kind of workflows is like your PRs as a designer and not a an engineer who's got all the training of an engineer, your PR should be very very small and manageable.

33:16 If you're not comfortable reviewing the code yourself or writing the code yourself. I think the rule of thumb here is that if you are expecting someone to put more time into reading something like a PR than you put into making it, if there's a mismatch of Yeah, that's good. >> of work being performed, right? And then it goes for like writing docs and stuff, too. I want to finesse the out of this five-line PR. And so then it's so small and easy to ship that I can review it and know like this isn't going to cause problems. And I give it to an engineer, they're like, "Okay, cool.

33:49 Stamp. Boom. Out the door." We have to break the work into like manageable chunks. Like five lines is not very realistic, but a hundred-line PR, that's my general advice of like don't five-code a bunch of stuff and send an engineer a 500-line PR that you didn't even review yourself. Cuz then it's just like an awkward conversation, right? You're like They're like, "Hey, uh what's up with this PR, man?" And it's like, "You tell me, man. I I just kind of like had some fun." Uh this conversation's hitting a little bit too close to home right now.

34:19 >> [laughter] >> No, same for me. I learned these things the hard way, right? Yeah. I'm going to go one level deeper on the beginning part of that answer where you talked about how you kind of just get the initial thing onto the page with the model. How much of your goal with that initial thing is exactly what you were picturing in your mind versus Did you ever kind of just see what happens a little bit? Like is that part of your practice? And And the reason I ask is because I was looking at your models with the animation with the little motion faces. I built something very similar yesterday.

34:53 And it was just for a website little feature card. Not as complex cuz I was able to fade out the edges with a little bit of like a CSS mask. So I kind of got to play on easy mode a bit. But I didn't really actually have that much in my head. I knew I wanted something to cycle through these logos. But I kind of was like I just wanted it to move horizontally and fade out at the edges. And that's it. And I I very intentionally did not give any more intent there because I kind of just wanted to see to see if it would take me a different direction. Is that part of your practice at all? Like do you think that way or is it very much so like I see the thing, let's build the thing.

35:29 That is 1,000% of my process. Like >> I think a year and a half ago when I was at Tone/Lightfield, that was when I first started using Claude as a collaborative partner. And less so like Claude code and like the the front end that it's writing, but just like asking Claude questions about, "Hey, I built this feature. All right, I have it in Figma. What do you think of this?" My favorite thing about working in Notion is you're just surrounded by really creative, super super articulate people.

35:59 But sometimes they're not available. And like last year I was like the only designer, right? So I have to like use these tools in a different way. I love seeing what Claude, which has indexed the entire internet, comes up with and how it evaluates my work. I don't think it's going to like give me spot-on advice every time, but it'll generate a lot of alternate ideas. And like, "Oh my god, I never thought about doing it that way." And then when it comes to your point to about making something wild, like having something surprise you and then be like, "Okay, cool."

36:36 I think one thing that I've really enjoyed is that working at a company like Notion, there's a lot of like one-off components. And we like made this menu its own kind of thing. Like we made a menu item its own menu item style. But our code base has an entire like really robust menu system. What if we just built that? Like and and and I'll just ask Claude. I'm like, "Okay, we need to like remake this menu, for instance. I want to use the design system as much as I can."

37:05 And it'll put things together in a way that I'm like, "Oh my god. Like we had all the pieces here. We were just like using legacy code for so long. And now we have this fresh version of it. We didn't even have to like do anything. Now it's more performant. It looks better. It's more in line with like what we've been jamming on recently." So like all the way from the initial sketching version. And this is I was using like Claude artifacts a lot. Like, "Show me what your version of this chart would look like." And it'll create something with like a million gradients and like a million tags. And it looks like a jelly bean factory, right?

37:38 >> [snorts] >> You're like, "Oh my god." But then, you know, we can you can kind of like trim it down to something that you'd actually be comfortable shipping. I'm totally stealing jelly bean factory. I like that a lot. Like immediately multiple UIs just popped into my head. Then I'm like, "Yes, that's exactly how to describe that." Yeah. Let's talk about this piece then, because I think creating wiggle room for Claude or whatever Codex is only valuable if you're able to push back what you're going to get that is generic, because it can combine things in unique ways, but like it's still going to be generic. It's still going to be boring visually, motion-wise, and kind of almost everything. And so, how do you think about that a little bit? Maybe we could talk to a designer who is potentially slightly earlier in their career where that you know, we used to say like, "Do a bunch of copy work, make every single visual by hand and now it's like well, you don't really do that as often. And so in some ways I think maybe I have some concern that we lose the practice of what makes for great visual design and what allows you to be creating things that are differentiated, show restraint. So, how do you think about the way to consistently push past what AI is going to give you out of the box?

38:47 There is no shortcut to having taste or developing like a high craft high velocity practice. I think that with AI, we have shortcuts to creating a lot of things. But at the end of the day, it comes back to discovering and learning the language of visual design. Through repetitions, understanding like you said that you used the word restraint, which is like the perfect word. We as designers, our job now with limitless UI out there, is how do we take it and make a restrained version of this where form follows function and we're avoiding decoration for decoration's sake. And so I think my boring answer to you is like do a lot of visual design, talk to a lot of people.

39:31 If there's someone you really respect as a designer, ask them about how they developed their eye, about their taste. What are they looking at? What movies are they watching? Like what books like what art books do they like? I think for me in a previous life where I was working in architecture, everyone's portfolio looked exactly the same. It's like hero shot, chunk of text, whatever. And it's because online there's just a bunch of portfolios that you can look at and get inspiration from. And I was like I don't want mine to look like that. And I was at the time I was like taking a painting class in school. And I was looking at a lot of art books. And the way that these art books like represented the work and the way that they chunked up the grid and like the really restrained text that is all about the work, just show the work full bleed.

40:18 And I was able to create something really just by copying. And so, to your point about like we don't like copy a UI pixel for pixel as much anymore, I still tell people that's a worthwhile exercise. It's less so about, you know, doing a static frame pixel for pixel, but like the linear sidebar logic is really interesting because if you minimize the window past a certain point, it'll automatically hide itself. And the window kind of refactors and reflows.

40:46 And then as you expand it back and forth, you see it's really elegant interaction. And so, instead of like remaking that in every instance of itself, how can you like redesign that interaction pattern? And how do you learn from like the easing curve of something? >> That's good. How do you know like what are the break points that they're using? We have like best practices for all this stuff, but I think all the great people, all the great designers are taking like this common knowledge advice and passing it through their filter of ultra taste and like putting something out into the world and like getting into the nitty-gritty and understanding like the keyframes of a certain animation.

41:26 It still is worthwhile to me. I know, I like that a lot, actually. Like recreating interactions. You need the visual design foundation in all worlds, but recreating interactions is one of the best ways to practice. And even as you're talking, it's reminding me like something that I've started paying attention to more is where are the best products not using any interactions? Where are instant transitions applied? Because especially, you know, your mental model where you're talking about, you know, I'm working on these bite-sized PRs, which is you very much so for me, too. Like I basically own every P3 bug, right? It's like when you're just staring at a single P3 bug, it's really easy to just make that thing immaculate, man. Every little detail is so dialed in and perfect and moves and it's gorgeous. But then you you run the risk of zooming out and you realize like every single piece of the interface is overcooked because I've been looking at things in isolation and now I can control all of those interaction details. So I'm That's right. Yeah.

42:23 Where does linear exhibit? Where do they do just instant transitions? Because the pendulum swung almost too far in the opposite direction. I can feel that for myself, you know, I'm sure people listening feel that as well. That's another thing like when I'm looking at or doing like a portfolio review and it's a young designer and it's like it's harder than ever to get a design job these days. And so you've got to stand out. And I see so many portfolios where I'm like, holy like you did so much here. Like you've got an animation here and this button does that and you've got a whole section on this.

42:53 And at the end of the day, the best way to stand out is to show your best work. And to show your best work, like let it speak for itself. The decoration for decoration's sake, no one wants that, right? Like I don't need to see an interactive version photo of you on vacation or something like that. Like just show me what you made last week. And micro animations and animations in general like they're cool 10 words.

43:17 And like you could teach a whole class. Right, there's books written on them. But I think the default is like, what does this thing look like with no decoration? With the same size typeface, with no animations. Take that and say, okay, where can I add a little flourish of delight here? And how does that help the user instead of detract away from what they're trying to do with this thing? I know you have a course where you're thinking about a lot of these things, everything from like the tooling perspective, but also training this visual eye and all of the reps and everything that's put into and everything that goes into that process.

43:48 So before I get to the final couple questions, I'm curious if you could just share a little bit more for people who do want to go deeper. Just who's it's for, what they can expect to get out of it, that kind of thing. So the course is called Craft at Speed, right? And and the whole thing is about like even though there are no shortcuts to becoming a really really strong designer, there are some really high leverage things that you can learn as a designer or PM or an engineer or someone trying to get into tech. There are really high leverage things that you can learn that can train your eye and instantly make something that's like, you know, let's say a 40% on the visual scale to a 80%, right? Just thinking about typography and composition and all these different things. And it's like, there's actually some what I think are objective principles of good design. And I'm trying to just like share the knowledge that I've I've I've gained over the years into that course. And then, when it comes to like learning about these things, the best way to learn them deeply is to actually do them. So, rather than like teach everyone how to use cloud code, it's like I just show what does my workflow look like on a day-to-day basis. It's like a two-pronged course developing a visual understanding and being able to put that into practice, and then using all these skills to actually like create an artifact yourself. And you'll leave the class with a new portfolio website or a no a feature that you want to push to production. And you and I can work on that and jam on that a little bit. And we could talk about these itty-bitty PRs and things like that. And the whole goal is to just build up the foundation of what it means to be a designer today. And being able to ship high-craft tasteful things using cutting-edge leading-edge tools, essentially. And then, you know, I'm there to give a lot of feedback. We work as a class and I try to lead critique sessions. I think a lot of folks who aren't designers, critique is really like kind of intimidating, right?

45:46 >> Totally. So, I just want to set it up where it's like, "Hey, as designers, one of the things that we can do that's going to benefit us the most is working as a jazz band, right? Sharing our work with people, let people take it a certain way, and developing that thick skin so that we can just take the best idea and run with it, no matter where it comes from. And sometimes the brutal truth is like, "Hey, this thing isn't really good yet, but you have the tools and we can help you get there." So, yeah, the course does a little bit of like it's like a crash course on being one of these titleless designers at a company like Notion these days. Speaking of transformation experiences, I want to call back to something that you said to me the last time we talked where you said how uh working at Tome felt like you came out of the other side feeling like a 10x designer. So, I'm curious for your own journey, what was that transformation that happened for you?

46:40 So, Tome uh was the highest of taste product out there on the market. And it was like a slide deck AI generation presentation tool. Um then right when you know, these tools started coming along and it was like an 80-person company. And then when I joined it actually collapsed into like a 12-person company and we pivoted from presentation tools to actually like totally different market of being an AI CRM. And so, we still had, you know, our founders Henry and Keith who were like bleeding edge, high taste individuals and we're building this new tool. And so, for me there like I was the only product designer. We had a really really excellent creative director his name's Alex Cannon.

47:25 And like myself, Alex, and then Henry, one of the co-founders Henry Liriani who his baby was uh Facebook Messenger forever and then he built Tome. It was just us three in a room every day for three hours talking about the work that we were doing. What that did for me is it forced me to be able to articulate why I made the decisions that I made based when I was creating something. I'm in a room like talk talk about like imposter syndrome. It's like I'm in a room with these heavy hitters. Yeah.

47:56 >> And I make something and they're like, did you choose to do that?" I'm like, "Bro, it looked really cool." And they're like, I think Henry's word was it's it's like graphic design theater. Like, you can't do something for the sake of doing. And so, you have to explain the work and you have to like dig into like first principles. Like, why did you do that thing the way you did it? And it made me so much more like it gave me a meta awareness of my process. And so, it's like, well, I want this to look a certain way. Why are you putting everything in a card? Like, uncontain it. Just present the information. Use space instead of lines. All these like very like based level UI tricks that automatically make your work better. But at the end of the day, it's just like the taking away of all these things that we layer on top of our our our work. Cuz I think a lot of the time it's like you're in a room with really great designers. You like you you want to overdesign the problem.

48:50 I think it's like the the midwit chart of like the really great designers just do less, right? And so, I think like just 3 hours a day for a year of just like really intense crits. Sometimes I came out of it, I feel so good. I'm like, like Henry loved my work today. Like, I'm going to go home and I'm going to have a beer and celebrate. Other days, I it'd be like a 5-hour day because I did not I did not I did so bad. I'd be like, "Oh my god." And I'm at the office till like midnight or even like reworking something. So, having those opportunities like critical feedbacks intimidating, scary, putting ourselves out there is vulnerable. Like, but at the end of the day, it is the best possible thing that you can do as a creative in any field, really, to level up your work. Well, maybe as a parting question, I'd love to learn just a little bit more about your experience at Notion cuz I I think you're coming up kind of getting close to a year now. You started working on Notion meeting notes.

49:47 Mhm. And that culture is so incredible, right? Like, I've always looked up to that group of people and the designers and just the quality of product that's come out for years now. So, are you able to reflect on your journey so far and see ways that being in that environment has continued to grow and shape you as a designer? The saying like if you're the smartest person in the room, you're in the wrong room. And I feel like like any room I go to in Notion, I'm like, "Okay, I'm in the right room because that person's here and that person's here."

50:16 And like I I sit right next to one of our design engineers, Colby Miss, and then I got Brian Lovin, you know, two desks away, and then I got all these like just the most like talent dense row over here in the world. And I think that just on a day-to-day basis, the small habits you pick up from other people. Kathy, our designer, is so so good at collaborating with other people, and I watch her and how she brings other people into the process at all times.

50:43 And then like Ken Chen, he's the best designer I've ever met who can look at something that you've been working on for 6 months. You're like, "Ah, it's needed to be perfect, but it's not working." He'll look at you and he'll be like, "Oh, well, that one thing is off. If you do that, the whole thing's going to be good." You're like, "Oh my god. Oh my god." And it's just so nice, but it all starts at the top and Notion and Ivan and Simon, our co-founders, are like Ivan, he freaks me out because not only is he the most tasteful timeless designer at the company, he's also extremely an extremely good engineer. And Simon, our other co-founder, is on constantly on the bleeding edge of using these tools to build different things and things like that. So, I came in here like the first time I interviewed here, I didn't get the job.

51:29 And so the second time I interviewed, I was like, "I'm going to make sure they don't regret this decision, right?" And so I just try to like take everything that I'm learning day-to-day, put it into my workflow. It's such a wonderful place to be because there's always some new thing we're going to build, and we have so many customers that use our product in so many different ways that the possibilities are endless. It's the most ambiguous place I've ever worked because of that. We have such broad range of work, and it's it's just a blast. And doing something hard every day, you go home at night and you're tired, and you're like, "Oh my god, like how am I going to do this again tomorrow?" But like the work is so interesting and fun that you just keep coming back and you just keep chewing on it more and more. Well, I'm grateful that you took the time to come on today and give us a little glimpse into this workflow. It's very clear that you think deeply about this stuff, that you care about it, and so it's just Man, we're in a time right now where it's so helpful to riff and experiment, but then have these moments where we can just kind of like share notes. Hey, what are you doing? What's working? What's, you know? So I really appreciate you kind of bringing your notepad today [music] with us, and it's great hanging in. Thank you. Thank you, Red. This is This is amazing. I'm going to keep stealing ideas from [music] you, so keep them coming.

Summary

AI is significantly transforming collaboration between designers and engineers, particularly in the context of front-end development. Designers are leveraging AI tools to streamline their workflows, allowing them to prototype and refine designs more efficiently while maintaining a high level of craft in the final product.

- AI tools are enabling designers to create high-quality prototypes quickly, often allowing for seamless transitions from design to production.
- Designers at Notion emphasize the importance of owning the "last mile" of design, ensuring that the final product reflects their vision and taste.
- Collaboration is evolving, with designers increasingly working directly in code, which enhances their ability to contribute to the front-end development process.
- The use of AI can help generate multiple design iterations, providing designers with fresh perspectives and ideas that can enhance their work.
- Designers are encouraged to maintain a strong foundation in visual design principles, as AI can assist but cannot replace the need for taste and restraint in design.
- The shift towards using production code as the source of truth is changing how designers document and share their work, often leading to a more flexible and iterative design process.
- Continuous learning and adaptation are crucial, as designers navigate the ambiguity of modern design challenges and collaborate with engineers in new ways.
- The culture at companies like Notion fosters a high level of collaboration and creativity, pushing designers to articulate their decisions and improve their craft through feedback and shared experiences.
© transcribe · For agents Built with care and craft by Gokul Rajaram