AI is changing how teams design and build interfaces, but its impact depends on the systems underneath it. Without clear structure, consistent rules, and shared context, automation can add confusion instead of speed. When paired with a design system built for scale, AI can accelerate workflows, reduce errors, and make iteration faster.
Foundations Before Automation
A design system provides a shared framework for design decisions. At Smith, key choices about typography, color, spacing, grids, corners, and shadows are captured as variables and tokens. Components are built on these tokens and include metadata that communicates design intent. This structure ensures consistency across web and mobile experiences and lays the groundwork for AI-assisted workflows.
Reusable Components and Templates
Components are designed to work independently before being combined into larger templates. For example, a recommended add-on block or a drawer component can be created in isolation, then integrated into a product page template. This approach supports composability, maintainability, and reuse. Iterative updates, such as resizing elements or toggling visibility, can be implemented quickly while keeping the system consistent.
Where AI Adds Value
AI works best when it has structure to operate within. Think about when you ask AI a question, the more information provided, the better the output. With metadata and clear rules, AI can create or update components and integrate them into templates efficiently. For example, AI can take a design element in Figma and generate the corresponding code component while preserving context and naming conventions. This reduces repetitive work, speeds up iteration, and keeps design intent intact while maintaining human oversight.
Scaling Without Losing Control
As projects grow in complexity, maintaining consistency becomes more challenging. A structured design system allows teams to scale across platforms, clients, and channels while using AI to accelerate routine tasks. When reusable components are combined with iterative updates, teams can deploy changes at scale without sacrificing quality or control.
See it in Practice
These principles come to life in a long walkthrough with Smith’s VP of Customer Experience, Jared Hochradel. This session highlights component creation, template updates, and iterative improvements using real design examples, including blocks like recommended add-ons and interactive drawers.
Watch the full video below to see these concepts in action and learn how a scalable design system can become a platform for faster, smarter design and development.
Transcript:
00:07 – You know, at Smith, we’ve been kind of talking about the importance of design systems for a long time. We have lots of IP that we’ve built out over the years that have helped us as we make large scale ecommerce applications and complex commerce experiences across web, but also mobile apps and that kind of thing for consumers and also businesses. So different use cases and different complexities with that. And we’ve built this system out that gives us kind of ultimate flexibility between clients and gives us a base of our starter to work with.
00:46 – There’s lots of different mechanisms that were included in here. Everything is based off Tailwind, which are base CSS properties that we use that are kind of a pretty familiar developer friendly framework. Those are ultimately used as variables that allow us to do things like light and dark modes, different themes that we can put together for different clients, and then control things like how the devices change different breakpoints and different variables that get used for different widths of devices and that kind of thing.
01:29 – So all this information are tons of decisions that teams make commonly. We need to make decisions about what we call things about the size of things that show up in our interfaces. So what is typography and what does that stack, and what are the properties involved with that? And how does that scale gracefully across the interfaces? How do we use color both at their primitive level for like brand inputs and base level tokens that our clients have as their brand guidelines? And then how do we use them semantically within the interface to use them in different ways to express the UI, how it should work.
02:13 – How do we decide on how we use the grid and how different elements move around the website? How do we align on corners? How do we align on shadows in the way that depth is presented within our UI? So what we’ve done is abstracted a lot of these decisions that are commonly made on the types of projects that we work on, and built out a system of variables that allow us to gracefully treat design as data and present this as even JSON objects and all this hard work that we’ve been doing.
02:49 – Best practices of building out design systems, building out components that are well structured that use those lower level components and tokens in their architecture, and really sophisticated instructions and properties that get exposed to help us indicate the different ways that that component might behave in an interface, and the different properties that that has that we can kind of send. Turn button on, buttons true, buttons false, labels false, labels true. The button type is this, the button types that, and these decisions scale and combine when we think about what’s been coined as atomic design. And as these decisions start to layer and we build bigger and bigger objects and how those objects are reused within our interfaces and our products.
03:52 – So over time, we’ve built out a lot of these things. We’ve built them the right way. There’s tons of metadata that are included within them that allow us to send this and naturally work with AI in a great way. So what I’m gonna show today is kind of like what we’re calling like agent to UI workflow. And we’ve got our design system here, like I showed with that foundation of a fabric of different variables and hooks that do different things to my interface in different ways.
04:34 – I’ve got these low level components that we’ve built out, and a mirror of these low level components in code. And then I’ve got starter pages that we use as kind of our basis as we make site to site and different common use cases that get presented in those. So if one of our examples is like a product page here, and this is one way a product page may show up, and for example, I’m working on a product team and we’ve got a new requirement of a new feature that comes in to maybe add services to this product. So not just buying this product here, but being able to like add on a warranty or something else.
05:20 – So you’ll see above here, I’ve prepared a new page that has that product up here and the idea of maybe those services or those add-ons below. And what I’ll do is show how we take it from Figma here, going into dev mode, using some prompting but also using the connection of Figma’s MCP server that I’ve enabled and how that allows me to grab all the details, all that time that we’ve invested into this product over time, all those best practices in terms of the Tailwind tokens and the variables being stored within these objects.
06:08 – All of this stuff, all of this meta information now can be communicated to a computer and it can get all of our intent, our design intent captured over to a real live coded component. And when I click on these info buttons, it’s gonna bring in this drawer, which is another core component within our component library. If we were to look over here, we’ve got a drawer component. This is kind of the architecture of it. These are examples, and we’ll be calling upon this to kind of make this demo happen as well.
06:52 – The other things that I’ll show is kind of where a lot of these components are rendered in our front end workshop Storybook. So just like I was showing in the Figma file, we have a comparable of all those same exact variables, represented as live code and all these objects also were rendered through AI using our design system object by object from the bottom, working up to an experience that gets presented.
07:24 – So when we were on that foundation page, looking at those decisions that get made across how is my display hierarchy working, heading text, different hooks that are available to us, but then to some of those elements that I was just showing you, right? So that button, what does that look like? Again, when those things are true or when they’re false or those different properties that I have available. So that’s what we call stack mirroring is I can take something in here and it’s the same exact object of materials as what’s over there in the code.
08:03 – And that’s one thing that we preach very strongly as we are navigating AI and how we introduce it into our workflow. The biggest thing that slows teams down is consistency, and kind of having to translate each other’s work. So by having this stack mirroring of what’s in my world is literally the same thing you call it in your world, it allows us for some really awesome velocity, and ultimately being able to do better things, cooler things for our clients faster and in better ways. And we have a lot more fun when we’re doing it too.
08:43 – I’m gonna take this object over here. You’ll see that there’s a state for it. Again, when we explore this component, there’s the initial state for it, but then what does that look like when one or more services are added? So that’s kind of what this base level component does. It’s architected from lower level atomic elements. So it has the button component there, it has the divider, it has my typography, it has my spacing, variables, et cetera.
09:12 – So when I go over to Cursor that has my entire code base within it, and I’ve got again, all those blocks and all those elements right here would be the comparable of that button we were just looking at. So when I was talking about like the types, there’s a default button, there’s an outline style, there’s a destructive style. This is how those elements are visualized in code. BG primary, text primary foreground, a shadow in the extra large, extra small style. And when it’s hovered use background primary, but do it in its 90/10.
09:56 – So it’s really cool when you know us as designers are like, you’re using the same things that I do over here. What is that? It’s my text foreground. What is that? It’s my text primary. So this allows us to have, again, that parity between what I’m calling things and what you’re calling things in your systems. And it gives us some really powerful things. Typography label small class, this stuff’s powerful because it allows us to not be the translator between the system and allows us to take this input or this intention that we’ve gathered into this all this metadata and translate that over to a real object.
10:38 – So I’m gonna come over here. This again, is a mirror of what I was just showing in Storybook. It’s my code base. It has all of my lower level UI as well as blocks like that buy box we were just looking at on that PDP. And when we go a little bit higher and look at the presentation of a PDP, you’ll see that’s what I was just showing you in Figma. So it’s the real thing that we were just looking at in my code right now.
11:09 – I do not have a component here for this service component when I tab back over to my Storybook, it’s the same exact thing that we’re looking at. So that’s the reality of what my code looks like. And now my Figma file is kind of out of sync with what may be this new template that we’re considering as a product team to incorporate into our code base.
11:33 – So I’m gonna take this here, I’m gonna go into dev mode, I’m gonna copy the prompt. I’m gonna go over to Cursor, which is an IDE that has agents in the mix, which is really cool. These agents can perform actions for me. But the importance here is it’s not me going to ChatGPT or Claude in isolation and saying, make me this button based on this screenshot, because what it does there, it has no intent, it has no understanding of the context of my code base.
12:07 – Whereas here in this IDE having an agent alongside me and awareness of my entire code base, what it’s gonna do is what’s called grepping. So it looks at all the previous patterns and ways I’ve done things and respects that as it starts to make new things for me. So the rules and the ways, all that intention, all those things that we’ve spent so much time getting right and getting buttoned up for that consistency. You’ll see how it pays off within the UI here. And then we’ll also create a Storybook story so that we can visualize this update to the PDP.
12:54 – So I’m gonna come right here to my chat. I’m gonna post that, I’m gonna call it, add this to the blocks section, call it the recommended add-on block for services. And also make a Storybook story with toggles and properties to expose. So what it’s doing is it’s first asking me can I get design context? So can I really, can you give me permission to read your Figma file? Yep. So it’s looking at that node specifically, it’s getting the design context.
13:43 – So now that it has permission to Figma, now I’m giving it permission to that exact file and that exact node, it just pulled a screenshot from my Figma into the code base here just to give it reference. But again, it has all the layers of information within here. It just built out my component for that recommended add-on component. And it just built that story. It’s re-reviewing it, it’s linting it right now. So linting is reviewing it based on rules that I have in my code base, kinda like a spell check, seeing if there’s anything that it’s not passing.
14:25 – It just did that. It found a couple things that it could have fixed. It gave me a little add-on and a readout of what was just made. It made the component of recommended add-ons and it made a Storybook story for me. So that’s pretty amazing. Let’s see how well it did it. I’m in Storybook, refresh, which it might not necessarily need to do, but you’ll see here now I’ve got that recommended add-on component and it’s isolated. And now I can use that when I want to add it to a given page template.
15:02 – So when I think about the product detail page template, right? It has a media gallery component, it has a buy box component, it has an extended product content. These are accordions. So you’ll see that these are just little blocks that get combined to stitch together. And by isolating these components and working in them on isolated bits and then combining them together, it gives us really strong composability.
15:36 – So if I go back over to my recommended add-on, this is gonna be that thing. I can kind of toggle it between my light modes and my dark modes. Kind of verify that works well. One thing you may notice is like that info tooltip doesn’t look as nice as it did in Figma that was smaller. So that’s kind of a cool little thing that I can do, is the info tooltip is too large, make it 12 by 12 and I’ll give it that kind of discreet instruction. It’s going to go in there immediately. It’s going to fix it for me ’cause it’s amazing.
16:11 – I can review it, double check it, look at the before and after on the diff of that code, see where that was altered, which is really cool. I can accept it, keep it, commit it, and right there in two seconds. Now my component is fixed with just some simple English, telling it exactly what’s going on. So by default, what does it look like when there’s one selected? What does it look like when there’s all selected?
16:53 – This is presented in documentation over here. So what’s cool is all these are individual strings within the component. It’s an API that I’ve made for this given component. So I can say Smith’s service component, just as an example of strings that are available to me that I can change that I’ve exposed as a developer to give authors or different other developers that are using it within their code base flexibility and different properties that they can turn on. Kind of like when I go back to that button example, I had a property to turn on an icon in the beginning and an icon to turn it on at the end.
17:31 – And those are just strings that I determine when I’m creating a component or deciding and working with the larger team. What properties should be available to me with this given element? And how does it scale out in different use cases? So help me or get support or whatever, those things are and the different options. Those are all different booleans that we can turn on and off. And the down here are different stories that represent the different states of what that given component may look like and how it may work when you look at it and work with it.
18:10 – So the second one that we wanted to build out was that drawer. And we’ve got plenty drawer components on the site. There’s a drawer lower level UI component over here that I can use in different ways. This one’s like maybe a dialogue on desktop, but when I resize my screen, it turns into a mobile drawer. There’s different properties that it’s kind of showing to me based on what I wanna use for that.
18:47 – If I come back over to Figma, I’ll do the same thing. Copy this, go to Cursor. I’m gonna close this chat because now, or I’m gonna open a new chat ’cause now I have a new set of context to give it. Now create a block story for this drawer. This will work in conjunction with the recommended add-on block. When users click the info tooltip in the component, it will open this drawer of more information.