Loading summary
Transcript96 lines
- [00:00]
A
Ever wonder what it's like as the first designer working on a generational product like Claude code?
- [00:06]
B
I DM'd. My manager is like, I think this is gonna be big. I wanna design moonlight for this.
- [00:10]
A
What does it take to design these types of AI experiences?
- [00:14]
B
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 use these tools for execution and offload and knowing when you need to go deep and do the thinking work is a skill set, and I think that's one that I see people doing wrong.
- [00:32]
A
Anthropic's new products changing the way that we think about building software.
- [00:37]
B
In the same way that it takes a lot to convince a non engineer to download a CLI tool and be in 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 in how you work with Claude.
- [00:52]
A
Welcome to Dive Club. My name is Rid and this is where designers never stop learning. This week's episode is with Megan Choi, who's the design lead for Claude Code and is pretty quickly becoming one of my favorite people in the industry to talk to. It also kind of feels like the way that design operates at Anthropic 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.
- [01:36]
B
So I joined late 2024. This is back when no one even knew outside of like, probably the core tech industry, what Anthropic was like. Everyone was so focused on ChatGPT and OpenAI at the time. And Anthropic was primarily an API business. It didn't really have a consumer arm. There was like a cloud app, but it just hadn't had a takeoff moment yet. And so when I joined, I remember people asking, where are you going? I'm like, oh, I'm going to Anthropic. They're like, what? What's that?
- [01:59]
A
What's that?
- [02:00]
B
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, where the real use cases live of what you're inventing. Maybe about three or four 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 it, 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 DMing it, which was Boris and Adam and Kat 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 designer to CLI. I DM'd my manager. I was like, I think this is gonna be big. I wanna design moonlight for this. My manager's like, sure, go ahead.
- [03:14]
A
Cool.
- [03:14]
B
Go do it. And that's kind of how I got started, and I never stopped.
- [03:17]
A
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've 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?
- [03:37]
B
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 there was so much to design and that back and forth in between the chats that made it feel more warm, more delightful, that communicated the statefulness of it. I've actually designed for clis 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 a CLI make it a very innovative space to play, actually.
- [04:24]
A
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?
- [04:42]
B
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 swirls 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 of 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 gui, 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 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 real quick message and
- [06:07]
A
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 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 keyframes 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. Enough you can get started today. Just head to Dive Club Jitter. I've anticipated desen's 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 of the pages and flows that you need are preloaded inside of desen as starting points, so you can iterate on them with your team, but also run user testing or inspect 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 Dessen. That's D E S S N. Now onto 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? How do you even get people comfortable with what a CLI could do?
- [07:46]
B
I think the biggest hurdle to overcome was making it feel like a chat. You could go back and forth with clis, kind of have that where you, like, print and then 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 Claude 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.
- [08:44]
A
Actually, the first feeling for me was I remember I was watching Dan Hollock use Claude code, and he was the one who introduced me to it. I don't 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, because I had never even. I had no CLI experience at all. And seeing that, or I'm immediately, whoa, what's happening? Like, where am I? This is very different.
- [09:09]
B
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 with them. And also, I think, like, Clawd 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 assy art. I think it's so fun. There was this deep period of dot 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 it, download a lot of apps, and a lot of them would include these, like, incredibly artistically drawn ASCII 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're trying to go for.
- [10:19]
A
It reminded me of the old, like, AIM Away messages. Did you ever do this 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 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 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 completely non deterministic. What is the role of design in a feature process and release like that? So give us a little bit behind the scenes for artifacts and what that was like.
- [11:05]
B
I think there was a really strong kind of emerging culture of people wanting more than just a transcript as an output, like something shareable, 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 is 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. Cause it's fast, it's snappy, it gets something like put together. Cloud'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 HTML files to each other so you could review it.
- [11:51]
A
I text HTML files way too much, which is crazy.
- [11:54]
B
Like, it's crazy that we're sending each other HTML files. It's actually insanity.
- [11:57]
A
It's like, I didn't even know you could. I was like, I literally asked Claude. 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 did it and hit Enter. And I'm like, no way day.
- [12:08]
B
Right, Right. But if you're sending someone an HTML file, it's like, didn't we invent the Internet? Like, why are we. Yeah, why are we. 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 Claude 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 reusing 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 tech 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 shareable 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. 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 else 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. We didn't really care about the name of 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 co team whose mantra 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.
- [14:11]
A
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?
- [14:19]
B
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 Claude 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 code base, 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 shareable 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.
- [15:13]
A
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. I'm trying to figure out exactly how that would fit into. I'm actually trying to ship something.
- [15:29]
B
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.
- [15:54]
A
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.
- [16:09]
B
Exactly.
- [16:10]
A
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, sourcing opinions and 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.
- [16:32]
B
It's almost like a mini microsite and decision log in itself. Like, often I will ask Claude to actually pull the data or pull any research I have from like Arpit, Queries, 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, churn 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 that proposals for there. And then I will ask Claude to review its own work in the artifact and like leave comments for me so I can see it and then I'll start iterating on there. 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.
- [17:20]
A
Separate links or is it like a table of contents almost?
- [17:22]
B
There's separate links, but they can link to each other if you ask Claude. And so I'll ask Claude 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.
- [17:39]
A
Whoa, dang, that's 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.
- [17:48]
B
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.
- [17:59]
A
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 in 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 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, okay, like, you know, these are the seven things that I've selected and can feed that back as context into cloud. But 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 been using artifacts for this.
- [19:06]
B
Yeah. And it makes them just like infinitely more capable and shareable. 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, 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.
- [19:22]
A
That's the smirk of somebody who already has the next version built but definitely cannot talk about it yet.
- [19:27]
B
Yeah, it's exciting. I really like it. You know, I never thought we'd go back to. HTML is like the main form factor for code and the main framework we use, but it's pretty powerful, it's pretty great. Speed means a lot.
- [19:38]
A
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 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 if you want to get on my list, or maybe you're even looking for your next design hire, head to Dive Club Slash Talent to join today. 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 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?
- [20:44]
B
Man, I am like constantly having both existential, personal, kind of big brain thinky discussions with my clients 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 Claude channel that's like my regurgitated brain in Slack, actually do it all in Slack. It's crazy. It might be like a crazy workflow, but mostly really.
- [21:15]
A
Yeah, yeah, I didn't see that coming.
- [21:17]
B
Yeah. If you see the Cloud tag launch and I think this is like a big one that 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 Claude at a high level and a lower level of execution.
- [21:32]
A
Okay, pause. Let's talk about Claude 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 why do you think that designers going to be using that more?
- [21:54]
B
Yeah, so I think Claude tag 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 because 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 be in the terminal to be working. And yet we've seen a lot of people do it now. I think Cloud 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 Claude, you spin up another Claude. 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 clients, you're working with Claude, a single Claude actually. And not just you working with a single cloud, 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 cloud that works differently than a human. Like you kind of got to let yourself take that leap and realize like, oh, clock 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 org 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 Claude its own credentials so that it can have its own GitHub access, its own Google access, its own Asana 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 code base. 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 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 clauds 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 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?
- [24:54]
A
Like crazy, Yeah.
- [24:55]
B
I didn't see that 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 clientag 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 Claude, 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 Claude. The crazy part is we use Claude tag to build cloud tag. So it's very meta. Like I was using cloud tag to update cloud tag and it was. It's aware that it's cloud tag. I've had some crazy conversations with Claude where I'm like, do you know your cloud tag? Like, what do you think this should be? Because you are cloud tag. 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 claw 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.
- [25:49]
A
That it's managing Dane, that's trippy.
- [25:51]
B
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 their clauds. 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'll just bring it to you. You just have to ask it to do it.
- [26:20]
A
Yeah, you're not even like pasting a screenshot or anything. You can literally just reference.
- [26:24]
B
I'll copy the 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?
- [26:30]
A
Dang, that's cool.
- [26:30]
B
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 CloudTag is it also learns about you over time. So what you're seeing 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.
- [27:39]
A
What the heck?
- [27:41]
B
It's crazy.
- [27:42]
A
What percentage of code that you are 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.
- [27:56]
B
I would say more than half of my code is done like this now.
- [27:59]
A
What the hell? And it's.
- [28:00]
B
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 is even not as forward looking because I had to ask Claude to do the design change. But very often now 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 it needed a little bit bigger of an overhaul. And so I was like, oh, 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 figma link of what we were brainstorming different architects of it. So I just linked it the figma.
- [29:04]
A
Quick, give us a little bit of context on that figma link. How far are you actually going in FIGMA right now?
- [29:09]
B
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 it's a speed thing.
- [29:35]
A
When are you faster in figma? Like go a little bit deeper there.
- [29:39]
B
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.
- [30:08]
A
Sure.
- [30:08]
B
Okay. Very simple, though. So it added a collapsible advanced section. It's making all these changes on how everything works. It's putting up a draft pr. I 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 were 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 mock up, 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.
- [30:43]
A
It'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 right it's right.
- [30:57]
B
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 are 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, man.
- [31:17]
A
That's so cool. That's so cool.
- [31:19]
B
And then I looked at it. I was like, hey, should we pull out this specific setting? Because I think it might be important to pull out. So these are 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 CI path all good to go, merged.
- [31:54]
A
Okay, I have questions. 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 designed. What would you say to that person?
- [32:14]
B
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 fast paced 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 CLAUDE that your entire organization works with. It's not, 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 auth mcps, which mcps are already kind of hard to understand. Like how do we make that distinction between you? So, so 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
- [33:51]
A
still doing a lot of that design work and even your own internal brainstorming by having back and forth with the models, right?
- [33:57]
B
Absolutely.
- [33:57]
A
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 execution driven 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 ambiguous, gnarly problems.
- [34:46]
B
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 polish. 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 thinking 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 should actually be asking Claude to do the early thinking the execution is wrong, 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 Clawd 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, like a weekly meal planning app with me and my husband. What? What does a meal planning app mean? 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 somebody 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 I'll 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.
- [37:55]
A
There's another thing I want to talk about that is you 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 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 Claude 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 when that has felt uncomfortable for you?
- [38:48]
B
Oh, absolutely. I think in the ease of anthropic, we're very experimental and we're so early in this exploration of the shape of the product. I say this all the time. We're 1% in this journey of 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 of 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 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 to. 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 designs responsibility to main 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 bar with everyone around us. And you do that by giving people that shared sense of ownership over what quality looks like.
- [40:49]
A
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.
- [41:02]
B
One that I do which has somewhat worked, is I'll stack nicer PRs on top of my engineer's 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 because it's very proactive. 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. 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's all these things that I'm constantly asking my engineers that 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 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 to do in a way that like is additive and is teaching and guiding rather than stopping.
- [42:48]
A
I think so much of what we've talked about today exists outside of pixels, and I think that's kind of what's made the conversation really enjoyable to me. But I gotta 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're 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.
- [43:44]
B
I've been really toying around with this idea recently and it's something that I'm slowly developing a strong 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 thing is 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, those 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?
- [45:14]
A
Yeah, that 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 know, 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 CLAUDE can kind of do anything you want with it. And I guess I thought that we were speed running 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 the artifacts has swallowed that entirely for 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.
- [46:14]
B
I don't know.
- [46:14]
A
It's an interesting thing that I'm thinking a lot about. It's like, where, where are we going here?
- [46:20]
B
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, 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.
- [46:53]
A
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?
- [47:08]
B
I think a really big one that 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 blow. 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, 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.
- [47:50]
A
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 think it does produce a lot of these existential questions of, like, where 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 an 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?
- [48:29]
B
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 find a place to start and move forward. In spite of the fact that it's chaos product, 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 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 will find your way. The second one, I think is just maybe discernment is just another word for taste and I'm just gonna like kick myself in the 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 cool 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 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 because this era require like 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 it comes 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 low. 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.
- [51:10]
A
It's interesting. I feel like in a lot of 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, you look at anthropic and it's like, well, yeah, you're working on the models, you're designing a freaking cli, right? Like you would expect the pull to be taught, 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. 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.
- [52:09]
B
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 because 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 lifecycle 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.
- [52:56]
A
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're 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 I really appreciate you coming on today and sharing what you're thinking about and what you're doing building.
- [53:23]
B
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 discord, trying these things out, developing your own opinion is the fun part right now. We should all be doing it together.