Full transcript of meaghan-choi-designing-claude-code. Source: https://www.youtube.com/watch?v=jEEbjiC4JE0
Ever wonder what it’s like as the first designer working on a generational product like Claude Code?
I DM’d my manager. I was like, I think this is going to be big. [music] I want to design Moon with Light for this. What does it take to design these types of AI experiences? There’s a huge school of thought that design is all around owning the quality and polish of everything. I think it’s really important to have that, but it doesn’t have to be all of your time. Knowing when to [music] use these tools for execution and offload and knowing when you need to go deep and do the thinky work is a skill [music] set and I think that’s one that I see people doing wrong. How are anthropics new products changing the way that we think [music] about building software? In the same way that it takes a lot to convince a non-engineer to download a CLI tool and need the terminal to be working and yet we’ve seen a lot of people do it now. I think has a similar kind of leap. The way to look at it is it’s an entire paradigm shift [music] in how you work with claude. Welcome to Dive Club. My name is Rid and this is where designers never stop learning. [music] This week’s episode is with Megan Choy, who’s the design lead for Claude Code and is pretty quickly becoming one of my favorite people in the industry to talk to. And it also kind of feels like the way that design operates at Enthropic [music] is consistently a few months ahead of the rest of the industry. So, there’s a lot to learn from in this conversations and a few things that surprised me as well. So, we’re going to dig into her design process, the way that Megan uses artifacts, and all of the ways that the modern shape of designer is evolving. But before we get into that, let’s start at the beginning of Megan’s anthropic journey. So, I joined late 2024. This is back when no one even knew outside of like the core tech industry what anthropic was. Like, everyone was so focused on chat GBT and OpenAI at the time. And Enthropic was primarily an API business. It didn’t really have a consumer arm. was like a clawed app, but it just hadn’t had its takeoff moment yet. And so when I joined, I remember people ask me, “Where are you going?” I’m like, “Oh, I’m going to Anthropic.” They’re like, “What’s what’s that? What’s that? What’s that? [laughter] Never never heard of her.” I was really excited because I spent a lot of my career working on developer platforms and in emerging tech specifically. And I just feel like when you are building in like the tech research area or like new tech, developers are the most innovative and the most critical of everything that you’ll ever build. So you get to see like the real use cases live of what you’re inventing. Maybe about 3 or 4 months into my time at Anthropic, someone had like demoed this like weird CLI pipeline of having Claude edit your code directly. Took like 45 minutes. It was so slow. It required this extraordinarily complex setup of like setting up remote workspace, downloading all these scripts, like doing all this like local dev that was extremely heavy. and then it could kind of sometimes write good code sort of. But I remember seeing I was like, “Holy crap, that’s so cool. I gotta try it.” So I did and I got in touch with the people who were deming it, which was Boris and Adam and Cat and a few other folks internally. They were doing it as an experimental pod. They didn’t have a designer because they’re like, “We don’t need a design on the CLI.” I I DM’d my manager. I was like, “I think this is going to be big. I want to design Moonlight for this.” My manager’s like, “Sure, go ahead. Cool. Go do it.” And that’s kind of how I got started. and it never stopped. I love that the expectation would be like, “Well, we don’t even need a designer. It’s a CLI.” Which I think actually probably would have been my reaction even like a year and a half ago. It wouldn’t have been obvious to me where a designer would slot in. So, where did you slot in? Like what were some of the things that you even were looking for in terms of like the challenges or opportunities that were unique to designing within the terminal. I think there’s actually a lot of design of the terminal that’s like the invisible thinking that goes behind building a product. That’s one that I think I expect and hire for at Anthropic and I think has been the long unsung hero of product designers everywhere is like the mental model, the interaction model, like the base primitives that compose how you think about what you’re interacting with. So there’s a lot of that that goes into it. And then the ultimate form factor of the CLI that made it usable was a chat. So you there was so much to design in that back and forth in between the chats that made it feel more warm, more delightful that communicated the statefulness of it. I have actually designed for CLI before. This wasn’t my first time doing it. That’s why I knew that it would need the help and I was like wow this is going to be fun. Like the challenges and constraints of designing for CLI make it a very innovative space to play actually. Okay, let’s talk about that then because I’m sure there were a ton of evolutions that were happening as you’re getting usage and playing with internally. So help us understand what design looks like at a CLI level. Like what were some of those iterations that you were doing and the role that design played? So I would say some of them are just like how you communicate the tool calling and statuses. Like it’s the exact same kind of design thinking that you would have on a UI except the verticalization of how messages stream. You can’t scroll or jump back in the same way. Like everything scrolls together in a CLI. So as things render in, you have to really think about where it’s loading, how much information that you’re showing. Because you’re serving developers, they have very specific expectations with the CLI actually that you want it to be extraordinarily information dense. Like you would show more in a CLI than you would ever probably show in like a guey, like a graphical interface, because there’s no such thing as progressive disclosure. So it’s just disclosed, especially in the early days when the models weren’t as good. We’re like, “Oh, we got to show people what it’s doing because we’re not sure if it’s going to go off [clears throat] the rails a little bit.” And then keyboard shortcuts are massive. I would say like there are power tools like Figma and other places where they do consider keyboard heavier but like the primary way you interact with a terminal is keyboard shortcuts. I distinctly remember we had this huge debate for a very very long time between myself and some of the engineers about what the shortcut should be for modes. Like if you’ve ever done plan mode or auto mode, what we call it and then what the keyboard shortcut is and if we have to change the UI so that you know what mode you’re in. There was a few iterations there, but the biggest debate was actually the keyboard shortcut to do it because it needed to be fast, but it couldn’t overlap with any existing shortcuts in the terminal, which are many. [music] Real quick message, and then we can jump back into it. So, I’ve been looking at a lot of portfolios through the talent network lately, and many of the best [music] ones all have one thing in common. The designers are using Jitter to bring their work to life with motion, which is by far the easiest way to give your designs that premium feel. And Jitter makes it simple. There are no complex key frames that you get in After Effects or Figma or other features that you don’t need. It’s just a really intuitive product that I’ve been using for years to animate my work and I cannot recommend it enough. You can get started today. Just head to dive.comclub/jitter. I’ve anticipated Desen’s [music] recent release for a full year. It’s called surfaces and it enables you to design and prototype directly on top of an existing production interface. All the pages and flows that you need are preloaded inside of DES [music] as starting points so you can iterate on them with your team, but also run user testing or inspect [music] states or check component properties. No other tool renders your actual product visually in the cloud like this, which is a pretty big deal for Teams. And you can get started today. Just head to dive.club/desen. [music] That’s d ssn. Now on to the episode. You’re building in a space where there’s simultaneously so much muscle memory, but then the core concept of what claude code was was fundamentally novel. Probably even stretched some engineers in the beginning. Like were there mindset shifts that you were designing for in those early days? Like how do you even get people comfortable with what a CLI could do? I think the biggest hurdle to overcome was making it feel like a chat you could go back and forth with. CLI kind of have that where you like print and then it like you send a command, it gives an output, sends a command and gives an output. And so we leaned into that a lot to like anchor the paradigm. But I think the fundamental shift was actually it reading your entire file base and then writing to it as well. And those are like the two big mechanical differences that helped make claude code effective. Like I think the most magical moment that you always see people have with cloud code is when it actually makes an edit for you with the context of everything that it knows about where you’re working already. And you have to remember this is back in the era where everyone was like copying and pasting parts of their files into like a chat and then copying and pasting the output back into their files. And we all knew the pain of that. So seeing it happen in front of you without having to do that is like the moment that people realize like holy crap this is something amazing. Like this is going to change how we work. And so we were optimizing a lot for that first feeling. Actually, the first feeling for me was I remember I was watching Dan Hollik use cla code and he was the one who introduced me to it. I don’t even remember when this been maybe last fall or something like that and you you type Claude and then you get that full screen and you have the giant orange box. That broke my brain a little bit cuz I I had never even my I had no CLI experience at all and seeing that or I’m like immediately whoa what’s happening like where am I? This is very different. I think that was actually probably the most fun thing I ever designed in the Claude experience. The Claude mascot, beloved, fun, incredible, generated by Claude actually, which I think is a really nice touch. I think it’s really important that you feel a little bit of warmth from these tools. You don’t want to be super super detached from them. And also, I think like Claude on its own has a very unique personality that makes it delightful to work with in my opinion. And so, I wanted to really represent that visually. I love AIE art. I think it’s so fun. There was this deep period of NFO files or info files if you remember back in the era of software development where like you would have to download all these you would have to script to download a lot of apps and a lot of them would include these like incredibly artistically drawn asy arts like things that you couldn’t even imagine. And at the time I was like yeah I want to bring this into our app. Like I think this would be really really fun. And we did a ton of exploration with the brand team actually on like all the backgrounds that you see now, like all the animations that you see now to really like make a world that feels like you’re in the computer with Claude. And I think that’s the vibe that we were trying to go for. It reminded me of the old like aim away messages. Did you ever do those where I would do the same thing? I would take the blocks and I would make little scrolling patterns and like art drawings. So it was like this was my little home was just my little dots on my aim away message. Okay, I want to keep drilling into your reality as someone who is designing but isn’t slinging pixels around nearly as much as I have, at least in in previous roles in my career. And another release that stood out to me was this artifacts release where you kind of break it down and you realize, well, okay, the inputs can be anything and the outputs are like completely non-deterministic. What is the role of design in a feature process and and release like that? So give us a little bit of a behind the scenes for Artifacts and what that was like. I think there was a really strong kind of emerging culture of people wanting more than just a transcript as an output, like something sharable, something visual. We’ve like learned a lot over the years that it’s not just like text that people want, but there’s like a ritual visual. You know, we’re all designers, so we understand that. And Claude is really good at coding, like excellent at coding. And so as that is emerging, there was a pattern of folks and I used to do this in my workflow as well of constantly asking Claude to generate HTML files for them because it’s fast, it’s snappy, it gets something like put together. Claus’s really good at making it and then it’s really quick to iterate on top of actually. And if done right, you can also share it which was a big part of it. We would start earlier starting to take screenshots of these files afterwards just like send a HTML file to each other so you could review it. I text HTML files way too much which is crazy. Like it’s crazy that we’re sending each other HTML files. It’s actually insanity. It’s like I didn’t even know you could. I was like I literally asked Cloud I was like I have this HTML file. I was like I just didn’t even think that iMessage supported it. Just like what are you talking about? Drag it into iMessage. And I didn’t hit enter. I’m like no way. I do it all the time. Right. Right. But if you’re sending someone an HTML file, it’s like didn’t we invent the internet? Like why are we why are we [laughter] why are we doing this right now? And maybe like this kind of highlights the workflow. It’s like wow a lot of people were doing it. I was doing it. Can we make this something that’s easier to use? You don’t have to ask cloud to do it. So cloud does it automatically. Oh, what are we doing with it afterwards? actually want to send it to someone or share it with someone. I want it to be live and iterable. So as we were using it, as we build it out, we start to uncover the features that we want out of we’re using it and we build it into a product. We’re like, I most commonly use these for prototypes and when I’m iterating on design. Our data scientists most commonly use it to make dashboards. Our engineers use it to make text specs or to visualize PRs or do research or design docs for the code bases. And then you want to send it to someone. So let’s host these. Let’s make them sharable so that anyone can access them. Oh, I actually want to be able to send an older version but keep working on it. Oh, let’s add version control for these so that you can share and pin a specific version or you can share the latest version so they’re live. So, a lot of the way that we kind of iterate on these is we build for ourselves. We test for the broader adoption and then we add features that we find useful and it ends up being useful for a lot of people or we get feedback from other folks on what is useful to them and we build it in and we end up with a product. And the interesting part of that is some people might not consider it traditionally design, but I do like what is the shape of this. It wasn’t called artifacts to begin with. We weren’t even sure what it would be. Like we were just sending HTML things. We didn’t really care about the name or the packaging at the beginning. We cared about the workflow. And the deeper we went into it, the deeper we’re like, how do we fit this into someone’s mental model? So it’s not something that they have to learn. It’s just something they get or have or is it important for people to learn what it is so they know how to use it? And those workflows are really where the design comes in. The UI part of itself is extremely simple because in my goal, we’re trying not to invent new UI. We want it to feel so natural that it just becomes intrinsically part of your workflow. There’s a designer here on the cloud code team whose manure is excellent. He’s like, we’re designing tools for people to get work done. The moment you notice the tool is the moment we failed. Like it should be totally out of your way. And I think that’s a great way to design productivity tools. Let’s help people imagine how they could use artifacts. So, can you talk a little bit about you mentioned sharing prototypes, what’s that workflow look like for you? what are you trying to accomplish? So, I’d say like a standard way I would use artifacts is I’ll get a feature request from a team for like some design support and as opposed to me doing any design work, I’ll just get Claude to generate an artifact or I’ll ask them to generate an artifact of what they should be or sometimes I’ll just tell them to use cloud design to generate that as well and then to send it to me and I’ll review it and then I will get my cloud to iterate on that artifact if it needs any feedback or I’ll DM them the feedback directly and then we kind of have a live version of like where we started. and where we’re trying to go. And then Claude can actually ship that final version. And because it’s baked into your codebase, once it feels mid-fidelity, I actually ask Claude to build it based off of our actual components. And so it no longer becomes just an HTML artifact, but a sharable prototype that then we check into the repository as well. And so it like grows as we get more sophisticated in a feature that then eventually becomes a pull request. Is there like a fidelity cap on what like you know is it an approximation of what you’re trying to build? Is that like the ceiling where it’s more useful early stage or like I’m trying to figure out exactly how that would fit into I’m actually trying to ship something. I think the benefit of it being in an HTML artifact is that it’s so fast to iterate on and when you’re in the early stages, you really want to get those iteration loops in. And then once you have the right shape of it, I think it’s easy to switch from an artifact because Claude is aware of it into a PR. That’s kind of the transition I go for. So we’re going from like early ideation and feedback to a decision. Make it a PR so that you can just ship it when you feel like it’s ready. The way that I would send Figma files, like it just didn’t really work. like if I’m trying to send it to like an exec member, I could never get them to go into the canvas or anything like that. But now I’m like I could have created it’s not even a prototype. It’s almost like an interactive report that includes a prototype. Exactly. I’m like, man, could you even build different ways for them to like express what they like or different intent pieces and then capture all of that? like it’s kind of exploding what I think about this workflow in terms of the designer’s job of visualizing ideas, [snorts] sourcing opinions and and uh ideas from the rest of the team and then like tightening that loop as much as possible. I can see how this would be a big big tool. It’s almost like a mini micro site and decision log in itself. Like often I will ask Claude to actually pull the data or pull any research I have from like our bitquery, Slack, any docs that we have on this and like summarize it at the top and then put a goal that we’re trying to accomplish. Turn out like three to four versions of the design. If it’s more complex, I’ll ask it to break out actually the different work streams that we need to work on and then proposals for there. And then I will ask it for it. The interesting thing is I often have multiple artifacts in one of these. Like I’ll have an overview one and then I’ll have side ones for all the iterations on the overview one I want to do and then I tell it to send it all back to the main artifact and that main art. Are they separate links or is it like a table of contents almost? They’re separate links but they can link to each other if you ask cloud. And so I’ll ask Cloud like, “Hey, like I want to do a deep dive on like the entry point. Let’s say let’s like prototype five different entry points. I like option A.” Mark that I chose option A and leave a link there to the old artifact. So if anyone’s curious that I did the exploration, they can like see the decision. Wa dang, that’s [clears throat] crazy. This is like a whole set of design challenges in itself in terms of just thinking about the artifact journey that you want to create for people. And I think the beautiful thing about artifacts and probably the challenging part of it is that it’s so open-ended like because it’s truly anything. It can be anything that you want it to be. My brain’s racing right now. I’m like I’m like I’m like 80% having this conversation and then 20% thinking about what I’m going to do right afterwards because something I was doing literally last night was I am building on top of the GitHub API and it’s little I know maybe a good chunk of the metadata that I would be able to have available from that but there’s so much that I don’t know too. So I just sent Claude I was like go do a research report effectively and given this set of goals what is all of the re relevant metadata that I should consider using but I didn’t want that as a block of text. So I had it make it into HTML and then I had it build like each piece of metadata as a multi select so I could just click and then get like um okay like you know these are the seven things that I’ve selected and can feed that back as context into cloud. What I really wanted to do was to send that to two other people and be like, go through and let me know which pieces of metadata speak to you, like what would be the most compelling thing that you would want to see on a user profile. And then to be able to like compare the results and then have like a version history within that and yeah, very limiting when you’re doing like the standalone HTML, but I did that wrong. Like I should have [laughter] been using artifacts for this. Yeah. And it makes them just like infinitely more capable and sharable. I think the sharing is really the big part and like we’re going to layer more on top of it. We’re like so early in this journey and a lot more is coming. So you can just imagine all the things that you really feel like you want to do, we also feel like we want to do and it’s kind of there. Like we’re thinking about it. That’s the smirk of somebody who already has the next version built, but definitely cannot talk about it yet. Yeah, it’s exciting. I I really like it. You know, I never thought we’d go back to HTML as like the main form factor for code and the main framework we use, but it’s pretty powerful. It’s pretty great. Speed means [music] a lot. 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 and [music] 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 club/talent to join today. Okay. So, we talked about like the social layer of artifacts a little bit, but I’m assuming there’s more on the bone in terms of how [music] you work specifically in the ways that you’re collaborating with the models. You’ve been there, I mean like a year and a half. We were joking before this about how it feels like we’re aging in dog years. So, like a year and a half worth of reps brainstorming with Claude is almost an eternity at this point. And so when you’re working on maybe early stage more ambiguous meaty problem spaces, what are some of the ways that you’ve evolved how you collaborate with the models? Man, I am like constantly having both existential personal kind of big brain thinky discussions with my claud and then also very tactical execution work. And the beauty of how we now work here is that it’s all together. So I don’t really have to code switch in between those two which is I think our old way of working. It’s all kind of built in together and I have like one clawed channel that’s like my regurgitated brain in Slack. I actually do it all in Slack. It’s crazy. It might be like a crazy workflow but most of my work Slack. Yeah. Yeah. I didn’t see that coming. [clears throat] Yeah. If you see the claw tag launch and I think this is like a big one that uh we can chat about a little bit more. A lot of my both thinking and execution work is all done there and I’m generating so much ideas and I’m going back and forth with cloud at a high level and a lower level of execution. Okay, pause. Let’s talk about cloud tag then because I did not expect you to be interfacing predominantly in Slack. So give us a little bit of context for what the heck that is. I remember seeing it on Twitter, but it didn’t immediately like it was clear that it killed a bunch of startups, but it wasn’t immediately clear what it unlocked. So why is that a big deal? and and why do you think that designers going to be using that more? Yeah. So, I think Claude TEG is a really hard concept to wrap your head around transparently. Like, we had a lot of challenges internally and we’re still trying to work through exactly how to explain it to people cuz it’s one of those products somewhat similarly to Claude Code that I think you have to use in order to really feel, but it takes a little bit of hurdle to get to a point of making it useful. In the same way that it takes a lot to convince a non-engineer to download a CLI tool and being the terminal to be working and yet we’ve seen a lot of people do it now. I think claude tag has a similar kind of leap. The way to look at it is it’s an entire paradigm shift in how you work with claude. So today you’re working with claude as a tool. You’re giving it direction and then it’s following that direction giving you a feedback. It’s like in and out in and out in and out. And it’s all single player. It’s all just you and it’s all very session based. like you spin up one claw, you spin up another cloud, they’re kind of separate from each other. Yes, there is like empty files, but it’s a little bit like it still feels like everything’s quite separated. And as you mentioned, sharing is a problem. What claude tag introduces is you’re not working with a bunch of different clouds. You’re working with claude, a single cla actually. And not just you working with a single claude, but everyone in your organization is working with that claude. Man, how do I describe this? I think it’s hard because like the human mind is limited to like what we can comprehend, but this is like a claw that works differently than a human. Like you got kind of got to let yourself take that leap and realize like oh claw can have thousands of simultaneous conversations while you as a human can probably have four or five. And so it’s having those thousands of simultaneous conversations and it’s all operating on a shared or knowledge and a shared memory layer. It also has access to its own set of tools as opposed to being limited to your own user MCPs. your organization can give cloud its own credentials so that it can have its own GitHub access, its own like Google access, its own like asauna access and so it can take actions as it needs to be configured as a member of your organization. And so what that looks like is as I’m working with claude on one feature, it will pull in all the knowledge of all the engineers working on it in a different channel or in a different documentation or in a different codebase. all the PMs that go to market, like all the other pieces that are organizationally happening, it knows about, but it also knows that I’m working on the design side of it. So, when we’re riffing together, it’s giving me feedback and direction on what design could look like and how it relates to all the other pieces that are going on in the organization as well without need me needing to be in like 30 different meetings for it to happen. I just like hold all this in my head like Claude’s holding it in my head for me. And it’s so proactive as well in a way that our existing Clouds are. it like runs infinitely for everyone. And so as updates are happening in other channels, sometimes I’m talking it’s like, “Oh, hey, so and so just made a decision here about something you were asking about. This is how you can update your thinking or this is something that you should talk to them about [clears throat] because it’s slightly different from how you see it.” And so it just like makes it so much faster to have these like big discussions. And then on the ship side of things, because it’s so proactive, because it’s so integrated, a lot of my PRs are written actually through Slack right now. Is that a crazy thing to say? That’s crazy. Yeah. I [laughter] didn’t crazy thing to say. I can actually share I put together like some screenshots of what it looks like like some examples that I copied and pasted with a little bit of redacting into what some of my conversations with tag look like. We had a lot of discussion on this because it is a new mental model. We don’t want you to think that this cloud which is user segmented is the same as like this organizational cloud because it’s so open like there’s a little bit there. Like we want people to shift how they’re thinking about how they work with this cloud. The crazy part is we use cloud tag to build cloud tag so it’s very meta. Like I was using claude tag to update cloud tag and it was it’s aware that it’s cla tag. I’ve had some crazy conversations with cloud where I’m like do you know your cloud like what do you think this should be because you are cla tag [laughter] and then it’ll go through the crazy it’ll go through its transcripts of like anthropic or ants that’s what we call ourselves using cloud tag and be like oh like this is what I think it should be because this is all the feedback I’m getting in the feedback channel about myself that it’s managing. Dang, that’s trippy. It’s so crazy. But this is an example of me. I have a Megan Claude channel. I keep it open because one really beautiful thing about this is actually you learn a lot from seeing how other people are working with our clouds. Sometimes I’ll say like, “Hey Claude, did you see what Boris was doing in his channel? I want that. Give me the exact same thing for everything.” So, it’s like very social in that way. I know there’s a lot of challenges of like sharing skills and workflows. This is one where you can literally just say you can see someone else’s workflow and be like, “I want it.” And because Claude did that workflow there, it already knows it. It’s it’ll just bring it to you. You just have to ask it to do it. Yeah. You’re not even like pasting a screenshot or anything. You can literally just reference any other conversation. Yeah, I’ll copy and paste the like DM link or the like open link. It’ll be like, I want this. Can you do this for me, please? Dang, that’s cool. So, this is a message I sent to Claude. This is an example of like some of the nitty-gritty UI details that I want fixed that I now just have Claude do. So, I was like, hey, there was a drop shadow there. There wasn’t meant to be one. Remove it. Right. Super easy fix. Claude on it finding because it has access to our repositories. It’s finding the page and the styling. It removed it for me, pushed a new branch, opened a PR, post a screenshot to the PR. That’s something that I have a preference to. So I ask Claude, whenever you’re making UI changes, put a screenshot in the PR so I can see it. One thing I also did, this is something special about Claude Tag is it also learns about you over time. So what you’re seeing in here is actually an iteration of me working with Claude and the preferences I have, which is always draft a PR, but make it a draft PR, not an open PR, so it doesn’t trigger CI. And then always put a screenshot of the before and after in the PR description so that I can see what it looks like before I open it. So Claude generated this PR for me. I clicked the link. I was like, “Yeah, it looks good. Now open the PR and merge it.” And then the crazy part is it made sure CI was passing. It posted in the stamp channel to get a review from my engineers. And then it told me when it was merged. So after me sending the DM, reviewing the output, I didn’t do anything else. It was done. It was all done for me. What the heck? It’s [laughter] crazy. What percentage of code that you were shipping is just happening like this right now? And is there like a trend? This is obviously like a very low-level visual change. That makes sense to me. Like give me a lay of the land a little bit in terms of just how big a part of your workflow this is. I would say more than half of my code is done like this now. What the heck? And it’s it’s not like this is I think the simplest example of it. Sometimes I’m doing like full overhauls. Like I have one and this is me directing it. I have some that are just automatically running right now. So, for example, I have a job that does cleanup that like every Monday it’ll just show me cleanup and then it’ll spin up a bunch of PRs for me like that and I’ll just review the before and afters and then I’ll just try and merge them. Like this example, I think it’s even not as forward-looking because I had to ask Claude to do the design change, but very often Claude is proposing based off of work that has merged in the past for me or work that is forward-looking or discussions that are happening in Slack between people at Anthropic about what the UX should be. I’ll have Cloud signal those to me and then I’ll look into them and then Cloud will typically generate a PR for like proposals for what it could be. And it’s not just PRs. I can show some other workflows. So this is another one where uh it needed a little bit bigger of an overhaul and so I was like, “Oh, like you need let’s clean up this page.” There’s a bunch of different states here. We had an advanced section. I wasn’t sure what it should be. I had a Figma link of what we were brainstorming different architects of it. So I just linked it to Figma. Quick, give us a little bit of context on that Figma link. far are you actually going in Figma right now? Um, this one was mostly around like ordering stuff around. I went through like four or five different orders of like should these configs be in this order and it’s faster for me personally to do it in Figma. I think the designers internally actually we debate about this sometimes because some people still use Figma and we all use it at different stages, some people don’t use it at all. For me, I use it when I know I’m faster like when the iteration I know I want to do, I’ll be faster doing it with like auto layout and stuff in Figma. That’s a speed thing for when now are you faster in Figma? Like go a little bit deeper there. Uh well, for this one specifically, there’s like we had like 30 different settings and I wanted to know if it would look better collapsed and what order they should all be and what hierarchy they should be. And with auto layout, it’s really easy to move things around actually myself. And so I put up three versions of this Figma link actually. And I had one that highlighted as like recommended. Part of the reason I also was in Figma for this one is because we didn’t have anything like advanced and so I wanted to have a reference for Claude to know what the advanced pattern would look like because it’s a new one that we’re introducing. Sure. Very simple though. So it added a collapsible advance section. It’s making all these changes on how everything works. It’s putting up a draft PR. I like really trust cloud at this point. I actually kind of wait until it’s done. It put up a before and after for me. So, I clicked into it and then the really interesting part that I love is that there was some gaps in my design. So, it made a call. Like, it made a design call on its own. It’s like, “Hey, I made a decision because your designs didn’t include it. And I think it’s better.” Actually, it says like, “If you want me to match the mockup, I’ll do it, but I think my call was better.” And it was right. It was like so right. I was like, “Oh, wow.” That’s happened to me a few times in the last week where it says, “One call I made. I saw this discrepancy. It felt like you were pushing me this way, but if we went this way, I think it’d be better for XYZ reasons.” and I read it and I’m just like damn [clears throat] right it’s it’s right [laughter] so imagine claude doing that not just with the knowledge of your design patterns but with all the decisions that are making on the architecture of how things work and all the product and go to market decisions that happening for example I was doing this at one point and the team had decided to rename a feature and it just like oh by the way everyone decided to rename this so just as a heads up I’m going to update the copy here as well I was like wow thank you oh man that’s so cool that’s so cool and then I looked at it I was like hey like should we pull out this specific ific setting because I think it might be important to pull out. So these are like the kind of discussions I have with clouds like do you think I should do this? I actually don’t know. I’m asking to figure it out and it has an answer for me why because it’s one of the most touched controls. So it’s pulling from our data and it’s saying hey actually I think it’s important that you keep it in here because it’s a config that people use based off of usage patterns and it has that because it has its own access to all of our like data logging. Put together a prototype for me so I could click into it. looked into the Porter prototype, opened the PR, made sure it’s CI pass, all good to go, merged. Okay, I have questions. [laughter] I think the first one is actually I know that there is somebody somewhere that is looking at this and they’re like, she’s she’s just outsourcing her thinking to the models. We don’t even think anymore. We just let the models do whatever we want. That’s not design. What would you say to that person? There is so much design work to happen that needs to happen right now that what you’re seeing is everything that I believe I can offload because the models are capable enough right now so that I can spend my time on like the really really hard gnarly problems that need deep design thinking. I think we’re all in an era right now, especially if you’re working at one of the labs or one of the companies that have really adopted this fastpaced shipping where you’re just it’s hard to keep up with everything that’s going out right now. And so these few examples you see are the examples of how I keep up actually and how people at Anthropic are keeping up because we’re finding ways to automate the parts that can be automated. So we can spend a lot of time on like the really hard design thinking problems that we’re working with. Like for example, a really hard thinking problem that’s part of it is like how do we explain to people that this is an organization’s claude? It’s one cloud that your entire organization works with. It’s not just your claude. Will people want separate access in a specific channel and how do we let them configure that so that you still have the power of claude knowing everything about the rest of the organization but it’s not breaching any security restrictions that you might explicitly have in your organization. How do we let you know the difference in between giving claude access as an entity in your organization versus just using your own user off MCPs which MCPs are already kind of hard to understand like how do we make that distinction between you. Those are the really important pieces that we spend a lot of time thinking on that we won’t offload because it’s about the user model relationship and behavior and like these design polish pieces or some of these updated ones are like really easy ones to offload. But you’re still doing a lot of that design work and even your own internal brainstorming by having back and forth with the models, right? Mhm. Absolutely. Let’s talk about that piece then. Like you talked about like the gnarly problems. You also said like the existential conversations. So like what you just showed in my opinion would be like very executiondriven work. Let’s just get rid of all the P3 things at scale. And I’m sure there’s a lot of people listening who that’s kind of their usage of AI and they haven’t really taken steps toward more of the how do I get Claude to accelerate my thinking on like the big picture stuff. So, like I know it’s a little bit wishy-washy what these back and forths look like, but for people who are not moving in that direction at all, like help us understand what your practice looks like when you are collaborating with Claude on some of these really, you know, the the the ambiguous gnarly problems. I think there’s two pieces to this. The first one I would say is that tactically there’s a skill set that designers are learning to develop. Some already have and some don’t. That is kind of an inverse of how you see the design role have been historically where there’s a huge school of thought that design is all around owning the quality and polish of everything and everything has to be quality and polished and I think it’s really important to have that but it doesn’t have to be all of your time. And so knowing when to use these tools for execution and offload and knowing when you need to go deep and do the thinky work is a skill set. And I think that’s one that I see people doing wrong. Like you might be asking Claude to do execution when you you should actually be asking Claude to do the early thinking. The execution is wrong. Like the shape of the execution is incorrect. And Claude is not good today at telling you if your idea is wrong, it’ll just execute on the thing that you ask it to do. And so there’s a responsibility on you as a designer, which I think is a really important skill set to have to know is this the right shape of product or should I be discussing with Claude the shape of it and not the execution of it like the mental model and the primitive rather than how it looks to someone and that’s a really big part of design that I think people often overlook. First, you need to be able to recognize that as an individual. Once you recognize that, I think when you are working with Claude on the more initial side of things, I tend to have my explorations be a lot more amorphous. Like there’s not a specific output I’m trying to get with Claude. I’m like only having a discussion. I say like, “Hey, I’m thinking about an idea and I’m not sure where it should go. Let’s keep it open-ended.” Like I’m working with Claude as if I would be working with like a product partner almost that I want to go wide with me in like our exploration process, but I’m also asking it to pull in all the knowledge that it has already from research, from data so that we can make informed decisions forward. And then a process like that might look like, hey, like I’m trying to make, I don’t know, dummy like a weekly meal planning app with me and my husband. What does a meal planning app need? Like what are all the parts of the meal planning workflow? You need to order, you need to like have the ingredients, you need to like know what food you want to cook at home, you need to know when you want to go out. Like it’ll propose the entire workflow for me, not from a design perspective, but from almost like a functional product perspective. And then some people are like, hey, like what is a meal planning app actually? And like I’ll have these existential like is it an app? Is it just actually like a workflow? Like do I even need a UI for this or can it just be nothing? and I just ask you to do this and then sometimes Col be like I think you like apps so you should have one but your husband doesn’t like apps you can just text him what happens at the very end it’s like those kind of discussions that you have that you would typically prompt yourself as a designer that you can prompt with Claude now and have like a that brainstorming partner with you so that’s where a lot of it goes and then that thinking isn’t as visual as you think it is though like sometimes I’m making mind maps with Claude or like tables with Claude but I think a lot of it is just like conceptualizing the pieces There’s another thing I want to talk about that is you’ve kind of talked around it a couple times where you mentioned how a lot of people like there’s this school of thought where design is like things have to pass through us to go out the door and we’re the ones that uphold the the bar for craft and quality and I get how working at like the tempo that you’re working at maybe that is actually impossible but it also does feel like it is directionally where a lot of this stuff is headed as lines get a little bit more blurry in terms of who owns what and cloud helps everybody do everything to an extent. So, one of the things that you mentioned last time we talked was how you thought designers needed to be more comfortable letting go of design. And I think we’ve seen like a couple examples here of what that kind of looks like, but why is that even necessary? And are there times even where that has felt uncomfortable for you? Oh, absolutely. I think in the ease of of anthropic, we’re very experimental and we’re so early in this exploration of like the shape of the product. Like I say this all the time, we’re 1% in this journey of like what the shape of AI should be. And sometimes knowing when it needs that craft and polish or knowing when just the shape of it is actually what you’re trying to test is really important. And so you might launch something or test something that looks terrible, but what you’re actually testing is the underlying mental model of the shape of product. And I don’t think it’s worth polishing that thing actually because it might not even make sense. You might have to rewrite it because it’s actually not the right shape of what it needs to be. And those are the times where I think actually spending a lot of iteration on that polish isn’t a good use of time. And I expect the designers on my team to know when something needs to be polished and when it doesn’t. that experimentation of mental models doesn’t require that high of craft and it’s better done actually in speed in the open in iteration as opposed to spending a lot of time polishing something that’s actually the wrong full wrong shape of what the product should be. The second part about handing it off is I tend to find the more we can share responsibility of what we think quality looks like in our product and not be the gatekeepers but educate and kind of delegate around us so that both our engineers and product partners feel that quality is something that they own and drive too. You want to like lower the floor and raise the ceiling for everyone to be design shepherds a little bit or quality shepherds. And so lowering the floor looks like making it so that anyone can feel empowered to say I think this is the right quality and you teach them why it is or not or claude actually teaches them if you have good automations in place and good design system files in place to teach you what good looks like and then raising the ceiling together meaning I don’t think and it never has been historically only design’s responsibility to mean quality the most successful organizations feel like it’s owned by everybody and so we need to make sure that we’re not pushing the bar on our own but we’re pushing the are with everyone around us and you do that by giving people that shared sense of ownership over what quality looks like. What are some practical next steps that designers listening could put in place? Maybe it’s like a workflow or a tactic to raise the floor and empower other people on their org to contribute at a higher level when it comes to design and more polished output. One that I do which has somewhat worked is I’ll stack nicer PRs on top of my engineers PRs in the workflow that you just saw. I actually don’t do them manually. I do them pretty automated. Like once Claude learned that that was a habit I did, it just started doing it on its own, which is crazy cuz it’s very proactive. Uh that’s one way because it doesn’t slow down the progress and it doesn’t erase the work that that engineer does. It kind of gives them an alternative or an iteration on what they did. And typically when they see that, sometimes I actually stack or iterate off of my PR so that it still has the right idea of what they wanted to do, but it like is in the right shape of product as well. And then I have been experimenting with some workflows where I like have Claude understand the things that I think about. Who are we serving this for and what are we trying to communicate them? You know like the basic question what are we communicating to them? Like does this align with our design systems? Has this gone through the past with like our content automation? Like how does this fit into the broader ecosystems of our product? Should this be a product or should it be a feature? Does this need to be named or can it be invisible? Like there there’s all these things that I’m constantly asking my engineers that uh Claude has learned over time that I like to ask. And then I’m slowly putting together like an automated reviewer that kind of does this for me and we’ll put up PRs or the interesting thing about being integrated in Slack is it’s not always about putting up PRs anymore. Sometimes it’ll just send a message to someone and be like, “Hey, Megan thought this about this. Like what do you think? Here’s like a prototype that you could play around with to like see what she was thinking about.” And so massaging that language is very similar to like just working with people. And that’s really helped. So I would say invest in like how you define your quality and how you uplevel it and then share that as a workflow that anyone on your team can use and don’t do it to stop them. Although it is important to know when to stop and hold the bar, but try and do it in a way that like is additive and is teaching and guiding rather than stopping. I think so much of what we’ve talked about today exists outside of pixels. And I think it’s kind of what’s made the conversation really enjoyable to me. But [laughter] I got to imagine still the vast majority of people that are listening are designing interfaces, right? Like historical B2B products. And even for myself in the last year and a half, I felt more and more of the value props around the products that I’m making shift towards like what’s the best model to get context through like an MCP and back to cloud and close these loops and like speed up iteration and that kind of a thing. It feels a little bit uncomfortable to me to be totally honest like like actually quite uncomfortable. I’m like, is this we just accelerating toward this interfaceless world? And I’m wondering how much you think about that and if you have any ideas around where does the interface have lasting value and more defensibility when it does kind of feel like you can almost do anything directly inside of a chat. Now, I’ve been really toying around with this idea recently and it’s something that I’m slowly developing a stronger conviction that we’re still going to need a lot of fixed interfaces. So there’s two concepts now that UI can fall into. There’s fixed and then there’s like adaptive or like non-deterministic is kind of and I think there’s just so much that needs to be reliably stable that you don’t want to relearn and you don’t want to be dynamic like a login screen, billing settings, like there’s a lot that actually feels important to keep stable and I think that UI will be really important. Knowing what should be fixed and what should be adaptive or dynamic is a really important decision for you as a designer to make as you’re designing these features because I think often people will assume that everything should be customized because it can. I’m very much of the opinion that a lot of people don’t want everything to be customized. The right things should be customized and adaptive. And then on the adaptive piece, I think it’s like what’s that container layer from what is adaptive? How do you express in a visual system that something’s adaptive versus something’s fixed? How do you let users customize it in a way that they understand that they’re customizing the tool that they’re using or they’re customizing the output that they’re generating? These are all like really critical workflows to get right. And so I think what I would guide people towards is like yes there’s going to be a lot that’s non-deterministic but there is still a lot that should be fixed and it’s your job to figure that out. And then in the things that are non-deterministic how do you make that easy and clear to people. Yeah makes sense. Honestly all of the stuff with artifacts is even challenging where I’ve been drawing the lines thinking about it. Like I’ve had multiple instances now where I’m designing you for a simplistic example maybe like a search results but the search results is natural language based. It can basically return anything and the shape of that is totally tied to the query where it’s like okay I don’t want to have an entirely dynamic interface. I want to probably have like a set of components and maybe map that to a system prompt where like we’re getting repeatable shapes where there’s like a little bit of familiarity but cloud can kind of do anything you want with it. And and I guess I thought that we were speedr runninging toward a world where that was how my future Claude interactions would look where you’re having like, you know, a bunch of different component combos that are maybe giving me different ways of expressing intent outside of just typing it. And now I’m like, man, maybe Artifacts has swallowed that entirely from me where it’s like I’m actually just not even interfacing with Claude inside of the chat. It made me almost even more skeptical about the level of interfaces that are going to exist in the future. I don’t know. It’s it’s the interesting thing that I’m I’m thinking a lot about. It’s like where where are we going here? I kind of separate my school of thought in between I’m generating a thing that I need to look at and I’m just doing a job that needs to get done. Like not everything has a visual output to it. And so I think for the things that are just doing jobs that get done they just need to be infinitely configurable and work for you but the end of the day there’s a starting point and that still needs to be designed so you can know what it can do. Like there’s a lot around like teaching people. And then on the dynamic side of things, I do think the dynamic side of things, I do think yeah, like having these be dynamic is what makes them so powerful. They should be and we should lean into it and be comfortable with it. And where you customize might be on like its visual language or the tool you use to edit it afterwards. Are there other unmapped design challenges that you think that we as an industry are going to be staring in the face in the coming months and like different types of problems that AI is kind of bringing to the forefront as the way that we interface with these models changes. I think a really big one that we’re we’re going to have to reckon with is when you can build everything should everything be built. Just because it can build and just because it can be a function doesn’t mean it needs to be. It adds a lot of product bloat. It makes it very complex. Minimalist design had its place and I don’t necessarily think that’s the solution. But I think in terms of like full functionality, things can be a little bit simpler than they are right now. And not every idea is good or necessary. Sometimes adding it is worse. but because it feels so easy to build now. Everyone’s building everything. So that’s a big one that’s reckoning through. Like having the discernment to decide if it’s worth building or not. Not even worth building because you can just build it, but if it’s worth adding to your product, I guess, and launching it. Okay. I kind of want to tie a bow on all this. Like we’ve covered a ton. It’s just new, right? Like there’s so much new in this conversation that it stretches me in all of the best ways. And I I think it does produce a lot of these existential questions of like what the heck is my role moving forward, right? And so I’m curious if you have any thoughts around like what’s the new shape of designer look like that’s going to thrive in the future. We talked about this skill around being able to decipher between whether I should be in execution mode versus shaping mode. Are there other things that you think are going to separate the best of the best designers in the years to come? I’d say the first skill set is just in the next few years where we’re still in the emergent phase of this technology. Being very open-minded and curious, I think is really useful. Like hold your opinions, develop them, and then be willing to let go and update how you think about things. Both what your role is, but also your product is extremely helpful because everything’s very dynamic. So, one of them is just like having fluidity built into you and being able to lean into that ambiguity and be curious and enjoy it and like find a place to start and move forward in spite of the fact that it’s chaotic. That’s a really big one that I think will serve people extremely well. I think it’s a hard one because design used to be so structured and processed that it feels like you really want to cling to that. But I’m urging people to do the opposite which is like lean into the chaos, develop new ways of working and like continuously update. And I think that will really serve you well. So that’s a big skill set that I think we need to practice. Kind of like let go of the rigid processes and roles as you know it and just lean into building good products and you’ll find your way. The second one I think is just maybe discernment is just another word for taste and I’m just going to like kick myself in the [laughter] future. But I think discernment on what should be built, how to best build it in a way that suits your product and what you’re trying to express and what role you should play in building it and where that craft should fall is like a big one. Like that’s the core builder process right now. It’s like if you identify a thing that should be built or an idea, how do you shape it in a way that it will land into your imagination from your imagination into a product and then knowing when to call it quits and be like that was actually bad. Let’s not do it. Looking at someone else’s and being like that’s not great and these are the reasons why or identifying something that’s really gold and be like yeah that’s great. Let’s keep riffing on it. We’re like two big shape iterations away or like one big ex execution riff away from getting there. like that discernment on like where something is and how it fits in and whether or not to go after it is really important. And then the third one I think is like feeling full ownership over finishing the ship because this era require like the the second skill requires knowing the difference in between the shaping and the execution and like when to lean in and what’s good. Sometimes that execution and polish will come after, sometimes it’ll come before, sometimes in between. And owning that loop, teaching your peers around you how to do it. Elevating your entire organization, not just design, but everyone around you is a really important role for design. And you need to feel your responsibility for that in the product. And you need to act on it as well. And so those three kind of skill sets, ways of life, outlooks are like specifically actually what I hire for on the team and specifically where I’ve seen people really succeed. It’s interesting. I I feel like in a lot of the conversations that I’m having each one there’s like a pull like we can’t just stay in like the traditional design box that we’ve drawn for ourselves over the years, right? So you’re kind of pulled maybe more into front end and more technical or maybe more toward product and on the surface like you look at anthropic and it’s like well you’re working on the models, you’re designing a freaking CLI, right? like you would expect the poll to be toward like quote unquote engineering, you know, but everything that you’ve said this entire conversation, like you were a product strategy expert, you know, like that’s kind of what you’re bringing to the table right now. There’s a slight at times hands-offness in terms of what is going out the door, the the craft, the slinging pixels around, like it’s very much so, like you said, what do we build, what do we not build, and why? and that kind of being almost like the anchor of the core set of skills that is propelling you in your career. I don’t know if that resonates or not, but that’s definitely like kind of what I’ve been hearing over the last hour. It absolutely does. And I think maybe this is something that a few folks in the industry have started talking about a little bit is like maybe as we all become builders, we actually just have archetypes that we lean into and like unique spikes of skill sets that we have, but our unique role doesn’t change. Cuz I think the skill sets that you just mentioned, they apply to people who like lean really heavily into front end and have a high degree of polish. It’s just like what they’re talking about is more at a feature level or more like very vertically deep as opposed to horizontally broad. So I still think those characteristics are important. It just depends where you are in the life cycle of a product and what you choose to anchor on. But I think I would expect all designers to be able to flex into the higher and lower level. I think that’s where the career is going. Before you could specialize only in one in one of these. Now I think the idea is that you’re developing them equally. Like we’ve expanded the skill set that we want you to be able to do. Well, in terms of curiosity being the defining characteristic that comes up on this show, you’ve definitely dangled a few very interesting threads to pull on for me and I’m sure a bunch of people listening. So, I very much so appreciate you coming on, Megan. You were quickly becoming one of my favorite people in the industry to learn from. And I’m already going to say we’re going to have to run this back on I don’t know what the timeline is because things change too quickly. But, uh, I really appreciate you coming on today and sharing what you’re thinking about and what you’re building. I’m glad. I’m glad. Thanks. And I would add like if there’s one thing that really excites me about the design industry right now and what motivates me to come out and speak with folks and to have these conversations with you is like to really encourage folks to know we’re early. We are all able to shape what we want right now. Like that’s the exciting part of it. So participating in this discore, trying these things out, developing your own opinion [music] is the fun part right now. We should all be doing it together.