Design Systems in the Age of AI Agents
Learn what healthy design systems look like in practice, how to structure them for AI agents, what contribution models work at different team sizes, and how tools like Figma Make are closing the gap between design and production code.
Presented by
Key learnings
What the first ten minutes inside a Figma file reveal
When the Headway team opens a new client's Figma file during a design system audit, the file itself is rarely what they look at first. Billy Sweetman's first question is whether there's an ecosystem around it: a documented process, a named point of contact, and context for how the system is used across the wider organization. A Figma library that exists in isolation is a red flag.
Design token drift is the next thing the team watches for. It is common to see a clean token standard at the foundation, but then a trail of one-off tokens added over time that never made it back into the system. That pattern typically signals a team that has been moving fast without a defined process for evolving and reviewing the system as the product grows.
Figma library versus design system
A recurring point in this episode: receiving only a Figma library does not mean a company has a design system. If there is no documentation, no governance, and no representation of that work in development, it is closer to a component library. The distinction matters because a true design system includes the processes, ownership, and cross-functional alignment that keep those components accurate and useful over time.
Figma-to-code parity and why it is the real unlock
Billy and Sam have been doing significant work to ensure everything in Figma maps one-to-one to the coded environment, including property names, component states, and structural conventions. The goal is not just consistency for designers but readiness for agentic AI tools that need to traverse a Figma file, identify a component, read its active properties, and correlate them to the correct coded component.
When components exist in Figma but have no equivalent in Storybook, it creates drift that eventually catches up with developers. The inverse is also worth auditing: if a component in Figma would not make sense as a coded component, it probably should not live in the Figma library either. Keeping both environments genuinely in sync is what makes the design system useful in development, not just in design.
Building a design system that AI agents can actually use
With agentic AI tools increasingly generating code from design files, the way a design system is structured has to serve two audiences: human designers and developers, and AI agents that will be reading and building with it programmatically. The Headway team has been exploring this directly.
Skill files and AI-readable documentation
One approach the team has been testing is crafting skill files that embed the kind of human perspective and design intent that an AI would otherwise have to infer. The goal is to give an agentic tool enough context to make good decisions, rather than having it backfill gaps with whatever it can find.
Properly labeled tokens and variables are a prerequisite here. If naming conventions are inconsistent or ambiguous, AI tools will generate errors or default to their own interpretation, which means technical debt that is harder to fix after the fact than it would have been to prevent upfront.
Writing documentation that works for both designers and AI tools
Billy has been experimenting with the USpec plugin through the Figma Console MCP to explore how AI-generated documentation differs from what the team typically produces manually. The plugin crawls Figma components and surfaces anatomy details, but it needs prompting to go deeper when properties live in sub-components or when Figma terminology diverges from what the development side uses.
Prompt specificity as a design skill
A key lesson from Billy's experiments: the AI cannot infer what is not explicitly visible in the file. Writing good documentation prompts means treating the system as if it were brand new to someone who has never seen it before. That same principle applies to general AI prompting work the team does across Headway, where being overly assumptive about shared context is a common failure mode.
When Figma uses a term like "replace me" for a component slot and Storybook uses "slot," the prompt needs to explicitly draw that connection. Otherwise the generated documentation will not reflect the actual relationship between design and code. Aligning terminology across both environments is foundational work that pays off the more agentic tooling gets introduced.
The difference between a design system that looks complete and one that works in production
A design system that looks polished in Figma but lacks dedicated ownership almost always has gaps in production. The team's clearest indicator of a system that works in practice is a named individual or team responsible for fielding questions, communicating changes, and keeping the system actively maintained. If everyone assumes someone else is handling it, nobody is.
For smaller teams that cannot dedicate a full hire to the design system, the recommendation is to assign someone who is genuinely interested in that work, carve out protected time for it on a recurring basis (even quarterly), and accept that partial ownership is far better than none. The design system is increasingly the linchpin for everything, and as AI tools generate more code, having a drifting or poorly governed system means the drift compounds faster.
For larger teams, the challenge shifts to governance: making sure the system does not become a bottleneck while still maintaining quality and consistency across multiple products and product teams.
Contribution models that scale without becoming a bottleneck
For enterprise teams dealing with high component request volume, multi-brand complexity, and large design organizations, the design system contribution model matters as much as the system itself. Billy shared a framework the team has used called the four Ds: decide, design, develop, and document. Each layer represents a different level of contribution that different teams can participate in based on capacity.
Contribution does not have to mean building something end-to-end. Some teams will produce a mockup and brief. Others will write the first draft of a coded component and hand it off. The teams with the most capacity can take something all the way through. What matters is that the model is clear, flexible, and not dependent on every team following the same path.
Documentation as the bottleneck
Across all contribution levels, documentation consistently slows things down. The team avoids releasing components without complete documentation, including design and development alignment and accessibility coverage, because releasing early has led to components going out of sync and requiring painful patches. Billy sees AI-assisted documentation as one of the most practical places to gain speed in the contribution cycle.
How AI design tools are changing the design-to-development handoff
The team has been testing a range of new AI-native design tools, including Figma Make, Google Stitch, Paper, and Cursor. The shift they are most focused on is moving from simulated prototypes toward prototypes built with real coded components.
Breanna described a workflow her team used on-site with a client: running multiple Figma Make instances to rapidly explore different product directions with stakeholders, then using those outputs to inform A/B testing direction before refining in Figma. The prototypes were not pixel-perfect, but they were close enough to generate real product signal quickly.
The more significant unlock is Figma Make's support for pulling in actual npm packages. Instead of AI recreating components it infers from the design file, it can now reference the actual coded components the development team uses. That means fewer discrepancies to correct before handoff and a tighter feedback loop between product, design, and engineering.
The case for designers writing code
For designers who have a background in HTML and CSS, this moment feels significant. Breanna noted that knowing code does not mean wanting to write it full-time, but it does enable better communication with engineers and creates a shared language across disciplines. The longer-term vision the team is working toward is a model where designers can implement component-level changes directly, hand them to a developer for review, and ship without a full round-trip handoff cycle.
Transcript
Breanna Shappy (00:00):
If things are not set up correctly or labeled correctly, when the AI goes to actually meld with those components, there will be errors that occur or it will just backfill whatever it finds essentially to put in those spaces. If you were to even go through and audit that, that editing process is going to be a lot more time-consuming than making sure that all of that work is done upfront.
Billy Sweetman (00:23):
Welcome to Intentcraft, a product design podcast where we dig into design systems, AI in the design process, and what it really takes to scale design for software. In this episode, we talk about what makes design systems actually work in production versus what just looks good in a Figma file. We also talk about getting your system ready for AI and agentic workflows. We dig into the gaps we see when auditing design systems, from token drift to Figma and code parity, and explore new AI tools like Figma make that are already changing the way product teams collaborate and prototype together. Now let's get into it. When we first engage with a company to really take a look at their design system, what is something like when we open up maybe their Figma file for the first time and we're auditing their design system that tells us maybe in that first 10 minutes or so, whether they're in a healthy spot or in trouble?
Melissa Gallagher (01:15):
Well, I think if I just receive a design system file as a Figma file, that's kind of my first red flag. I think you should have a contact person. There should be some sort of process documented. Even outside of Figma for the wider organization to understand the design system, that's the first thing I look for. Not just the components itself, but the whole ecosystem that keeps it afloat, make sure that it's fresh, and that if I have any questions or if anyone on the team has any questions, there's a dedicated person for me to reach out to, contact, and I just get a full understanding of how the whole system works.
Billy Sweetman (01:59):
Yeah, absolutely. Yeah. It's one of those things where if you only get a Figma library, you're like, "Well, you might not actually have a design system. We might just have a component library here."
(02:10):
And we need to dive in just a little bit deeper. I know one of the things that I think is really important now is really seeing the drift in maybe their token system and token structure. I know you usually can see a standard that might get set, but then you start to see little one-offs show up here that don't maybe go back into the system or the pattern that they've set up, or they'll have special tokens set aside for some new thing that got added. And I know early on you set your token structure, you set your token standards, you might not know everything in the beginning there, but that really shows that maybe they don't have the time to evolve their system the way they should and review that in a good maturing process. But we've seen that a little bit where there's a lot of one-off tokens here and there and they're kind of all over the place.
(03:05):
And that's usually a big indicator that they've been moving really fast and there hasn't been a consistent process there to update that or manage that effectively.
Breanna Shappy (03:16):
I think to add on a little bit, one of the key pieces with understanding a design system and its efficiency is that we've seen some teams come to us with just a Figma file and there's not a ton of representation of that work happening in development. And those development components are really, I think, what unlocks the design system because then your dev team and your design team can really play with the same Lego blocks and making sure that everyone's on the same page there. So seeing not only the Figma file for your components, your tokens and those, again, Lego blocks that you're building with is important so that you're checking to make sure your designers are in alignment, but also interfacing with the engineering side and seeing if they have a story book and then comparing and contrasting what those two environments look like and making sure that things are quite literally pixel perfect.
Billy Sweetman (04:15):
Yeah, for sure. And it's interesting too, because sometimes when we audit a storybook or we take a look at Storybook, and we've had this happen to us where you start building components in Figma that are super useful for designers, but then we never have that code parody in Storybook or it doesn't make sense for it to exist in Storybook. And you almost have to pull back a little bit because you're like, "Well, if this doesn't exist in Storybook, then it probably shouldn't exist in MyFigma library either." And I know that can be an issue, create a lot of drift and a lot of complications in the end when developers need to deliver specific things and they don't have access to that. Everyone's using AI stuff now. And I know AI has been driving a lot in the design system space and a lot of conversations around agentic AI.
(05:02):
How do we implement a design system that a human designer and maybe an AI coding agent both can use reliably? What are some things that we change with our design systems or think we should be changing so both of those customers can use them effectively?
Breanna Shappy (05:20):
I think one of the things we've been taking a look at not only within the design system space, but elsewhere is just the skill files and how we can get a agentic skill file to almost imbue the human perspective that we would apply into the skill file into that process. So I think that's really interesting and something that we've been trying out a little bit. The other piece that I think is important is making sure that things like variables, tokens, all of that can be properly ingested by the AI because if things are not set up correctly or labeled correctly, when the AI goes to actually build with those components, there will be errors that occur or it will just backfill whatever it finds essentially to put in those spaces. And that's really going to end up with, if you were to roll that out, it would give you some tech debt.
(06:19):
But if you were to even go through and audit that, that editing process is going to be a lot more time-consuming than making sure that all of that work is done upfront and that it's kind of like the dotting your I's and crossing your T's of setting up that process.
Billy Sweetman (06:34):
Yeah, absolutely. I know one thing that we've been doing right now is thinking about how our documentation changes a little bit for the design system and how do we create not only a good template for designers and developers to read, but also how do we create those additional documentation bits that maybe an AI agent or an AI model can go through and check out. I know I've been playing with the uspec plugin or the use spec plugin, which is through the Figma console MCP to see how it's generating documentation and then how it's, this will actually generate documentation for you, kind of like seeing how they're doing different things and different elements that they call out in there specifically, and then trying to see how that will help with some of the Agentic stuff that we're doing and what are some of the differences that they've been in the way they put their documentation together from what we've normally put together.
(07:33):
It's been okay at generating out documentation for our use. I still have to go in and correct a bunch of stuff and maybe the prompt that I'm putting in there isn't as good as it should be, but it is interesting to see how their system and their skill files go through and unpack your design file and then read that out into documentation. It gives me a little bit of a window of like, okay, if I need to do an AI to ingest this, how might I document that the other way around? So it's pretty cool. It's pretty easy to get set up with the Figma Console MCP and allows you to do quite a bit of stuff.
Breanna Shappy (08:10):
So Billy, I have a follow-on question. With that us spec, you mentioned you're prompting it and you have some thoughts around the prompt setup. What would you say are important pieces of the prompt to make sure that you're thinking about? And then with your experience up to this point, is there anything you would change?
Billy Sweetman (08:30):
Yeah, and they kind of call this out in their documentation because you can ask it to create anatomy and it'll go through, it'll crawl through the Figma component and it'll start to put the anatomy bits and pieces out there. But if it can't infer it from the actual component itself, it's not really going to do a good job of catching that stuff. So you have to give it the same way if you showed somebody your design system documentation and you assume these things are there because we're all designers and we've done all this before and we just know how those things work. It's not going to always know that stuff. So you have to add those additional pieces to the prompt. So we do a lot of sub-components in our components to drive structure. And so I would always have to tell it, "Hey, you need to at least go one level deeper when you're running your anatomy check," because a lot of the properties are in that second layer, it wouldn't actually check those things out.
(09:34):
And then where we use ReplaceMe components, because we don't have, well, we have access to the slot now, I would tell it like, "Hey, make sure you're correlating these to a Slot component in development so that even though in Figma we're calling it a ReplaceMe, we know in our storybook it's a slot and making sure that it draws those comparisons there." So it's just trying to give it that extra bit of context that might not be inherently discoverable on the page itself because it's not reading any of the documentation in your Figma file. So you're kind of adding that as it's generating out the documentation.
Breanna Shappy (10:10):
Cool. I think that's a good way to think about it. And I think especially within the space of you're talking about the use back prompt as the same space of if you were to give somebody who's never seen your design system before the documentation and maybe they're new to design systems, explaining it in that way so that the system understands the level of detail it needs to have. And I think that's even something that I've run into just prompting with other types of work that we're doing at Headway, the specificity that's inherent within the prompt, I think sometimes I've made assumptions about how much I need to say or how much I need to or leave out essentially. So I think that's definitely a balance that is important to Stripe is letting the system build on a film, but also being super specific about the parts that need to be very detail oriented.
Billy Sweetman (11:08):
Yeah. And I think like Sam and myself, we've been doing a lot with some of the design system work we're doing now to really ensure that everything that's in Figma is one-to-one with what's in the coded environment for obviously property names, things like that, and trying to build a good templated structure all the way through so that when we do have agentic tools running through maybe a Figma file and creating out a screen, it knows exactly what the component is, what the properties are turned on, and it can correlate those all with the developed component that it needs to compose in that correct form. And so there's a lot of making sure everything is exactly as close as possible to the exact same things in both environments, which sometimes can be a little tricky because sometimes you can't do things in Figma that you have the freedom to do in development side.
(11:59):
Yeah,
Sam Pecard (12:00):
The property naming, that was a big learning experience for us because we would set things up within Figma where it makes sense for designers to pull in. But yeah, I know that being one of the things that we had to align with the dev team was to make sure that the way we're setting those properties up and how we were naming those was more of a one-to-one to help mitigate some of that.
Billy Sweetman (12:22):
Awesome. This is kind of going back to a little bit kind of the first question we had is like, so what's the difference between a design system that looks complete and one that actually works in production and where do we normally see the gaps in one that may look complete versus one that works in production?
Melissa Gallagher (12:40):
I think a dedicated design system team, or at least one person dedicated to maintaining the design system is really critical to its success. Someone who's able to field questions, take in new requests, be able to communicate between the development team and the designers using the design system, any issues that are coming up with their components and how they're trying to use them within the screens that they're trying to solve, that's kind of the key for me of that collaboration piece, making sure that there's someone there to make sure that things are being communicated both ways. And it can include dedicated Slack channels, making sure that they're being managed properly, any changes that are coming from the design system are being communicated to the team, or open office hours, places where folks can go and ask questions. Those are kind of the pieces that need to be in place to make sure that it's successful and being used properly.
(13:46):
Yeah.
Billy Sweetman (13:46):
It's one of those things where at least the most success we've had is if everyone assumes somebody is doing it, that probably means nobody's doing it. So having somebody dedicated to kind of tackling that and making sure that all the things are happening in the correct ways, or at least there to facilitate that process. This is going to be more successful than sort of this abstract, who's doing this? I don't know. Maybe it's Jeff.
Ad (14:13):
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 and 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.
(15:11):
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.
Breanna Shappy (15:29):
I have a follow-on for you guys with regard to having that dedicated person. So imagine you were a new design leader at an organization and you don't have a dedicated design system hire. What is the best way to handle that? If you have just a team of designers, but you have a design system, how would you go about breaking out that work?
Billy Sweetman (15:50):
Yeah, I think the thing there, and we see this a lot in the design system space, is even as a small startup that maybe only has a design team of two or three people, they're still building a design system. It might be small, it might just have a tiny bit of components and functionality. It could be mostly in the design area, maybe not quite in dev yet. Maybe they're building on top of the library already. They're already doing those things. So I think finding that person who's eager to do that and just know that they're not going to get everything done all the time as fast as we might expect them, but to help maintain that system because the system really is becoming the linchpin for everything. AI is generating more code and we don't want things to drift from the brand and we want things to make sure they're staying aligned with our patterns and things that we've established.
(16:42):
We need to have that stuff ironed out, otherwise we're going to start to get that design system drift to happen. And so having an individual who's doing some of it, maybe not doing it to a full depth of a whole team dedicated to it, but I think some of it is going to be better than nobody doing any of it. And I think a lot of designers enjoy doing that work and they enjoy having that reusable library of stuff when they're doing their work. And devs, I believe too, are eager to do that work.
Melissa Gallagher (17:11):
Yeah, it's about carving time. So whether that's quarterly, if you're a small team and you have lots of irons in the fire, making sure that you carve out that time to take a look at your design system, check that it's healthy, that any updates that have come through Figma are kind of being used to its fullest potential and making sure that you are getting what you already invested in starting to build it together, kind of lose all that great work, all that groundwork that you've set when you set it up if you're not constantly going back, maintaining it, making sure that it's healthy and actually being used properly within your team.
Billy Sweetman (17:50):
Yeah. And I think on the flip side of that, I know we talked a little bit about smaller teams. I think on the flip side of that, for teams with 10 or more designers, maybe living and breathing across multiple products, there's a different challenge for how do we build a system that scales for teams that large or larger that doesn't become a bottleneck for them. You might have the resources to build everything that you need, but then it's like, how do we manage that governance and how do we manage those teams so we can effectively deliver what's needed for them? I think one of the biggest things that we've dealt with those bigger teams is thinking through, you get a lot of requests, you get a lot of component requests, a lot of products, maybe multi-brand, a lot of changes that need to come in.
(18:40):
Really leaning into an effective contribution model is very helpful and really understanding what are the different layers of contribution to the design system. I think everyone has this gold star vision that contribution is, I designed a thing, built the thing and committed it all the way through the system, but not every team has the time to do that. And so I think contribution for one team could be, here's a mock-up of what we would like and here's some documentation written up on what we think we would need this to do for their specific product and they're not going to have time to maybe do the end-to-end testing and everything for that. And then other teams, it might be like, "Hey, here's a first draft at a coding component. Can you guys bring it to the end?" And then teams that do have a little bit more time and availability, they could really flesh something out and push a PR all the way through the system that led that design system team maybe reviews.
Melissa Gallagher (19:37):
Yeah. I have a little bit of personal experience in our last engagement of being on a smaller team that was using a larger design system. We were building for iPad, which is very unique, has its own kind of quirks that not every larger design system takes into account. So what we did to help keep us agile was create a product library, very much informed by the larger design system to put together those smaller pieces of screens. And then once we found something or a pattern that really worked for us, having that communication back to the larger design system team and seeing if that's something that can be incorporated into the larger design system. So not being afraid to peel away in a sense, but you don't want to be siloed. So having those, like I mentioned, touchpoints, those channels, that dedicated person to have constant communication back that we've uncovered something and we want to contribute back to the design system for the wider team to use, but still being flexible enough that we can kind of go ahead and build something on our own.
Billy Sweetman (20:52):
Yeah. And I think for those teams, just that contribution model is so important. And we always have those huge ultra huge diagrams of what contribution looks like. And it's got a million layers and a million loops. And on one engagement, someone had asked us like, "Just give it to me simple. Give me the simplest, rawest form of contribution and what that looks like. " We did put this diagram together that we were like, "Oh, it's maybe the four Ds of design system contribution." So how do we empower teams to make decisions? Does it belong in the system? Does it not? Can they design that thing out for us? Then development, are we building it? It's going to get kicked off in the backlog. It's going to take a little time for us to get to it. Can it be faster? Well, yeah, it can be faster, but then your team maybe builds that out.
(21:45):
And then the slowest part for a lot of us is the documentation parts. And that's one thing where I'm kind of eager with some of this AI documentation thing. How do we speed that up a little bit? Because we try not to release anything without having the design and dev hand in hand with all the documentation, as many of the edge cases covered, because we've had bad experiences releasing things too early, then things get out of sync or issues that we just didn't consider come up and then we got to patch things and that always becomes kind of a nightmare.
Breanna Shappy (22:16):
I think that's important to strike a balance between too many cooks in the kitchen type of situation, but also allowing people to contribute that want to contribute, but having a process around it at the same time that balance is between your hitting those important deadlines and then understanding when it's important to add something to the backlog and it's not the right time to actually do the work to get that component into the system.
Billy Sweetman (22:42):
And I'm really eager to see, we've been talking a lot about how can we automate all the checks and balances through building out components, like how can we essentially create a design system linking tool that can check through a component to make sure it has all the bits and pieces that we need in the design space. How can we check to make sure that we've covered all the documentation bits, all the accessibility documentation? Are those things that we can automate to help us get those things done quicker and more thoroughly? So I feel there's a lot of opportunities there and we're exploring some stuff that's helping us deliver components faster and also helping people to have designs that are more compliant with the system as well. So I think all those things are beneficial to teams that have these large or large teams that are using systems across various projects.
(23:40):
Anything else that we'd like larger teams or larger enterprises struggle with design systems that we've experienced in the past?
Breanna Shappy (23:49):
One thing that we've experienced, I think with a couple of different engagements is when we have folks who have never used a design system before and an enterprise is rolling it out for the first time, or we have an existing design system that we've just set up and we have folks who are new to design systems and they're just onboarding to the organization and making sure that there's the right processes in place so that those people don't get left behind in their functional product teams or just as individuals. I think that's really important that if you do have the fortunate situation where you have budget to have a dedicated unit that's responsible for design system, making sure that a unit is running educational opportunities for either, again, if you're in the scenario where it's your organization is just adding a design system in for the first time or you're making upgrades to it, or you have folks either on engineering or design who have just joined the team and they're not familiar with the design system, setting up things like office hours so folks can go with questions, setting up learning opportunities.
(25:00):
I know we've done almost like quizzes for folks where they'll come to sessions and learn different things and then they'll have to take a mini assessment at the end. And it's really a good way to test that you've understood the curriculum, so to speak, and that you can then take it and apply it to a real world scenario. So I think those pieces are really important because I think especially at the enterprise level, making the decision to invest in a design system is a really big step that does lead to a lot of efficiency, but you need to make sure that every member of the team understands that process completely in order for it to take full effect.
Billy Sweetman (25:41):
Yeah, for sure. It's like a way of working and we've been part of training teams. Sam and Melissa, do you have any experience because you've been embedded with teams where we've been rolling out a design system and then you're on the product team helping designers who might've never used a design system before. Any things that, words of wisdom that you might have for rolling out design systems to those product designers who are new to design systems?
Melissa Gallagher (26:09):
I mean, I think it's important to really read through the documentation, see what all components have been created in their states, because I know I can fall into the, "Well, I'll just use a list item for absolutely everything." And maybe that's not the correct component to be using or I'm not using the heading correctly. So going through, seeing what is available to you at the time and how it works within a screen and just experimenting before you start putting things together is a good way to get your feet wet and have a better understanding before deadlines are looming over your head and now you have to put something together quickly.
Billy Sweetman (26:56):
Yeah, absolutely. Peskey documentation.
Melissa Gallagher (26:59):
Yeah.
Sam Pecard (27:01):
Yeah, I'd say it is interesting because a lot of the questions that I get, like you were saying, Melissa, just understanding the documentation, what components are available. Some of the systems that we work on are pretty large and I think it's just the familiarity with what components you use where, and even just how to manage those to access the different variants within a component set and how to get them to work for your specific use case. So yeah, a lot of it, just going through the documentation and putting things together and then bringing in some of those questions that you might have to the open office hours, the things that we provide to help just check those things to make sure everyone's using things properly in the right way.
Billy Sweetman (27:44):
Yeah, absolutely. I know we've all been playing around with various new design tools that are coming out. Google Stitches out. We've messed around with paper and pencil, interesting names, is different tools. We've all done a lot of Figma make experiments and user cursor and quad code, things like that. And the design tools are really starting to leverage AI more or they're natively built AI design tools. What kind of experience do y'all have having that solid design system in place with those different parts of the process with those new AI tools? And what is some of the impacts that we're seeing or speed and effectiveness of a designer within a team or even yourselves in some of the projects?
Melissa Gallagher (28:29):
I like you leveraging those tools for prototyping and being able to come up with something that is super accurate to what is ultimately going to be developed. I know there's a workflows where you can essentially go straight into development and publish, but even just using it as a communication tool to get buy-in, to help people get on board with your vision, instead of just showing them some strong together JPEGs and hoping that they get it, having them be able to interact with it in a meaningful way and see how data actually interacts instead of having that Lorim Ipsum where we have the same kind of card in every screen and hoping that they understand this is going to be live and dynamic and all the cool things that it can do, you're able as a designer to bring that to life and get people to understand what the vision is.
(29:27):
And it wasn't super readily available or it would be a real time suck to not leverage those AI tools to do that.
Billy Sweetman (29:36):
One thing that I'm kind of excited for is we've done a couple of prototypes in Figma Make, and if you got a multi-theme design system, sometimes it doesn't pick the right theme, sometimes there's some issues in there. Sometimes because it's recreating all of those components that it's pulling in from the design system, but they now have it so you can actually put Pulling your own NPM packages, so you're actually using the actual coded components, which is really nice because I think that's just going to make things go faster. You're not going to have to say, "Hey, no, please use the hover state that I originally had in there as it kind of inferred its own." Because we saw some real unlocks when we were on site with a client where we were sitting with product people and we were able to just explore a whole bunch of ideas really quickly by having a couple Figma make instances up and running.
(30:30):
We're like, "Well, what if we did this? And what if we asked you to do this and just try out all these different ideas?" And at the end, we were like, "We could probably run these past customers. AB test, which one's the best one?" Yeah, they don't look a hundred percent right, but at least that'll give us a sentiment of where to go. And then we can bring it back into design and be like, "Okay, now let's refine it. Let's make sure we have all the edge cases." And I think that's a new workflow that really is more collaborative for these larger enterprise customers where maybe it's a little less collaborative now where it's a little bit more waterfall, product makes a PRD, design gets to go do some design, maybe a research, then it gets handed off to dev, where now product and design can explore together and really create a PRD in the form of a prototype that they actually validated and tested.
Breanna Shappy (31:22):
Yeah. I think it's kind of interesting. The tools are becoming more collaborative in a sense of the ... I think previously in product design, it was very much like each segment, so product design and development all had their own lane and you just had to stay in your lane. Whereas now it's just one river that everybody's swimming in together. And as a designer, you can take things in Sigma and actually get code and then share it with the developer. And if all of that is backed by a product owner and you've collaborated on that as a group of those three disciplines, I think that really unlocks a lot because then you're going to skip the process of having to iterate of like, okay, product owner is going to give the brief to design and then design is going to iterate with product. And then once you reach a certain point, you're going to go over to engineering and then you're going to iterate some more.
(32:25):
But if you're able to use something like that, you can package. You can iterate a lot faster, but then you can also bring something to engineering that feels like it has legs and they can really understand what it is. It's using the same components that they're using in storing book. And again, Billy, to your point, it might not be perfect, but we're a lot closer than we were with our previous process.
(32:50):
And I think that'll just allow for more experimentation, but there's a lot of opportunity, I think, for really interesting experiences. Whereas I think now there is sort of a tax of like, "Oh, we can only do so much with the current process." I think AI is going to unlock a lot of opportunity with experimenting that we may not have had access to previously.
Billy Sweetman (33:13):
Yeah, absolutely. How do you guys feel about ... We talk a lot about prototyping and being able to leverage prototypes. Personally, I'm really eager for this sort of future where we're kind of building UI and we're actually using the real UI components, not like the ... I don't know, I always call it the simulation. We're building a simulation so someone else can build the real thing. And I've been really interested in paper and how they're really ... I still think it's a little bit of code on both sides, not necessarily using the actual bits and pieces from your system, but this is kind of doing what Figma is doing with CloudCode now, where you're able to pull in your actual screens, customize within there, and then push those back out to code. But how eager or how excited or how non-excited are all you to dive into the actual code and work on the actual interface?
Breanna Shappy (34:13):
I think it is both exciting and nerve-wracking. As someone who used to write HTML and CSS for a lot of my day, I don't miss it, I'm going to be honest. I do really enjoy the creative aspect of product design. However, I think that having that experience, I think knowing some code is really powerful and it does unlock this level of empowerment within the designer. And it also allows you to have better communication with your engineers, which is really important, I think, for both disciplines to speak some of the language of the other side. And the thing I can equate it to you from just design in the past, I guess, is this probably going back 15 years, maybe more, is Dreamweaver when you had the Wiziwig and you had the code up on one side, but then you had your actual design on the other side and you were making changes in the code, but then you could see what was happening.
(35:10):
And defining in that way is very interesting. I think Dreamweaver as a product was definitely an interesting space. I used it a ton. It wasn't the best, but it was a thing, and we all used it for emails and webpages and things like that. But if we could get a better version of that, and I don't know, having trust in the dev side as well for us to actually get in there and make changes and branch things and merge it back in if it looks good and having an auditing process for code reviews for designers to merge things. And again, I think that unlocks a lot of speed and efficiency, but it's just making sure that the right level of comfort is there for the designers to make the changes, but also for developers to be like, "Oh no, the designers are in our space." That type of a level of fear.
(36:04):
So they're going to break everything. So I think there's definitely a communication and collaboration branch that has to happen for that to really work well, but it's definitely exciting.
Melissa Gallagher (36:16):
Yeah. My hope is that it does make a developer's life easier and not harder. The front end is really only half the story. There's a lot happening, a lot of data that has to get sorted and understood and a lot of connections that have to be made in order to even display an image, for example, or to display the correct data point. So if we're able to make their lives a little bit easier by caring about the roundedness of the corners that we care about, I mean, I think that's exciting to see and exciting to at least try. And it's the digital era. So if we don't like it, we can change it. We'll pivot, we'll find something, new, we'll experiment. I think that's what's exciting.
Billy Sweetman (37:00):
I'm eager. Currently, the workflow is, "Hey, we need to add a new state to this component. I'll mock it up in Figma, send it over to a developer. They might code it up. We're going to do some testing. We're going to verify it together to make sure it's right, and then we're going to send it. " And it would be great if I was like, "Hey, developer, can you just make sure I didn't mess this up?" And then we could just send it. I've seen a couple of folks doing that, and I think that's a part where I would like to have a little bit more control. Yeah, I'm not going to be diving into the backend or worried about API connections or anything like that, but I definitely would like to have, "Hey, just let me rip out this new state real quick and we'll call it good." All right.
(37:38):
Well, awesome, everyone. Episode two down. Thanks for watching Intent and Craft. Want to support the show? Subscribe and try on notifications 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.