Design systems aren’t just a UI toolkit—they’re the backbone of digital product creation and management. In this episode, engineer and researcher Steve Dodier-Lazaro joins Chris Strahl to unpack why treating design systems like standalone products is holding teams back. They explore what it really takes to scale product design and development in enterprise environments—from shared tooling and token standards to how AI and LLMs can bridge messy, real-world workflows.
In this episode:
- Why design systems are dependencies, not deliverables
- Tools and standards shaping the future of digital production
- How AI will reshape the infrastructure behind design and engineering
-
Guest
Steve Dodier-Lazaro is a freelance software engineer specialised in design systems and frontend development based in Seine Saint-Denis, France. Steve is dedicated to advancing the design system tooling ecosystem through his open-source contributions as a community advocate, addon author and contributor to Storybook, and through projects around design token tooling.
Transcript
Chris Strahl [00:00:00]:
Hi, welcome to the Design Systems Podcast. This is the place where we explore where design, development and product overlap. Hear from experts about their experiences and the lessons they've learned along the way, and get insights into the latest trends impacting digital product development and design systems from the people who pioneered the industry. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.coud. If you want to get in touch with the show, ask some questions, or tell us what you think, send us a message over on LinkedIn. You can find a direct link to our page in the show notes. We'd love to hear from you.
Hey, everyone. Welcome to the Design Systems Podcast. I'm your host, Chris Strahl. Today I'm here with Steve Dodier-Lazaro. Steve, I'm going to let you introduce yourself because you have a really interesting background. You do a lot of academic research, you've worked in a lot of companies. Ostensibly you're a software engineer, but you said yourself you don't necessarily like to define yourself by that work. So tell us a little about who you are.
Steve Dodier-Lazaro [00:00:48]:
Right. So, hi, pleased to be with you, Chris. Thanks for having me.
Chris Strahl [00:00:52]:
Yeah.
Steve Dodier-Lazaro [00:00:52]:
Like you said, I'm an engineer by training, but I believe that I've dabbled in a few different trades. And generally speaking, the nature of work is changing. We're not necessarily staying in roles nowadays as much as we were before. My interest in software is really that I'm interested in how technology interplays with people and how people, individuals, can use technology to fulfill their goals, to be creative or to be productive as individuals, and then, of course, as collectives. I think it's always fascinating to see how people can build ways of working, set up tools and infrastructure that help them get something done together. So I dabbled in research. I worked on a PhD that was very much about how we appropriate technology and what makes technology useful. And that's kind of how for me, going to design systems, going to UX design, and to software engineering was a natural fit because it's really about getting groups of people that don't speak the same language, that don't have the same understanding of a job and of product craft, to talk together, to work together, and to understand each other.
Chris Strahl [00:02:00]:
I love all this. At heart, I still have a piece of my brain that lives in this really heady academic space that makes me just brim with joy every time I get to talk about topics like this, because some of the most talented engineers I've ever met got their start in language, human Language and the way that people talk to each other. I think it is really interesting that your lean into systems comes a lot from your idea of like, how do we express systematic interaction between humans and the technology we use. Tell me just a little bit more about the focus here. When you think about this in terms of your own personal journey into this space. How did you get here? And kind of like show us the meandering path you took to get into a place where design and systems are so much of a focus.Steve Dodier-Lazaro [00:02:50]:
What you do design systems by and large, the word system here for me resonates with ecosystem. I have decided to leave academia and to return to industry because I very much like the collaborative nature of software work and product work as well. Whereas academia, as I'm sure you know, is a bit more of an individual journey, which is very much about competition with each other. You have to fight for money a lot more than you spend time actually going after the things that make you passionate. So I just decided to leave that behind me. Design systems I guess it kind of happened when I moved back to France. I had a team of people building software for chemists and biologists, software for chemical regulation, healthcare regulation. And they needed someone who could both kind of spearhead the UX effort and help the team build design knowledge, and someone who could also be a software engineer and a front end engineer.
Steve Dodier-Lazaro [00:03:46]:
And this was just as design systems were starting to appear. It was just when people were starting to use these words back in 2017. So I've helped that organization build product processes, design processes, build assets for design that matched the components that we're developing in ui. And you would be right to say, well, that's starting to sound like a design system, right? I never really left that niche. I find it fascinating and I think also now we're tackling bigger problems, which I'm sure we're going to be talking about, that have been slowly focusing on tools and infrastructure more and more rather than just UI components.
Chris Strahl [00:04:24]:
So when I think about like design systems as infrastructure, what I really mean with that is we've had this lens for so long of, hey, like we're making design systems for people. There are these big, you know, beautiful things that are a product in and of themselves. And there are elements of that that I feel like are really true. But when I look at like what the purpose is that these systems ultimately serve is the empowerment of others. And in that empowerment of others, that feels a lot more like infrastructure where I'm enabling somebody to do something I wouldn't Otherwise expect them to be able to do, or it would take them a tremendous amount of effort to go and do. And I really like that framing for the systems.
Steve Dodier-Lazaro [00:05:04]:
And I would say in particular, you are asking people to depend on you. You are building dependencies because you're providing some of the things that will be part of the chain of deliverables and assets and processes that are necessary to push something to production as a software team. And if people depend on you, then you need to be dependable as well. For me, this is in that sense that design systems are the most a piece of infrastructure. And it's in that sense that they differ from a product. You could buy a product off the shelf and it could become a bit outdated and still be useful. But you can't really just have an infrastructure that disappears. And I'm sure many of the design system teams out there will relate to this if there's nobody to maintain the design system libraries and something goes wrong in production and that root cause for the issuing production is in the design system and how do you fix it? So in that sense, for me, it very much is a piece of infrastructure.
Steve Dodier-Lazaro [00:05:56]:
And it's important to understand how the capacity that we have to maintain it relates to the benefits that we provide to our consumers.
Chris Strahl [00:06:05]:
That's a great take when you think about that capacity or that ability to force multiply for that consumer. That to me is the alignment to value that is so difficult sometimes to articulate inside of these big companies. And it's because we get wrapped up in the idea of how many components do we have, or what is the token set and inheritance model and all this other stuff like that, when really the purpose we're all trying to serve is how do you create value across all of the consumers of the system, not just for the people making the system itself.
Steve Dodier-Lazaro [00:06:40]:
One of the key avenues for the future of design systems as a community by notch is how can we share what we've been building? How can we harness the work that we've been doing in different organizations? A lot of the work that we do is highly specialized, is specialized because every organization works differently and every team has different ways of working and different technologies and different needs. But in that highly specialized work that we do to build tools for our teams, there are recurring patterns. And I fear that engineers who work in design systems, work in developer experience, don't spend enough time sharing what they're doing to the broader community. And they don't spend enough time just putting things out there that they've been doing because it often feels like it's so close to the way that your organization operates. Surely it must stay private. My mission, my North Star, is how can we build ecosystems of tools that we can reuse so that we can get more done and so that we can go further together as a community and provide more value. I think the key to making design system more useful is to share and to build more robust tools.
Chris Strahl [00:07:51]:
So when you think about like this idea that you have this ecosystem of tooling that is out there, that's published, that sounds a lot like open source, that sounds a lot like knowledge sharing, that sounds a lot like building a community around this type of work. And I couldn't agree with you more that we need to be better at explaining these sorts of things and these sorts of ways of working to other people. One of the reasons why at Knapsack we do patterns events where we go and try to get a bunch of people that are good at this stuff in a room together, is because we see so much value in the intersection of various different companies that are really meaningful in their space. Talking with other various different companies that are also meaningful in a different space about these ways of working and that cross pollinization has real benefits to the way that we build software. I think that what your goal is really on this is like how does that get supported with tools? And in the case that it's supported with tools, what does the ideal ecosystem in your mind look like?
Steve Dodier-Lazaro [00:08:54]:
Right. So I think the prime example of a successful open source tool in our space is that dictionary. And it started off as an Amazon project, right, with a single engineer building it and its primary competitor Terrazzo. It's a small collective, but very much of the work is done by a single engineer working at Figma. And these tools have been used by tens of thousands of people. Well, Storybook is another obvious example and I think there are a few other documentation tools out there. But Storybook has grown to such an extent now where 40 to 50% of front end engineers use it. And this tools enable so much, right? Building live showcase documentation for components without Storybook would be nigh impossible for most companies.
Steve Dodier-Lazaro[00:09:34]:
Tokenizing properly would be impossible as well without Style Dictionary. And a little bit after these successful tools, we see something emerge. We see a standards working group at the W3C working design tokens and I think they're all doing fantastic work. My interest specifically at the moment is we have a lot of tailor made tools for design tokens. I know some people at Adobe have design token diffing tools for instance, that they use. A lot of people have been building their own tailored documentation for design tokens and there is to some extent in general design system products, there is an attempt at making a general design token documentation. And one of the difficulties that we have, I think it is true for design tokens and it is true for components as well in building these tools is the data that they need to consume often comes with a very organization tailored, very specific format. It is difficult to build a token documentation tool that works for any type of design token out there, because even though there is a standard for source design tokens, there are still so many things that are not standardized and there's still so much variation in the content that we have.
Chris Strahl [00:10:41]:
There's a lot of sources too. I think that this is one of the things that has been a challenge for us at Knapsack is so we support Style Dictionary, we work with Token Studio, we work with figma, we work with all these different sort of ecosystems that exist, but there's different use cases and different groups that are attached to each of those different ecosystems. So if you're in FIGMA natively, you're using variables and modes. And so in that case that is somewhat misaligned to the W3C spec and that is then also somewhat difficult to translate into Style Dictionary. And then ultimately there's lots of different exports and transformations that you can do to get things into a finalized format, but there's a lot of work there and that ecosystem of tooling is anything but seamless. In the case where we're trying to basically say, how do you take something that exists in a FIGMA file and make that something that ultimately gets implemented in code? That's still a bit of a Gordian knot of a process. And the reason why is twofold. First, everybody thinks they're doing it the right way, and it's all well intentioned here, but the second side of it is, is that a lot of this stuff gets defined in multiple places.
Chris Strahl [00:12:00]:
In figma, you're defining very visual elements, you're defining things like color and type and whatnot. But if you're actually talking about token implementations in code, you think about things like states, you're thinking about things like animations, you're thinking about all of these things that are ultimately like not definable in a variables and modes context. Ultimately what everybody's trying to make is a system that works in code. And the last mile is always the same, but how you get there can be higher, highly varied, and that's in my opinion, really difficult to manage. If you're any person sitting there as like, you know, a principal engineer or a staff designer or somebody in the UX organization and you're looking at this problem, it feels hard. And I think that like what you're saying is it shouldn't be.
Steve Dodier-Lazaro [00:12:50]:
Yeah. So backtracking a little bit on what you said, I wouldn't necessarily say that people think they're doing it the right way, but that the whole space is so complex and you have so much that you need to do in order to bring all your design data into actionable code assets that you end up having to figure things out as you go. And so you end up with this highly specific tools and scripts and you can't really reuse them and you can't really share them. What I care to develop at the moment is a layer of abstraction that allows tool makers, people who work on things like design token documentation, pull request assistance, Lintus IDE plugins. I want them to have a way to bridge together the source knowledge, the source tokens that you know are supposed to follow the W3C format that are in FIGMA open parts with the build design tokens that we find under a very, very wide variety of formats in software. And there isn't something at the moment that really addresses that need. So I've been working with the Terrazzo maintainer to build basically build a proposal for an interchange format that would allow us to bridge resource tokens that we have in figma with the build tokens that we produce with token translators like Stylistry and Terazzo. So we're talking to a few tool makers.
Steve Dodier-Lazaro [00:14:06]:
I know that this has been relevant to the first FIGMA MCP server that was developed by Graham Lipsman because it kept having GitHub issues come up. Figma MCP is great, but my FIGMA variables aren't translated properly and of course they aren't because this is all so specific. And if there's one thing that we know about the engineering teams is they really care to have their own vision for their own conventions and their own naming patterns. So this is not something that you can standardize from top to bottom.
Chris Strahl [00:14:34]:
Absolutely. And like that's in and of itself a crazy problem, especially in like big multi brand ecosystems. You know, anytime that you're sitting there introducing like some additional layering into your kind of implicit definition of what a token is, you're adding an order of magnitude of complexity. We have customers with tens of thousands of tokens and in the tens of Thousands of tokens, numbers. It starts to be more than a human being can, like, hold in their head in terms of how those values get used. And thus you have to have some convention that's attached to it that gives people a structure so they can understand it. And I can't even imagine being in a place where you're just like, I'm Figma or I'm Style Dictionary, and I want to basically say, like, let's solve that problem for everybody. I just don't know if that's possible.
Steve Dodier-Lazaro [00:15:21]:
I don't think it should be a goal. One thing that is obvious with Storybook, for instance, is Storybook itself cannot define how front end frameworks should work, right? We need to have bridges so that the people who develop the framework can provide the right structure and the v right mapping between the Storybook abstractions and the framework abstractions so that it all works together and that all of Storybook's added value propositions are available to the framework's users. And I think it's the same with design tokens. We need that glue that allows us to understand how a design token exists in a code base so that all the tools around developers and all the tools around translating design tokens can benefit from that data.
Chris Strahl [00:15:58]:
So in your mind, what is the form that that takes? Because we talked a little bit about LLMs and AI here, we talked about MCP. When we think about how do we extract the right design information or the right styling information about our intention, and then apply that in these big, complex ecosystems. Is that an LLM problem? Is that a human problem? What does that form look like in your mind?
Steve Dodier-Lazaro [00:16:25]:
I think LLMs are uniquely positioned to help us here. So if I were to talk about what design tokens are, they are famously introduced as being key value pairs, right? You have names and you have hard coded values, and then you can use them to have colors and typography and whatnot. But there are a lot more than that. Within the token system itself, within the data that you have, you often have a hierarchy that informs you on a lot of implicit constraints and rules, right? You have a specific background that goes with a specific foreground and so on. But you also have something that lives kind of on the sidelines, which is usage guidelines and design guidelines. Something as ambiguous as if you have a component that has a primary and secondary variant, the primary variant should have a higher contrast. And when I'm saying higher contrast, is it that the foreground and background have more contrast within the component, or is it that it has more contrast to the surrounding environment. And any seasoned designer would interpret this properly.
Steve Dodier-Lazaro [00:17:24]:
But it's natural text, it's ambiguous, it's completely disconnected from the formal structured data that we can use as engineers. And I think LLMs have this unique opportunity about them. They are general language models. They can understand ambiguous content, they can contextualize it to a specific problem. So they can make use of the guidelines if we give them to the LLMs. And at the same time, with MCPS, we can provide exact mappings of data and exact content to reason on or to test against. Right? One of the things that makes AI so much better is when you give them hard truth and you tell them to check what they've produced against the hard truth and to adjust, say, linters. If you have a linter, your IDE is going to produce much better code than if you don't have it.
Chris Strahl [00:18:10]:
It is interesting to hear you talk about this because it's like you have the data and then you have the rules, right? You have the context and the constraints. Those are very similar in a conceptual model, whether that's about humans or about an LLM. And so I have a tendency to feel like we're on the right track here, where if we say our key value pairs as tokens are the data in the context and our rules, our usage guidelines, our documentation is our constraint model, that's very close to being able to say, like, here's a machine that can be built on top of an LLM that can interpret that at scale. I think that the scariest thing about that is that usage guidelines are oftentimes challenging. They're inconsistent, they vary so much from place to place. Are we talking about the ability to create like a constraint model for how we think about the implementation of tokens that is maybe not made for humans, but probably could be readable by humans, but is actually made for LLMs?
Steve Dodier-Lazaro [00:19:08]:
I think one of the earlier challenges that we could solve with AIs is understanding inconsistencies in practice. Because when you have a design guidelines and when you actually pull the design data and you compare it, you can see that some components don't fall of a guide guidelines. You could probably then have AIs try to reformulate the guidelines to account for use cases that continue to occur, use cases that happen to be patterns that haven't been identified yet. Or AIs could also propose alternative renditions of a UI component that try and follow more closely the constraint set that you've provided. I think all of that can be explored in a sense that is what expert system designers are doing. This is why we have a centralized teams that take the time and effort to produce consistency by auditing, by curating. So I think we could assist ourselves with tools. And just the same way what I was saying, if we had more open source tools and if we had better open source tools, we engineers could do more, then designers could do more if they had the tools to help them.
Chris Strahl [00:20:09]:
Hey everyone, I'd like to take a quick break and tell you about Knapsack's leadership summits. Every month we host an exclusive in person event in different cities all around the country, bringing together design, engineering and product leaders. These summits are are all about sharing our learning with tailored discussions to address the challenges you're facing. The best part, it's totally free. Head over to Knapsack Cloud events to find an upcoming summit near you and apply to join us. We'd love to see you there. It is interesting being the CEO of what is an ostensibly proprietary SaaS platform. One of the things that I think a lot about is, is what are the ways that we can provide tooling to the community that ultimately makes the whole ecosystem more viable, more valuable? Because I think one of the risks that we run in this is we end up in a world where instead of having some sort of systematic approach to the way that we use AI to manage brand or componentry or any of the systems concepts we have, we're doing a lot of reinvention.
Chris Strahl [00:21:14]:
And that reinvention is going to be based on the very small fractional number of systems that are out there that are open. And so I do think a lot about kind of the two sides of this, right? Like what is the data structures and the explicit definitions of things that we need to have out there in the ecosystem. And then what are the more natural language, unstructured data things that represent those usage and those constraints. And how do we get a system out there that ultimately people love, want to use, want to adopt that isn't just another conflicting standard with everything that exists today. My approach on this has largely been about the idea of how we provide context is really, really powerful. You can open up MCP servers that can do a lot of work to understand how that context applies to the problem you're trying to solve. But the thing that still feels like it's really missing to me is like this workflow constraint model that could exist and that needs to be some more explicit definition of how a token is used or how a pattern is used that isn't as unstructured as does my brand go first? Does my function go first? What in my dot naming convention implies usage here?
Steve Dodier-Lazaro [00:22:30]:
I think generally speaking we are not at a stage yet, and we probably will never be at a stage where they can be a universal way to define a token architecture or to make another parallel to define the API of a bunch of components. I firmly believe that the best way that we can support our community and get things to emerge that then will trigger new ideas is having these translations between these different tools that are influential in their spaces. So another topic that truly interests me is how do you translate Figma's code connect with storybooks archetypes and with a different typing system that exists in front end frameworks? And is there a way that we can either construct these mappings or at least partially construct these mappings with the data that we're able to pull out? And I think there is, because there are so many people who are working on translating design to code and translating code to design. Famously in France, Steve Riots has done so many experiments in that space. And then of course, AI can help bridge the gap by providing the capability, probabilistic capability, to understand the ambiguity and the edge cases and provide a mapping for them.
Chris Strahl [00:23:39]:
So thinking back 20 years ago, when I was writing a lot more software than I write today, people were like, we're never going to solve version control. Like, everybody's always going to have their own system for version control. There's always going to be too much convention for us to really be able to solve this. People made attempts where we got like sember and everything else like that. That was a part of those early attempts to go solve what felt like an intractable problem. And then git comes along and solves change control and with it a lot of version management. Are we just waiting for our git or is this a truly intractable problem that we feel like we're not going to be able to get to or git over?
Steve Dodier-Lazaro [00:24:21]:
I would say the first step is we need to put that data out there. We need to get people to show how they work and then we need to see what ends up working for most people and what are variations that are frequent, recurrent, so that, you know, they should be supported in any kind of standard or any kind of product offering that people want to fraud the community. So right now there are areas where there's a strong interest in mapping design and engineering, where there's both structured and unstructured ambiguous data, where we have the tools to actually tackle those problems, but where we don't have enough collective experience or enough visibility for the people who have been working in that space. And I think this is where we should focus right now as a community. And then to go back to what you were saying, I don't think there will ever be a product offering or a way to work. And generally speaking, when we extend a little bit the problem of crafting software or crafting digital products to all the other aspects that are not design and engineering, we start understanding that we need to connect to existing knowledge systems. We need to connect to the way that organizations work and AI and humans and probably some formats and protocols and standards can all be parts of how these connections happen.
Chris Strahl [00:25:31]:
So that's actually my hypothesis on what the product is, right, Is it's the product that can sit there and say, let me go examine all of the work your organization has done, all the ways of working that you have as a company, all that provenance and history, gather that all up and then define a set of constraints for you. And that constraint set is based on what came before. And also an ever evolving kind of look at how your organization builds software. And that is not a one size fits all thing. Like your system is going to be different than my system, it's going to be different than somebody else's system. But at the same time, that's still the systematic way that is kind of ever evolving and that looks at how that software gets built. And I agree, like the areas of research right now or like what people are doing in industry to go solve this problem is fascinating. I love the Div Riot stuff.
Chris Strahl [00:26:24]:
I love a lot of the ways that these different companies and these different organizations are pouring themselves into understanding how we go from something that is boxes on a canvas imbued with glorious purpose to code that a user can see in a way, web browser. And all of that is really, really powerful at understanding how these systems should work and should function. But ultimately the difference between those systems and say like Prompt engineering and Cursor or Windsurf or whatever is the fact that we have an understanding of a codified system of constraints that is more about how we build software as a company than necessarily like the output of the LLM. And in that, how we build that experience, that way of working, that's how you actually ship software in big companies. Don't get me wrong, I'm not like shitting on Cursor or Windsurf or anything like that. We use those tools here. But that's a thing that it provides a piece of value to an individual developer or person trying to write that line of code. But like, what provides the organizational value to how we actually ship software as a company is a lot of those ways of working that you're talking about that are very individual and kind of difficult to codify.
Steve Dodier-Lazaro [00:27:40]:
One of the main challenges we're going to be facing is that workflows ways of working, they're not particularly observable. They take shape through many different pieces of software and many different acts of communication as well, across multiple channels. And it's very difficult, I believe, to extract or understand the workflows that are actually in use in an organization. And in most organizations, what is defined and what actually happens tends to be different. But we can.
Chris Strahl [00:28:08]:
Yeah, nobody's ever experienced that. That's. Listen to this podcast. Yes, right.
Steve Dodier-Lazaro [00:28:12]:
I think there's a difficulty here, and that's why I believe that creating tools that empower people to answer questions effectively, efficiently, or to get started with a code, or to review audit consistency in a system of assets or deliverables like components, icons, tokens, I think that has value because it doesn't really depend on that observability problem. In a large organization, you will have things like accessibility guidelines, brand guidelines, content guidelines, localization, you would have testing practices. You always have some of that stuff that is defined to an extent. Right. In ticketing systems, you have so many details over the status of things and then you have GitHub, GitLab and so on. I think to some extent it should be possible to build tools that just kind of try and answer questions rather than necessarily provide a whole roadmap of how every worker should intervene on the pipeline to get something produced. I think that would be more tractable because at least we can make that information more broadly available and we can make it queryable.
Chris Strahl [00:29:17]:
I think it is interesting to think about this in terms of, you know, there's a bit of a divorce from how companies say they work and how they actually work and how software gets built versus the way we theoretically think about building software. And a lot of it is based in value system. Right. There's lots of companies that talk about value and accessibility, but when it comes time to actually implement that, that's expensive, it's time consuming, and it's rather difficult. And so there is maybe this ability to say, hey, what we can observe from a reasoning standpoint is you have the stated goal of our systems need to be accessible. But based on us examining every commit that you've made into your git repository and all the ways that you've designed in your figma file. The reality is like you're not valuing this. You're getting a 2 out of 10 instead of the 8 out of 10 that is your goal.
Chris Strahl [00:30:06]:
There's some interesting kind of ideas around how that could go help us improve adherence between the way of working and what we have as stated goals. I do want to dive a little bit more deeply into the infrastructure part of this. When we think about things like MCP servers or the way that we interpret data inside of these systems, you seem to have a really strong vision for the future of what that looks like. And I kind of like to explore that in a little bit more depth. And that could include the workflow pieces that we're talking about. But I want to kind of understand like, look, if you're talking about the system, that is going to be the way we power how we build product five years from now, what does that look like in your mind?
Steve Dodier-Lazaro [00:30:47]:
It look, I think design systems are knowledge repositories and they're repositories of this ambiguous language based knowledge that we curate and we put forward and we try and distribute. And there are also repositories of artifacts that are produced with this knowledge, Design tokens, components, APIs, design guidelines, templates and whatnot. I think a key goal that design system teams should have is to distribute that knowledge as widely as possible. Where AI comes in and creates new opportunities is if we can provide all of our knowledge, right? So the ambiguous and destructured knowledge, if we can provide it in some sort of API or in some sort of standardized formatted structure so that AI can access it, then we can develop many other tools around it. And of course if we do that, we can also develop non AI tools when it makes sense. So I think the best service that we can do ourselves as teams is to store our knowledge in ways that we can retrieve it later and that we can make it available and enable other usages. And I would just like to quote Paul Dorisch, just so we have a little bit of an academia moment here. So he's been working some 20, 30 years ago on context in software.
Steve Dodier-Lazaro [00:31:59]:
Does it make sense to model the different contexts of use of a software? And what he's been saying and what a few other researchers have been saying is it's more interesting to make the context of a system of a machine available to the person so that they can reconfigure it for their needs. And the parallel withdraw is if we make our data, our knowledge available, then we can have People tap into the data and knowledge and say to the AI, well, in that specific design context, I'm actually not designing for the product, I'm designing for some other kind of usage. Say, for instance, I'm building a marketing event website. So it makes sense that you adjust a little bit all of the design data that you have and all of the guidelines that you have from a specific context, and then VA is more relevant.
Chris Strahl [00:32:40]:
I'm making something that's going to go in a storefront window on a screen versus like be consumed in a phone in someone's pocket. There's an interesting piece of this that is about what organizations view as competitive advantage in this case. And so oftentimes organizations are very guarded about their design. They're guarded about their engineering the code. And what you're saying is like, the discoverability of context is really, really important. Is that the thing that organizations should be looking at as a secret to guard, or is that something that we're saying we want to publish much more broadly? Because everybody can benefit from those choices. And you can see my point, right? If you're a company that makes shoes in America and then you're a company that makes shoes in Germany, you may not necessarily want to share your contextual decision making with each other, but at the same time there is this value that seems to be global about the surfacing of that context information.
Steve Dodier-Lazaro [00:33:37]:
So I was thinking within the confines of your organization, right? So if I'm working for an open source organization or government, for instance, it's going to be a completely different scale from a private company. But for instance, if you have a SaaS product and it's B2C or it's B2B and then you develop kind of side products or different communities, or you develop internal tools, then it's interesting that you share a little bit about that context. In one of the clients that I work with, France Television, we have about 20 different technical platforms where we have code, and some of them are mobile apps, some of them are TVs. And when you design for TV apps, it's a little bit different, right? You have completely different scales that you have to apply. And then we have legacy systems that are basically applications made for modems, routers that are provided by ISVs. And because the system is a sole legacy, they also have their own different technical context that needs to be taken into account when translating design. So these are types of context that I envision could be provided to tools. So that tools can basically provide guidelines, provide something that embodies the spirit of consistency and the values of your brand and your goals and standards in terms of usability, but that is adjusted to the specific context where you're crafting so that basically designers don't have to maintain 20 Figma libraries instead of one.
Chris Strahl [00:34:56]:
I think that's a brilliant future. I want that fingers crossed. So Steve, this has been so fascinating to get to kind of understand your vision for the future. I think that you've spent a lot of time thinking about this stuff. You've spent obviously a ton of time both in research and in industry actually looking at how these systems and how these companies can leverage these concepts. First, I just want to say thank you. This has been a super enlightening conversation for me. I've got to learn a lot.
Chris Strahl [00:35:23]:
I get to put a bunch of things out in the world that I haven't got to talk a lot about. Where can people learn more? Where can people look at this and kind of understand some of the work you're doing, some of the directions you're trying to take things?
Steve Dodier-Lazaro [00:35:34]:
Look, it's been a two person conversation, so I need to thank you as well. I've been wanting to get this out of my system for some time. Yeah, it's a fascinating conversation for me as well. I can be found on LinkedIn, I can be found on the Storybook Discord fairly easily. If there's anybody out there who works as an engineer and they have their idea of a tool that they would like to share and they don't really know how to make it happen, they should definitely reach out. If there's anyone working on Design Token tools working on Storybook add ons for their own organization and they want to see where they can take this. Send me a DM on Discord. Send me a DM on LinkedIn.
Steve Dodier-Lazaro [00:36:05]:
Try and find me. I'm not too hard to find and I'll happily help.
Chris Strahl [00:36:08]:
We'll have a bunch of your stuff in the show, notes and ways to connect also. So Steve, thank you again. This was super fun. I really appreciated the conversation and I look forward to chatting again soon.
Steve Dodier-Lazaro [00:36:17]:
Thanks for having me.
Chris Strahl [00:36:18]:
This has been the Design Systems Podcast. I'm your host, Chris Strahl. Have a great day everybody. Hey everyone, thanks for listening to another episode of the Design Systems Podcast. If you have any questions, topic suggestions, or want to share feedback, go ahead and reach out to us on LinkedIn. Our profile is linked in the show notes. As always, the podcast is brought to you by Knapsack. Check us out at Knapsack.cloud.
Have a great day, everyone.