Design with Intent, Craft with Context | Intent & Craft Podcast

Good design doesn't happen by accident. It's very much a series of decisions that have to come together that are thoughtfully considered and discussed. That intentionality behind it in terms of craft, constantly deciding to continue to learn new technology, learn new ways of working in order to, to keep your craft up.

Welcome to Intent and Craft, a product design podcast where we dig into design systems, how we use AI in the design process, and what it really takes to scale design for software. For more than a decade, the Headway team has been helping startups and enterprise teams design and build better products. We want to share what we've learned along the way with you. In each episode, we break down the intent behind the decisions we make, and then the craft behind the actual execution. In this first episode, the Headway design team talks about what the name Intent and Craft actually means to us as individuals. What business leaders constantly get wrong when it comes to investing in design, and the gap between what clients think they need and what they actually need when they bring us in. We also get into where AI is saving us real time in our design process right now, where the tools still fall kind of short, and what we're most excited about as the line between design and development continues to blur. Now let's get into it.

What's the, the origin story of Intent and Craft? What's kind of the meaning behind the name? Why did we choose the words intent and craft? And what does it say about the design work that you do, that we do at Headway, and the future of design? So, Billy, what's your answer to that?

Yeah, I think the name really stems from the two different parts that makes up design, right? The intent of all the decisions that we have to make, what we're trying to achieve, what we're trying to help our customers or their customers understand and the work that they might be trying to accomplish. And then the craft behind actually getting those tasks done. What does it look like? What does it feel like? How does that all come to head together in like a cohesive product? And I think it, it's more important now than it probably has been with, you know, sort of the advent of all the, um, AI tools and things that are out there. So really, as, as that kind of enables us to move faster and do things quicker, the intent is more important now than it ever has been. And then the craft side of it is more important as well, because we're going to get a lot of just good enough stuff here that really needs that finer touch and that refinement. So not really a great origin story, but kind of like what that name signifies is, is that comprehensive design lens on everything that we do.

Yeah. And okay, I'll like touch on the origin story a little bit. This show has been an idea for like 5 years or more, maybe, I think maybe 6 years. And so now we're finally bringing it to life to kind of like give a focus to design and the conversations around design and allowing our team to kind of share what we're experiencing internally what we're experiencing with clients and to share that with everybody and hopefully invite other folks in the industry to, to have conversations with us about the things that they're seeing too. So Bree, what do you, what thoughts do you have around the name or what, what Intent to Craft means to you?

Yeah, I think when we think about intent, it's are we thinking about the right things and how are we thinking about those things? There's a lot that goes into making Some things may feel outdated just because of the tech that something has or the way it looks. So being aware of what's modern. And then there's also this piece of uniqueness that I think is important in making sure that the decisions you're making not only feel unique in terms of the product and the ecosystem that you're working with, but they're also enjoyable and functional to use.

Sam, how about you? What, what does intent and craft mean to you? Everyone on the team here has worked with smaller startups launching a new product to market, maybe just the founder and maybe one other person, you know, with them. But also you've been working with like enterprise teams too. Maybe talk about that a little bit, like how you've kind of, your experience of intent to craft in a very small team or just a founder versus, hey, I gotta deal with a ton of stakeholders and figure out like how to balance all this stuff?

Yeah, for sure. I think when you're on a smaller team, it's, it's, uh, maybe like you're closer to, um, uh, you like your immediate stakeholders and, and I think it might be easier to, to look at like what what business outcome or, or behavior are we trying to, to impact or influence? I think that can be maybe a little more challenging in the enterprise level, just like, because there's so many layers. But in the, it's easy to just maybe get caught, you know, tunnel vision a little bit. I, so I think it's, yeah, it's just really important to build like, pause, peel back the layers and make sure we're actually addressing like a specific behavior or like I said, like a business outcome that we want to influence. So that kind of like encompassing the intent piece of the name. And then, yeah, I guess as far as like craft, more of like how we do it, you know, how, or like how we make something and, and just looking at the systems that we put in place to help support like the intent that we're, we're trying to reach for.

Yeah. Melissa, how about you? I kind of have the same question. Cause I've seen you do a lot of different projects and your expertise within UX audits as well. I'm just curious what, if you have anything else to add.

Yeah, I think it's keeping in mind that good design doesn't happen by accident. It's very much a series of decisions that have to come together that are thoughtfully considered and discussed, and that's what makes something good, that intentionality behind it. And then as well as in terms of craft, constantly deciding to continue to learn learn new technology, learn new ways of working in order to, to keep your craft up.

Melissa, I'll stick with you for this, this next question actually. What's one thing that like business leaders consistently underinvest in when it comes to design and like what are kind of the costs of that because they dismiss it or don't feel like it's important or make excuses or, or whatever that may be?

Yeah, there are a couple things I think of when you ask that. One is They underinvest their own time and energy that they have to put into making whatever it is that they're looking to accomplish. You know, we spend a lot of time with our stakeholders understanding their problem, their vision. We're not going to go away and 6 months later come out with a piece of design and call it good. So I think they underinvest in their own commitment to the projects. As well as like putting together a process, kind of like I mentioned, it's a lot of decisions that have to come together and a lot of documentation that has to come together. And oftentimes in smaller kind of founder-led engagements, it's only one person, they have it all in their head. And now you have to download that into my head. And then if you're hoping to scale, we have to make sure other people understand it. So they don't really think about that commitment of having to document processes. And then in larger enterprise-level engagements, there might be one or two historians who have been there for a very long time, and they are the kind of keepers of all this information. Or it's kind of universally understood, and then coming in as a newer person, understanding acronyms or understanding any of that stuff. As you might've noticed, nothing that I mentioned is the actual design work. That part comes a lot quicker and a lot faster when you understand where you're going, you have documented processes, and you have that access to, to your stakeholders or key decision makers.

Yeah, I love that historian, like, kind of title you put to people, cuz that, I feel like that's so true. Like, my dad's like one of those people. He doesn't work on software, but that he's that guy where he works, like he, He's like the Bible. Like he knows all the stuff. Like he's like the user manual basically. Yeah.

Yeah.

They're hard to get ahold of. So it's really tough.

Yeah. I think one thing that I was thinking as Melissa was, was talking is we work with a lot of early stage startups and enterprise customers, and I think each of them underinvest in processes and things that, you know, like early stage startup doesn't spend enough time understanding why enterprise is successful and stealing those bits for early stage startup. And then enterprise doesn't understand or underinvests in sort of the fluidity and speed at what an early stage startup can do with their limited resources and underinvests understanding that. I think an example I see a lot with early stage customers is they look— sometimes they'll look at design as a means to an end and not as a foundational system for their entire existence really going forward. And that can really lead them down some interesting rabbit holes or constant redesigns, and it ends up costing them a lot more money in the end than if they would have thought that way just from the get-go and kind of built those, those foundations. And then on the flip side, enterprise customers, you know, sometimes they're so ingrained into their system, they're almost risk-averse to trying interesting things or trying to push those boundaries, which doesn't allow them to evolve and, and really lean into their design teams and allow their design teams to kind of expand the way they express themselves, either in software and marketing and things like that. So it's just An observation that I've had a lot is just they're not spending enough time studying each other and pulling the bits and pieces that really matter.

Just riffing a bit off of what Billy was saying, I think design is one of those disciplines that is very silent in how it presents itself if you're not in the design field. And I think that means if you're not thinking about the design, it usually means it's done well. And I mean, you can think of anything, like the design of anything. I studied package design when I was in college, and I didn't realize how much actually goes into designing a label or designing a box. And like, you just go to the grocery store and you pick something up off the shelf and then put it in your cart and go on your way. But somebody put a ton of effort into making that. And I think that's the same with product design. And because of that, I think business leaders can overlook just design as a discipline and lean more into engineering. As a discipline, just because that's like the inner workings and the functionality that's going to get the thing to market. But if you don't have a good front end user experience and all the back end works, that's not really going to make people want to use your product.

Yeah, it's funny, you were, when you were talking about labels, this is a common problem that I think I have is like, if I get something and it's been in the fridge and I, it's not easy to identify the expiration date. I forget that I should probably eat this sooner than later. I'm like, I'm gonna have this instead today. And then I'm like, ah, I should have had that yesterday or whatever. It's like things like that. It's just like sometimes it's impossible to find the expiration date. It's not on the bottom.

Where is it?

Oh, it was on the little plastic rim that I removed when I opened it.

Yep.

And now I don't know. I think we can move on to this next question. When a founder or a product leader first brings you in, what's usually the gap between what they think they need for their project and then what they actually need?

I can jump in. I got this one. We see a lot is a lot of times we'll get brought in and folks will think of design as, oh, they're going to, they're going to put the interface, the interface together. And then we usually come in with, all right, we got a lot of questions like, who is this for? What are they doing? And then we kind of get into like the data side a little bit so we can understand what needs to be represented, where, how does this transform throughout the process? What's important in these different roles. And, and we spend a lot of time working in this like foundational app mapping process with a lot of our customers. And sometimes, you know, a lot of our early stage startups and even some of the enterprise customers, they have this like eureka moment when we go through with that because they don't always understand even how their products currently work or how those things are connected. And that helps us drive a lot of insights and really understand what's in, what's important right off the bat. And sometimes it feels unnatural for folks that a designer's coming in and doing that, especially on the, on the data side. A lot of times we'll do like flow diagrams, but really understanding like where does this come from, especially enterprise customers, because data sources come from all over the place. It's not just one single feed that pulls in and we need to understand how that stuff functions. So a lot of times we'll do that before we do any sort of interface thing. And a lot of times those artifacts become really valuable throughout the organization in a way for other teams and other disciplines to come back and look through that stuff. And a lot of people don't— they don't assume they need that or even know that's an option of something that can be created for them.

Yeah, that's interesting. I never really thought about that way where a lot of the, the assets that are created are like just actually valuable to everyone in the organization and not just the team that you're working with. I even think about that stuff at Headway internally, like, hey, we, we did this thing over here and when we share it between either designers that are on different projects or designers to developers, or just, you know, whether it's like anyone on the leadership team, like, oh, that's really interesting. Like the fact that they found like the insights of like, oh, they found it really valuable or they're, they're sharing it internally with their, their team or whatever that looks like. It's one of those things where you, you underestimate like the value of the things you create day to day and just think like, oh, this is only for me. But until you actually show it to somebody, it's like, oh, that's really cool. Did you know this? No, I did not. And it's like all of a sudden there's like all these, like, like you said, the eureka moments or light bulb moments. I'd imagine too, like with, especially with like software, because like turnover on teams can be kind of high at certain companies, the people, the team that built the product, may not be the same team that's either improving the product or building a new version of it. And so they're probably, like you said, like they don't understand how it all works. They like, hey, it, it works today, but I don't know why it works. Right. They never actually mapped out everything. Or maybe the, the previous agency that built it for them never gave them an app map. They just like maybe assembled it, but never shared some of those assets like you're talking about. That they kind of went away for 6 months and came back and here you go kind of thing.

Yeah.

It's just, just really interesting. Does anybody else have any thoughts on that?

I think what's interesting when we chat with clients, I would say more so on the startup side, but we've seen this with enterprise as well. Folks will come in with what they think is a very clear idea about what they want and what they need and their audience for that. And then we'll, we'll run this exercise called simulated shopping. And it's a research exercise where we actually take their idea and we start showing it to strangers. And what we experience during that is very interesting because there's always these moments where people are telling me vastly different things than what the founder or the executive came in and told us they want the product to do or what they think the product is. And we show these clips of the interviews to clients and they're like, what do you mean they didn't get my idea? What do you mean they don't like my feature? And so I think in that case, it's always very interesting for folks to get that feedback. And with us being like an unbiased person, like we're not the ideation space of the founder or the executive coming in to work with us. We're just like, hey, you know, you can come in and chat with us and just be honest. And we always, we tell people like, be yourself and just let us know what you think of this. We get a lot of very candid answers. And people will flat out tell us that things are not a good idea. I would never use this. And then we'll ask them, well, what would you use instead? And what they come out with is always very interesting. And when we take that back to the client, it's interesting for them. They have a eureka moment, to use Billy's language. But then it also helps shape the end product of what getting that product out to the user actually means and what they actually want and how they want that packaged. and that's going to be a lot more successful than just getting whatever you think the user needs. Like, you really have to go out and talk to the audience and make sure that you're talking to the right audience and you're actually bringing them something they're really going to need.

Where do you think AI creates a risk in design, in the design process that business leaders aren't thinking about?

For me, I think kind of like to what Brianna was talking about, doing that simulated shopping and getting kind of honest feedback. The risk is not getting that pushback of not having those guardrails or someone there to say, maybe this isn't the direction you should go in. I feel like a lot of times with that technology, it's more about, yes, let's get you to the solution. I'd have all your documentation. Let's get it out quickly. But there's not that step of, is this the right problem that you're solving? Is this the right audience? Like, that is the one component that I don't think is built in just yet. You have to kind of search for it.

Yeah, because I've even seen where they do like these kind of like AI avatars where they'll, they'll test it with like kind of— I don't even know how it really would work or how it works because I've seen it where it'll put like interfaces or ideas in front of these avatars and then they would give like fake feedback essentially. But they're supposed to act like that type of user or that type of customer or whatever. But it is, it is interesting 'cause it's like, oh, they could be, have positive feedback or the negative feedback could just be an assumption based on the model. And it's not like what a real person in the real world would actually say because human experience is unique. Obviously things change in real time all the time. It's hard to also— any related experiences that are outside of the knowledge base of that model can't be put into that. It's a very, very unique thing. And, and kind of the human in the loop part is like super essential when it comes to that.

Yeah, like you have to, you have to have a reason for every decision that you make. And so with AI, like with, like what we're saying, a lot of that can just be automated and it's great 'cause you get there faster, but then, then you're not necessarily like there along the way to help even understand why you're making these decisions. So it, it is, yeah, like you're saying, making, making assumptions that can definitely have an impact with your product down the line.

Yeah, I think like there's sort of like your product is your reputation, right? So like we want to have some sort of guardrails on like what gets released out to customers. And also, do they know that this might be a beta feature or something that we're testing? Like we can get things out to people quicker and doing that in your main product. I think we've all kind of seen sort of the reaction, whether it be on Twitter or Reddit, as things get launched and people are like, what is this? No one asked for it. Why do I have this here? and you know, did they actually get a signal that says that should be something they push forward or not? So I think that's, that's something that's kind of risky to, to do. But on the flip side of that, we are empowered now to build like really authentic MVPs and prototypes a lot faster that feel more realistic than the standard click-through of a couple of screens. So I'm really excited that we'll be able to test and get feedback from folks on something that looks a lot and feels a lot more realistic. So that's kind of exciting. The other risky thing that I've seen is, and we've been a part of a couple of, you know, like AI process weeks or, or deep dive sessions, and we've done our own internally, um, is if you don't really put some guardrail, guardrails around it, it kind of just will do whatever it wants to do. And you know, you always see the like, oh, Claude Code wrote this whole UI from me, but it's like, it's not built with a foundation. And then all of a sudden it suddenly drifts off to the side a little bit and it's doing interesting things and you're like, well, actually, no, I, I, my input focus state should maintain this color. Why did you change it? And things like that. And so that's something that we've been really diving into is how do we help build those guardrails through like design systems and process so that you can get something that feels more realistic and follows your your process and guidelines.

Today's episode is brought to you by Headway. Do you need to design and build a world-class user experience for your software, but feeling like you just can't get there on your own? That's where Headway comes in. We're the folks who help ambitious startups and enterprise teams bring their product ideas to life through design, development, and product strategy. We don't just give you user interface designs. And leave you to figure out the rest. We work with you and your target customers to create beautiful user experiences, build scalable design systems, and provide Silicon Valley-level talent to get it done right the first time. Whether you're launching a new software or just looking to add features, we've got your back. We've worked with startups in industries like logistics, healthcare, fintech, and edtech, helping them solve their biggest software challenges. And here's the thing, no matter how complex your product is, we can help you gain clarity and get the job done together. We're so confident that we'll be the right fit that we offer a 50% money-back guarantee if you don't think we're working out within the first 45 days. Ready to see how we can help you and your team? Just head over to headway.io and book a free consultation today. I think the next one would be where do we we feel like AI will be the most helpful first when it comes to design, or maybe sharing things that you've been using it for lately that have been like super helpful.

Yeah, I think a big push that we've had on the team is using it for prototyping in particular. I know Billy just kind of alluded to that a little bit in his previous answer, but we did a spike on a few different tools back in the fall and tried to run different examples of designs we had made or remaking designs for popular features for websites and seeing if we could make an adequate prototype. And one thing that I think the Figma traditional prototyping method has is it's just, it's very tedious. You gotta drag all the, like, the little noodles around the screen, and, like, it's very time-consuming. And I think it's also limited. You can't do things like animations very easily. There, there's a lot of, like, Wizard of Oz type hand waving that happens to make something look, like, kinda real, but even still, you have to kind of talk through, well, you know, it's gonna do this. And I think when presenting ideas to clients, having it be as real looking as possible, I think is quite helpful in getting decision makers to get on board with an idea or make a decision. So we've seen that being able to prototype with tools like Figma Make and Cursor and Claude Code have been really impactful, not only in the sense of speed and tediousness. It is certainly faster, but I think the output that we get from that is a lot closer to what it would look like in a production environment. And that also empowers us to have better conversations with our developers so that, again, if we're in that space of using a clunky prototype that isn't really doing all the things, like how I describe something and how a developer might interpret that, there's going to be a gap. Whereas if I can show them an animation on a clean prototype that I've made with AI, it's pretty clear. And then we're just talking about like timing and some smaller adjustments rather than like, let me go Google this animation for the kit you're using. We don't really like this level of spin. We want it to, and you just get like so in the weeds that it wastes time. So I think that's definitely one big unlock that our team has found.

Used it for two, two projects. And, and I think the idea for just like expressing ideas so you can hand those off to developers or trying things out is, is really valuable. So we've had this conversation about building a custom plugin. that allows designers to basically go through their entire file and plot and apply the gap values from the variable system with inside of Figma that they might have manually typed in. It's a tedious process in Figma. You gotta click a button, go to the variable, click a button, go to variable. It's a lot. So sometimes people just type it in and I was able to like mock up a proof of concept with, um, Claude and Cursor. And get something up and running myself to prove that that could exist and then be like, hey, dev, can you make this a reality? Uh, on something that, you know, make it so it's actually scalable and makes sense. But I was able to like build that out and prove it out. And that's kind of a cool process for testing out an idea really quickly. Otherwise, I gotta go to a developer, ask them, hey, do you think this is possible? They gotta do the research. They go, yeah, I think you can do it. And then I have to wait for them to make it and kind of sit around, or I have to learn how to write code and do all this other stuff. But I was able to like, I don't know, brute force my way through it with Claude and Cursor doing it for me with enough guidance. And, and so that was kind of a cool process to getting a custom plugin built that we needed.

What do you hope either comes out or gets figured out within the design process in regards to using things like Claude Code or any AI tools in general and like what parts of the process you feel like are a big opportunity to be improved with some kind of automation versus, uh, the way that you're doing it today, like in Figma or something like that.

Yeah, I think there's a lot of opportunity there between the developer and designer handoff, getting an understanding of what ultimately we want. At the end of the day, and also getting buy-in from stakeholders. It's hard for them to see the vision until it's like finally developed and out in the world, but being able to get buy-in by showing them something more polished than just a couple of wireframes, that's super valuable.

Yeah, I, it's funny cuz I see there's folks at, at some certain teams at certain organizations that are where they're letting the designers push things to like production. How do you guys feel about that kind of stuff? Have you done it at all? I'm just kind of curious.

I have not pushed anything to production for any of our clients yet, but I've, I've done enough damage myself. I would say that I feel, I feel, uh, less about the need to push to production and more about like, let me work like sometimes we don't always have to go back to Figma to build everything out. If we have like a, a proven pattern in like, just let us build in the actual interface and then maybe have someone else prove it and double-check it and push it. I think the thing that Figma just announced with, I believe it was Claude Code or even what Paper is trying to do where you're actually building in the live interface is very exciting cuz that makes designers less of translators. You know, like we gotta build something and then someone needs to translate it and we actually can just be there. We can test it on all our different browsers and test it mobile and, and see those real assets and design in that space. I mean, we still need the infinite canvas that Figma provides, but it would be nice to be able to have tighter loop that we can then have some responsibility and some control for and really not waste a developer's time to, like Brianna was saying earlier, mess around with animations when like let us get in there and do that and craft that and then submit it as an actual code element that they don't have to translate later on.

Yeah, you mentioned Paper. Are there— what tools seem really, really interesting to you right now that either you've just seen people sharing things online or been to the website or seen things on YouTube or maybe have been experimenting with that seem really helpful or interesting or promising?

Yeah, paper.dev is interesting. I've been following their roadmap. They're going to start, at least they currently have planned out from what I saw, is to be a little bit more being able to design in the real coded elements, similar to the thing that Figma just announced with Cursor. Or Claude Code, those are really interesting. And then for trying to think of the other one, it was shared in our internal design channel, but it was a similar tool where the design canvas is the literal code coded elements that you're working with and manipulating and changing, which that seems really exciting. It seemed a little limited. You know, you still want the infinite canvas that Figma provides, at least I do for that exploration and being able to try stuff out and sort of that freedom, but then being able to refine it as an actual component that could then be shipped off is really interesting to me.

Yeah, cuz it seems like with Figma, the collaboration's really effective where people can go into the canvas together, they can leave comments, they can talk, they can chat. But then like with these coding tools, it's like, this is like your own, you're like in your own little project. It's not like other peo— unless I'm unaware. It's not that other people can jump in and like collaborate in the same way. And I think show examples on the side, like, hey, well, what if it was like this? Like, it's hard, it's hard to, it's like, well, no, I gotta do my own Claude code thing over here. And then we just kind of like compare them side by side or whatever.

Yeah.

Right. Like the process, that kind of process hasn't really been figured out.

No. And I think it's still two different, it's two different like experiences. I think like, in Figma with the open canvas, a lot of that is creative exploration. Like, and I still think that's the main intent of Figma is like, I'm, I'm trying to figure things out. I need a, I need everything to be unlocked. I'm not gonna engage with auto layout yet. I'm just trying to see what does this look like? What does it feel like? How could these things be built together? And then once those decisions have been made and you're feeling comfortable, now you get into this more rigidity that you're trying to establish because now you're trying to ship to a dev to build these components out. And so you're using variables, you're using styles, and you're building out different states for things. But then you kind of hand it off to dev to translate that into the, the real element. Like we're still building a simulated element and then they're building the real element. And I think the refinement to building the real element, that gap closing is gonna be really nice. 'Cause in, we can help out with that and we can help drive that instead of essentially building the same thing 2 times, cuz that's what we're doing now, or 3 times or 4 times depending on how many platforms you're working on.

Yeah. Is there, cuz of the, like the app mapping process we do, is there currently a way to kind of like connect the dots there? Like where, hey, mock up something with this app map data. Have you done something like that before?

Attempted to, it has not been great.

Not been great.

What did you try?

I'm just kind of curious, maybe share your experience with that. Like, hey, this sounds good. Like, oh, I'll put it here and it'll output this great first version, this great MVP. So maybe share your experience.

Yeah. So we've taken sort of some of our app map information and I mean, this was a rough proof of concept. So put some parameters on it. It was a rough proof of concept. We didn't go too deep on it. But we did it two different ways. We were one, hey, we have this brief, this is the information we have. Here are some documents, create an app map for us. Uh, and we, it gave us kind of a high-level app map or a flow diagram, but it missed a lot of the nuance and the way that we were working. And it, I want to look into like Lucidcharts and see if there's a more, something that I can craft more prompts to get it to what I want it to be. The, when we were doing a Claude to Figma, it was a one and done. It shot out the app map and they were done and you have to kind of reprompt it and do that. Sure. Taking the app map item and having it spit out a screen, when we did that in Figma Make, it, I mean, it was okay. It still created a bunch of gaps for various things. It's a lot better when you can give it the app map information and then like a mockup.

Oh, okay.

Like some of the explorations that you had done, Brianna, where we actually gave it the mockup and then it was a lot more informed about what it should be. That worked a lot better, but it's still like you spend a lot of time prompting afterwards to, to really craft, to get it into the spot that you need it to be. Yeah.

It's like wrestling it into where you want it to go and you could have just made it yourself.

Well, yeah, I think like the way I've thought about using AI and like prompting it is you have to, having had experience leading teams and giving direction, you have to give it direction as you would give a team member direction. And you have to be very specific if there's things that need to happen. So you can't leave out details because in the sense of like working with a person, they're just going to fill those in. And what you have in your head and what the person you're working with or the agent you're working with has is not going to be necessarily the same. So being very specific about what you want in that prompt is going to be helpful. But then also, I think to Billy's point, the tools aren't quite there yet. And so what ends up happening is even if you're that specific, your output still has to be edited. And then it's sort of in the case of like, if you're working with an intern with no industry experience at all, and they just don't know what they're doing. So I think there's like this space of the AI has to improve and the more you use it, I think you get better at prompting, but there's still just like this gap in the tools. Like it, it can't do certain things yet. That doesn't mean that it won't be able to in the future. And I think that's exciting too, because I think As designers, creativity is important and most of us want to hang out in the creative space and not in like this tedious, like data heavy or like number crunchy space that sometimes you have to do in order to build features and make sure things are correct. So the more opportunity we have to be in that like free flowing, open canvas in Figma, like I think. The happier folks are. So allowing AI to do some of those tasks and help us get there quicker, I think will allow for hopefully more creativity, which I think will help solve for some of the like AI sameness that we're seeing now, where it's like a lot of the stuff that is being output from AI in that creative space is very like same, same and having uniqueness in your product and your brand is going to help you stand out. So you don't want everything to look the same because then there's no differentiator.

Just to follow up on what Brianna said, I think, yeah, the ability— there's like all these micro opportunities for automation that we can leverage AI for that's really exciting. Like we always joke, oh, okay, you've designed out what this brand and what this look should be. Now you have to go in and make the hover state for all of these, and then the tags and all this other stuff. And like getting a first draft of all of that automated and cross the line is a very exciting prospect. And then, you know, being able to hone that afterwards, cuz a lot of that stuff isn't a lot of fun. It's not terribly exciting to do. It's a lot of manually translating things. So the less we have to manually translate stuff, I think that'll be, that is gonna be more. Uh, where we can then be more expressive and try different things and be a little bit more interesting with our buttons and inputs and, and brand decisions. Because we don't have to worry about like, oh, is this gonna fit in the box that we have? Because, well, the tools will help us get it in there.

Yeah, it's almost like the details are really where the impact's made cuz it's like under— getting just more answers to questions that you don't have answers to. Or, you know, I think the one thing that John talked about on Even Keel podcast about the development side and code is that, you know, in the past as a human coding, like sometimes you, you, he called it like human slop where like, hey, sometimes you just make errors as you're typing things out or copying and pasting things in from different sources and stuff like that. Or bugs just start to happen. You don't have the capacity within either the timeline or the budget to like go in and clean up everything before launch or within maintenance and all that kind of stuff. And with this, it's like you can focus on all those details that really matter and help polish a product because now more than ever, you know, the expectations are higher for version 1 and for all the improvements and the speed of the experience, the how fluid things are. Like Brianna shared earlier, like good design, you don't actually think about the design when it's that great. Like you're just, oh, this is serving me well. I'm enjoying what I'm getting from this thing. You're not really thinking about the design where sometimes people are like, I don't like how that looks. Like, or you're just like, this is really ugly, or this is confusing and you get frustrated and all of a sudden you're thinking about how it's designed. Like, I wish this was here instead. And so the more time you can focus on those things, getting that human feedback, simulated shopping, whatever that may be. I think that's great. So like you said, the less time on the foundational stuff or the repetitive stuff, the better. And I don't know, like if it's a matter of like Figma fixing those things or just plugins from the open source community or just new complementary products that do that thing in parallel with Figma or other tools and stuff, the future will be kind of unraveled as we go. It's like, how design will work. It, it's from a marketing perspective. And then even just talking with the development team, like the way that they're, that we do our work compared to a year ago is it's just fascinating. Like how much I'm using like Claude and Claude Code to do things. Like it's just fascinating. Like I, a year ago I never thought I could do the things I'm doing today. And so it's hard to imagine like what design work will look like. But I think going back to like the origin of, and the name of the show is that As long as you have the intent behind what you're doing and understand your craft really well, like those tools will just help you do your job better. As long as you're, you're, you're following like the basic principles that actually matter.

Yeah, I think one too, one thing too is like a lot of times we're looking at this to solve and automate things that we've done, but also using it to ask more questions of yourself when you're doing different design work. That's something that I've recently been doing a little bit more of is, is using Claude as sort of like, hey, if I was going— if you were going to go do this, what are some questions that you would ask me, uh, to give you the correct answer for this? And then using that as a prompt for me then to think through, oh, okay, well, maybe I should add this, or maybe I should consider this, or maybe I should do something like this. And that's been really useful as like kind of a sounding board almost instead of, or just to expand your thinking a little bit. 'Cause sometimes we get trapped into our repeatable patterns that we've done and it's always good to kind of push ourselves a little bit. Yeah.

Well, as we wrap things up, I do wanna talk about kind of like what's next for the show. This is episode 1, but what people can expect in future episodes. I probably won't always be here to do things to ask the questions, so I may pop in from time to time depending on the context of the episode. But, uh, I know that we'll be inviting other folks from other companies and, and other experts to join us on the show from time to time. But, you know, Billy, would you maybe like to share some of the topics that we've been thinking about and what we'll probably cover in the coming months?

Yeah, we want to talk a lot about the process, really just the process of, of design at all the different scales that we, we've engaged with here at Headway. So everything from early stage startup design to running teams, DesignOps at larger enterprise, and, and what is, what does the actual work look like? A lot of times, you know, we get a lot of fancy demos and we see like case studies and things like that. And really a lot, we want to find a space for us to dive in deeper, uh, to, to what does the process look like? Because it's different everywhere. There's like set rhythms and rituals that teams can do, but like It does look a little bit different everywhere and really just kind of uncover that nuance that it, that is on every project. Cuz every project's different, every product's different, every team's a little bit different. So really having conversations around that.

Yeah. And I think it also, to get really specific, to be, it'd be great to have either Dan or Tim or both of them to talk about design systems from a development perspective, talking about MCPs and things like that, just And again, we mentioned earlier, like the handoff process, like going from design to development, what's been working, what's not working, and kind of what the future of design systems even looks like too.

Thanks for watching Intent and Craft. Want to support the show? Subscribe and turn on notifications so you never miss an episode. You can also share it with your team or leave a rating and review to help other designers and product leaders find us. We'll see you next time.