Nathan Curtis: Alright, welcome back.
To close the day today, we're going to have a panel that is thinking about the future of design.
That panel will be led by Chris Strahl.
He is the CEO and founder of Knapsack, an enterprise software platform that unites product design and engineering in one place as a single source of truth.
Chris also hosts, and I listen to many of, the Design Systems podcasts.
Right now there's over 70 conversations with a wide range of design system experts, so I definitely highly recommend that.
He has become to me and many possibly many of you, as a familiar and curious voice in our community, help me welcome Chris.
Chris Strahl: Thanks so much.
Cheers.
Behind.
Don't fall off the stage.
Hey everybody, how's it going?
So I'm here to introduce our panel.
This is a sponsored session from Knapsack.
First I want to say thank you to Jina for putting this on.
And having an awesome partnership with us and sponsorship here, so really appreciate it.
You might see the Knapsack booth out in the lobby.
We are a design system platform that is all about providing clarity between design intent and user reality.
I got at least a couple of cringes from that pun without further ado, I want to make sure that we introduce our panelists.
Today I'm really excited to have Amy Lee.
Welcome Amy, Donny D'Amato, and Kaelig, and I'm not going to try on the last name, because I love you Kaelig.
One other thing before we get started we're going to throw a QR code up on here.
If you want to check out your design system using Knapsack you can come visit us in the lobby and we can show you what what it looks like to have Knapsack up and running with your design system.
So getting started, the first thing that we are going to talk about is this idea of what sort of represents the future of design systems.
And when we talk about that, we're talking about a couple of different things.
We're talking about the convergence between design and engineering.
We're talking about changes in tooling.
And we're talking about a change fundamentally in the way that we work from this model that has taken us from our roots in print design and in things like early coding on the internet.
into a much more systems based world view.
And I would love to just start this off by getting an idea of a future from each of you where we think about what that means to the products that we build and the websites that we maintain.
Kaelig, let's fire it off.
Kaelig Deloumeau-Prigent: Here we go.
Okay.
Hi.
Again.
Yeah, I think the future that I was talking about is all about interop and being able to migrate between levels of the production and going from prototyping to production and back to prototyping because you want to iterate on some ideas very quickly but you want to test them out in production, etc.
So I think design is going to be less and less done in design specific tools.
But based on the activity that you you need to achieve, you might yeah, you might go across all of these.
So that's, for me, that's what the future of design looks like.
And we're very far away from the printing press, to be honest, at this point.
Yeah.
Chris Strahl: What about you, Donny?
Donnie D'Amato: I see it as an infrastructure where we could build on top of.
I think of I'm sick of building buttons and accordions and things, and I see our teams doing it to support their needs, and I would like to see somewhere where our work is trying to build the infrastructure in which all that stuff is supported, so it's no longer really our task to build these things for the other folks, it's that they build it for themselves, but then are able to cross share that work, and then on top of which we can have things like analytics like Luro and things of that nature, that we can see how that share happens, and then follow that share and see how it organically grows and how it's supposed to be supporting the rest of the folks.
It's a transition from us trying to think of a component level thing and more of really that system where all the components sit on top of that goes across the organization.
So that's one of the major points.
Amy Lee: I think the design systems in the beginning we worked really hard to sell the design systems.
Say, you should make many components, you should make all these tokens.
Look at our growing Figma library, and now we have so much, we need a lot more organization, ways to categorize things, ways to upgrade some things in the design system safely, um, whereas our things are sacred and should not be touched and so I think that in the future massive information management is going to be a serious concern.
How many people have more than ten tokens in their library, right?
Hundred?
More than a thousand?
Ooh!
Chris Strahl: Oh.
LAUGHS Amy Lee: Yeah so I think that the more that people use the design system, the more that we have to help them find the good stuff that's in the design system.
Chris Strahl: That's great.
So what, when you think about, Donnie, you brought up the idea of standing on what's come before and that, that idea of how we stand on the shoulders of giants.
When we think about some of this early work that's happened in design systems, and actually I got into a sort of hallway conversation about this a little bit ago when we think about the work that's come before, and these design systems that are, those early adopters, those early leaders the Airbnbs, the Ubers, the people that we all looked at six years ago, lots of these design systems are facing challenges of how do we take the design directions and the decisions that we made in the creation of these systems and update them for a more modern take that we would have now.
What would your modern take be on design systems?
If you could basically say hey, at my organization, I'm gonna, I'm gonna wipe everything out.
What would be the foundational starting place that would be fundamentally different now than, say, six years ago?
Donnie D'Amato: I will say some of that is my talk for tomorrow.
But I love to steal thunder, that's my job.
Okay, thank you for that.
I don't need this thunder, I'll take it later.
One of the other things which is actually timely for us is because at GoDaddy, where I'm working now, we're potentially on the verge of just doing just that, where we're actually able to potentially do something different.
And one of the things that I'm thinking about there is how we might be able to take the structure and the style as one unit, and the behavior as another, so that, the server side render situation where you have HTML and CSS and that gets into the page, and then we, what we call, hydrate that component for make it functionality.
But normally for us, we usually have all of that together in components like React and so on and so forth.
But I'm interested to see if we can take it back, and where, like the Salesforce blueprint idea, where you have just HTML and CSS this is how it's supposed to look and if you want to give more behavior to it, then you can have a way to do that through your framework of choice.
And I'm interested to see if that's a possibility.
Where we can actually, again, have that structure separate from the behaviors so that you can build your own behaviors.
Think like a React hooks library as opposed to a React component library.
Chris Strahl: Gotcha.
So almost like a different kind of decoupling where you think about this idea of there's this stuff over here that represents behavior and there's this other stuff over here that represents more of the excuse me, the display.
Correct.
And how is that different from, say, theming?
Donnie D'Amato: Oh my goodness, he's just gonna just go ahead and have me do my talk right now.
Hey!
I have 30 minutes tomorrow, I'm gonna use it.
No for theming in particular, I think there's Oh goodness, there's a whole bunch of different ways of thinking about that theming, between, of course the easy stuff, or I'll say easy in quotations, but and topography.
But it could be more difficult when it comes to just talking in the audience about border radius and how that, read my blog, it's actually impossible to make that semantic.
But I know there's border radius tokens out there that part of it makes it a challenge in its own separate unit of work, just because of the combinations of different colors and even the marketing and feelings that we have about color, right?
Because that's not a functional thing, right?
The button is supposed to click.
But there's feelings about the color that make it so much more challenging that you have to manage those feelings for folks and be like this person wants an AI purple.
So we need to somehow make an AI purple button for that, for their needs.
And I think that becomes even more challenging because from the component standpoint, it's just functional, right?
It's just a function that is supposed to do that behavior that the user is expecting.
But that expression that you're adding on top, that's, there's feeling behind that.
It's a lot more difficult to systematize.
Chris Strahl: So I'm gonna go ahead and keep winding you up a little bit.
So Amy and I were talking a minute ago about the idea of what is a theme.
And as a part of that, we basically were talking about the concept of isn't a theme just a really complex composite token.
And I'd love to hear from Amy that point of view before we jump back to you, Donny, because I think that we had a pretty fascinating idea about like how this represents interfaces.
Amy Lee: And I think a theme is a composite token as in there's lots of tokens and they're tucked into another token, right?
Chris Strahl: Yeah, exactly.
So there's some sort of nested token values that represent things like, what is a drop shadow?
It's, a color, a dimension, all those different things.
Amy Lee: I think that the sort of like composite tokens it's an organizational principle.
It's like a, it's like a hierarchy, right?
You have like birds over here and you have, other mammals over here.
The ability to categorize the tokens and apply different sets of tokens.
I think that's what we were getting to composite, Chris Strahl: Yeah, the idea of like, all right, so if I have a theme that is a brand theme, and I want to have that in, in dark mode, and I want to have it to be compact spacing.
Isn't that just a complex composite token that then represents that implementation of that brand?
I can watch Donny cringe, it's great.
Amy Lee: And it's almost the sort of atomic CSS, right?
Where you can maybe compile compose interfaces using different sets of these composite tokens.
Yeah.
It's a really interesting concept.
Chris Strahl: What do you think about it, Kaelig?
I'm coming back to you, Donny, I promise.
Kaelig Deloumeau-Prigent: Yeah, we had this discussion at dinner yesterday, it was great.
Yeah, the way I try to think about it is more what are the use cases, who cares the most about these things, who needs to have their voice represented that cares but doesn't know that their voice matters, and then get them heard in the community group and then standardize so that we have ways of expressing all these opinions that really matter.
So that's a very political way to say I don't have an opinion.
I want to make sure that in the specification we have ways to represent all of these.
Chris Strahl: Gotcha.
I'm coming back to that too.
Donnie, you've been itching.
Donnie D'Amato: Hi.
I Don't like composite tokens.
I just don't like them.
I, I actually did a talk a couple of months ago about something called token operations.
It's a, kind of an idea that I made up that tries to solve a lot of the issues that have been brought up in the working group.
There's lots of different things that it tries to, to solve for.
One of those things is to remove the idea of composite tokens, just because I find that the composite token, at least part of the spec, to be like special snowflake every single time.
so Like the shadow thing for example, because there's so many different values that compose into a final shadow.
In the way that I think about it, I think of less about the type of token and how that might matter, but I'm more interested in taking the values, putting them together, to get that final value that you need.
So that, that means that each of those values themselves can be a token.
And then they can compose into its final value.
As an example, maybe you don't need to change the color of that shadow across all shadows, and you want to reuse that shadow color that's used there.
So you should be able to use that color across all those shadows tokens.
And then just combine them, composite them into single tokens.
And in that way, and I do get the reason why the type is there just so that when the end product needs to find these tokens, knows what to do with them, I understand that totally, but I think the composition part I think would be much more helpful because it's a lot more fluid and doesn't have all these expectations, because there will be other design properties that will also need to be composite and I don't think it's the responsibility of the spec to completely, itemize all of those things.
I think to have something that's a little bit more abstract would actually help, especially designers being so creative.
Fight me.
Chris Strahl: He said the word spec, so I gotta go back to you.
Fight me.
What do you think the responsibility of the spec is, in terms of that?
Kaelig Deloumeau-Prigent: To recenter on the topic, like the future of design, and it feels like we're getting very micro on very small details of the spec, and it's fascinating, but also, If you want to zoom out a little bit, I think the specification is a foot in the door of tool makers to then show them that we can all as a community and as the stakeholders who are building those tools work together towards more interop and that it's not a zero sum game.
I know that some companies want to build a huge moat on top of which they can control what they do with our, with the market and generate revenue.
That's what the, a company is built for typically.
But I think it's better for the industry and the future of design if we end up with with standards that help us move across all of these tools.
Chris Strahl: Yeah, so building on that, when you think about the idea of standards, a lot of what comes up is Brad Frost's famous I Never Want to Build a Date Picker, again blog post, right?
And we talked a little bit before, when we were planning this session, about the idea of, again, standing on the shoulders of giants.
Should we have some sort of composable collection of componentry that we think about as the basis for every design system?
Right now there's these de facto design systems that lots of folks adopt.
Google Material, IBM Carbon, et cetera, et cetera.
Should we have one of these things that exists in a public purview that is a starting point for this community?
Kaelig Deloumeau-Prigent: Yeah, so it's funny cause in 2012 or 20, wait no, 2015, one of my co workers Adam told me, I want a modal component by default on the platform in the browsers and I was like very reticent to the idea and nowadays I'm like, yes that, and also the modal component exists and the I don't think it's called modal, but anyway.
And and that kind of joins what Brad Frost was saying there.
I think the OpenUI initiative is super interesting in that regards, and so they're trying to look at what are all those design systems doing, and what should be part of the platform.
And that includes modals, date pickers, etc.
And making the atomic parts of the platform more themable and adaptable.
Now you were asking earlier what has changed maybe in the past six years on if you were to start a design system today, I think a lot of stuff has been commoditized and productized.
For example, documentation and component inventories and all the tooling that goes with it.
So I think that's great.
It's just showing the maturity of the industry and how far we've come.
A lot of companies are still at the start of their design system journey, so having all of that tooling is going to accelerate them for sure.
Yeah, that's how I look at it right now.
Chris Strahl: Amy, what about you?
I saw you nodding along.
Amy Lee: I was waiting for you to pick on Donnie.
Chris Strahl: I've done enough of that for now.
We'll come back to that.
Amy Lee: I think playing off of what Kaelig was saying, when the components become part of the browser or become part of a standard set, we don't have to worry about the mechanics of the date picker anymore.
We can actually pop up a layer and just focus purely on the styling.
I would hope that more components become part of the standard UI kit.
And if we want to talk about is there like a template where you can just generate a design system just by just typing a command all of a sudden what kind of a design system do you have?
Do you have a mobile app?
Here's a bunch of starting components versus, oh, I have a desktop widget with spreadsheets, so here's a bunch of components for that.
Perhaps it's something like that.
I almost think of way back in the day I think it was jQuery had a theme roller where you could just pick what you wanted and custom design system.
Essentially.
Chris Strahl: We wouldn't be in San Francisco if we didn't at least mention AI.
When you guys think about the future of design systems, and you think about what an AI enabled design system looks like, what comes to mind?
What do you envision?
Donnie D'Amato: I can start with that because I wanted to come on about these components and I'll say, why are you guys laughing?
I didn't even start anything yet.
Gosh, um, about the components in that global system, my hot take is that I think a good UX designer should work specifically in wireframes, not high fidelity, I'm talking low fidelity wireframes, where the system informs the fidelity after the fact, right?
So all those rules that you have in terms of color, topography, all that stuff, that gets informed into an AI system.
Where you submit a wireframe that says I need a social media feed in the view of my design system, right?
And you make up that wireframe and you put it into the system and you get sput out what it would look like using your system in that high fidelity so that it could then be, iterated on and therefore you know, finished.
So that's one of the things that is already offered out there.
There's products that do that out there.
And a lot of my inspiration was through stuff like that shows that we can really focus in on the process of user experience and really reduce the noise, because I see a lot of designers out there that focus so much on, okay, this has to be the right color purple, this has to be the right font size, and they lose the experience part, the real part that's trying to make these products work.
So to remove that noise and really dive into, this is the experience wholeheartedly, I think is key, and AI can help drive that.
Chris Strahl: So what would you say to somebody that's but there's so much that I can do inside of my design tools to model that intent that is well beyond boxes on canvas.
Donnie D'Amato: I think that just goes right with the system, right?
Because you're informing the system about what you want it to look like and that's just a training model at that point, right?
You're going to train it and say, okay, this is the right way to make that purple gradient pop, right?
And then it's systematized into future iterations of your experiences.
Chris Strahl: Kaelig, I'm sure you have a take on AI.
Kaelig Deloumeau-Prigent: Yeah, and I want to get out of the graphic design, UX design.
I want to, kind of go to content, cause I think it's been one of the underserved parts of our design systems over the years, and solo or very small teams of content designers are struggling to, like, the weight of the words that we put out there in browsers, in apps, et cetera, there's no way a single team can control, have good oversight over everything that's being shipped, and so for these teams to be able to train models or at least inform how content is written and end up seeing way better quality of content across the company is what I think AI is gonna be good at.
But yeah, that's that's my my hot tip to the content folks out there who have been trying to get good words out there.
Chris Strahl: Yeah, it's interesting, right?
We've been a, we've been a startup for Almost three years now.
And in that, we've had one design system that has had a major focus on content as a part of the design system.
And it happens to be in the pharma space where medical regulatory frameworks matter.
But it's an interesting case for content and the need for content inside of those systems.
Amy, what about you?
Amy Lee: I know for the people in this audience, we love design systems, that's why we're here, so we understand design systems very well.
But I think there's many organizations which are still adopting the design system for the first time or really truly investing in it.
And where I think AI can help us is things like accessibility.
I want a super linter that can help guide my decisions so that I don't make as many mistakes.
That I can get to that very first draft and it feels really good and solid.
I want AI to help do a little bit of generative to help me imagine like a better workflow.
Maybe there's too much content.
Maybe the workflow is too many steps.
Maybe I've I'm pressuring the user through we're trying to work too fast.
I think that AI is one of those things that it's good at recognizing patterns and suggesting the best ones.
Chris Strahl: sHifting gears for a second.
Thinking about how do we get people to really care about design systems?
We talk about how everyone here has a vested interest and a stake in this, right?
And so when we think about how we get more adoption of design systems, how we get more resources as a community, how we think about continuing to see big organizations and small organizations adopt these, we have to understand that there's a question about relevancy for people that are outside of this community.
And how do we think about tackling that more strategic conversation about why people, and largely people that have large sums of money should care about these things and invest in these things?
Kaelig Deloumeau-Prigent: I think you're really good at this, actually, because I think it's your MBA background.
Yeah, and the way you've talked about and also Nathan Curtis has been one of the inspirations of how I, the more and more I think about stakeholder and especially leadership buy in is thanks to what you've been saying and like doing some napkin maths and just the nitty gritty of what component libraries bring us on a day to day, as an exec, you might not need to know all of that.
Maybe showing them numbers, and if there's six zeros after the first digit, maybe they will react to it.
So that's the kind of stuff that can speak their language.
But aside from that, what business doesn't want to get more with less right now?
, like Brad Frost was saying recently, we weren't put on this earth to draw rectangles, It's perfect.
And do you want your employees to draw rectangles all day or do you want them to build differentiating experiences that you know make that revenue curve go up and to the left.
That's my abstract way of responding to this.
Chris Strahl: Usually goes up and to the right, not up and to the left.
To the left, yeah.
Kaelig Deloumeau-Prigent: Yeah in some countries I guess that works.
Chris Strahl: It's a culture thing.
What about the rest of you?
. saying this design system is really improving life for multiple teams.
There's always this sense of a design system is an investment to make us go faster, but then sometimes it's hard to quantify how much time did this save us?
And I too have struggled to figure out how to like present numbers sometimes because numbers don't, they don't show for many quarters, like you're slaving away trying to get something out there really hard, working so hard and yet at the end, it may be like six months until the final fruits of your labor finally come back.
And I think in between now and when things finally get delivered being able to show the progress constantly, being very vocal about it saying that like you're not just here working, but you are helping and getting other people to speak and carry your voice forward I think that's really powerful.
Chris Strahl: Yeah, it's actually my favorite design system metric is when you ask somebody that uses the design system, consumes the design system every day, whether or not they feel like their work is more impactful with the design system.
And when you have that sense of impact, that's something that you can't rip away from somebody.
It's so exciting.
Donnie, what about you?
Donnie D'Amato: I really don't sell anything well.
I don't.
I know that we need like the buy in and adoption and things like that, but I admittedly just don't know how to speak to CEOs about how this is going to help anyone.
I'm very, the systematic part or the the warehouse part of that systematic stuff.
I'm at the, the, at the wheels trying to make this stuff work.
And, because I believe in it just like the rest of everyone else does in this room.
But it's hard for me to, uh, convey the importance in a way that someone who only thinks about money, not that you say you only think about money, CEO, I don't know but not to say that you only think about money, but it's hard for me to convey about something from a business standpoint.
As much as I'm trying to convey it from a user standpoint, and sometimes they miss, right?
And I don't know how necessarily, to do that in my work, personally.
Nathan Curtis: So it's interesting you bring that up, because the, on the warehouse side there's a lot of community that we care about as a practice.
And so one of the wonderful things about Clarity, one of the wonderful things about some of the Meetup events and local stuff is we are building community.
And a part of that is that, that understanding of the practice and the understanding of how this all fits together and how it works.
And I think that there, there is, that counterpoint to the money argument about how many people care about this stuff.
And if this starts to have reach and it starts to go really far and there starts to be events like this that, that really continue to drive home the expectation that these things exist inside of organizations, that's another kind of power.
And that's a lot harder than the money argument to rip away.
When you think about, rise in interest rates or macroeconomic trends or something like that, that can really impact people's ability to fund things inside of organizations.
But it's also something that is then counterbalanced by a groundswell inside of a community.
And I think there's a lot of power in that.
And that's one of the things that, that I wanted to end on as a question, is How do we each as folks up here on stage in front of this community of people, continue to grow and build that community within our own organizations, as well as in our lives?
Knapsack is obviously a very proud sponsor of Clarity, and that's a part of our contribution here, as is this talk.
But things like the podcast, things like the field guide, things like all these other ways that we connect as people, are our way of shifting power away from that money conversation and into this idea of a groundswell.
And I'd love to hear each of your thoughts on that kind of as a closing and then we'll open it up to some audience questions.
Donnie D'Amato: I can go first.
So the community is huge to me.
I want to stress that so much that I'm so thankful for you out there being my people.
That's the way I like to say it.
Because I was at Clarity.
2018, the one that Nathan first MC'd in New York, and when I went into that room and I was, any person I talked to could talk about the same problems that I was going through, and without any kind of cuing or questioning, it was just like, yes, I know exactly how you feel, it was that comfort feeling, and having a community like this is incredibly important, it empowers us, it shows us that the stuff that we do is important, and you see it even more outside of what we're doing, because it is coming into areas that are outside of us, even from design and development, it's also coming into other mediums, like haptics, like robotics, and things like that, that systems could potentially, the stuff that we do could influence that stuff.
The community that we're building here and being involved with it, like Slack, if you're not on Slack, I'm coming for you.
bUt the community that's in there is just so powerful that and growing and learning about from this stuff because the work that I'm going to present tomorrow, I would have never been able to, figure out without folks like you.
Thank you.
Amy Lee: To play off of that definitely join the Slack.
That's where, what, one of the cool places is because now there's so much of a community.
Thank you for starting the Slack because now we have this common conversation point.
It's going to be in my talk tomorrow too.
But this common conversation point where people can help each other across organizations.
Because it's so hard just even in your own company to be able to help the people that are around you.
But being able to leverage the entire community that's really special.
Kaelig Deloumeau-Prigent: yEah, the community aspect is huge.
The promise of the web was that it's for everyone and we all have our sub communities and we find our people in this vast world.
And yeah, we're a bunch of weirdos who for some reason found ourselves in San Francisco on the, in the middle of the week, just thanks to folks like Jina and and yourself and very thankful for that.
And then the way I see my contribution, so I always look at, I have a framework where I'm looking at my impact at the project level, team level department level, company level, and industry level.
And I'm trying to distribute that time depending on the needs of the company and the community.
But the, I think lowering the barrier of entry for people to have that access to efficiency and so that they can focus more on what is fun, what is creative is what I'm striving for.
Chris Strahl: Awesome.
Hey, I'm so grateful to be on stage with all of you.
Thank you so much for being here.
This has been so fun.
And I love all of you and I appreciate the time and giving back to this great group of people.
So I think we have time I think we have time quickly for two or three questions from the audience.
We'll pass the mics around.
If there's anything you want to ask the panelists raise your hand.
We'll try to get a mic over to you and get a couple Q& A of things.
Donnie D'Amato: While they're moving the mic in seriousness for the Slack stuff, I'm one of the, I'm one of the moderators on that Slack.
If you have a problem getting in, find me.
We'll make sure that you're in.
If you have a two factor problem, I will get you in.
We will get you in.
Okay, go ahead.
Chris Strahl: And and if you're asking a question just state your name.
[audience member] Great Sean, and thanks so much for today.
This was really great.
What I'm trying to figure out is what folk are doing to actually, um, understand adoption of the design system and be able to get visibility to that so that you can figure out what to do next, I think one of the things you brought up during this talk was, asking the people that are using it all the time, but what about the people that should be using it that aren't using it?
And like, how do you, like, how do you improve adoption?
Amy Lee: One of the slides I think Jina put up in her introductory talk was all the various colors and fonts.
There was like dozens and dozens.
One of the things I love to see is when people start adopting the design system.
The numbers start reducing, and you start getting this more consistent look and feel.
That's an immediate evidence that you can use.
The other evidence I like to use is because I like having lots of people on a design system chat within the company.
You can see all the teams that are starting to adopt it.
And that there's this energy around, yes, we love adopting it.
Donnie D'Amato: The only thing I'll say is about the support piece cause, I like to think of the design system as a product, so that you're trying to, support your, those users that are using it, so to have that feedback about, okay, what do you actually need and have a response to that in one way or the other, even if it's something that says, oh, I'm sorry, that's something that I can't support, even just that feedback alone is gonna be helpful, certainly and then I guess the other thing about that is, must be speed, right?
How fast is the, that person that you're going to help out able to do their work?
One of the things I talk about tomorrow is basically some of the processes that we might have, even though they're systematic, are also slow.
And we should consider ways of speeding that stuff up.
Just for the sake of, if we're blocking them because we're too slow, then the system becomes a bottleneck, and therefore, a unnecessary evil, which is no good.
Chris Strahl: It's interesting for me as a company.
We live in the meta.
We have a design system that creates a product that hosts other people's design systems that is then the thing that makes the products that ultimately end up in users hands.
There's four levels of meta there, right?
And the big problem that we always see with our customers is nobody's baselining this stuff.
Those metrics exist largely at the product level around speed, time to market, lots of different things that product metrics exist around, but oftentimes those don't exist as a function of a design system team.
And so if you're a design system team, largely your users are the people that are building other products.
And so being able to focus on their metrics and how you're improving something that represents like their KPI, that's a way of turning ultimately your user into a hero.
And that's one of the things that we try to think really hard about at Knapsack is how do we take, not just the people that are building the design system, but the people they serve and turn those people into heroes.
And what are those metrics that they really care about?
And that, it gets into the whole idea of user research and listening to your users and those sorts of things.
But that tends to be where the magic happens.
Yeah, Kaelig Deloumeau-Prigent: let's chat later because I'm curious to know what scale you're thinking of because the, it depends answer really applies there.
Let's chat later and tell me more.
Chris Strahl: Maybe time for one or two more.
[audience member] Hi, I'm, it's weird to hear yourself, I'm Becca Sheldon.
So there's been a lot of talk today about web technologies and the specs there, but I'm curious how you see the future of design systems with mobile for things like car screens and watches and just other platforms.
[Chris Strahl] I love this one.
Can I start this one?
Alright.
One of the features that I really see as being present in design systems is this idea of the spec.
And what I mean by the spec is what is that governing thing that represents that source of truth?
And then everything is an implementation of that spec.
That represents the contract between all the different parties involved in an implementation.
And that spec may be partially fulfilled in some cases.
For example Figma is an abstraction of largely web applications.
And so there's gonna be things that are included in the spec that Figma can't implement.
Likewise, we have that same problem with living room devices or car devices.
But there needs to be some central thing that does represent that governance of truth that is what amounts to a data contract between design, engineering, content, product, that is that true element of representing what we're all building, or what we're all talking about.
And that's a fairly far flung idea right now.
I would say that's not something that's gonna happen in the next six months.
But I view that as something that we're all working towards.
And I did this really awesome chat with one of the engineering managers at Meta about how they think about this.
That provided me a lot of insight and understanding that what we need is to stop thinking about how we go from Figma to living room devices, or Figma to web, and we need to start thinking about how we create these centralized ideas of what a spec is, and then everything is an implementation of that.
Donnie D'Amato: I actually am a little scared of the possibility of interfacing, interfaces being similar across these different devices, and the reason I say that is because, car manufacturers, as an example, have tried to put all their buttons into their touch interfaces, and that has fallen, flattened on their face.
Yeah, they're going back, actually.
Exactly, for the tactile ones instead, and that's because it makes it easier for folks to actually feel the button on the console and actually press.
the correct one as opposed to trying to put it all in the infotainment centre.
If we over index too far into just saying, oh, just put everything on the screen, it might not be the right experience for that place.
Same thing with television OS's, right?
Cause in the television OS you don't typically have a standard pointing device to go ahead and navigate through that system.
You have a, your remote control, which is a separate, user experience entirely that might not match what we've been doing on the, or probably shouldn't match what we've been doing on web and mobile otherwise.
So I am concerned about how closely we need to match those experiences from the functional point.
From the stylistic expression point, they could probably match a little bit.
But again, that functionality I think is, I'm a little concerned about.
Amy Lee: I think looking at like the future technology is so pervasive, it's always around us, like in, in the car as the example.
I think that the next dimension for design systems is how do you design systems for very distracted people?
You're you need to communicate quickly to the user that something is happening.
You need to provide affordances that fit whatever, finger or glancing or voice.
And I, I think that there's a lot of exploration, and I think we can still apply design system principles.
There's pro, some probably equivalent to atomic design, but for, car UIs, for, Alert signals, I know, I'm getting really cerebral.
But the point is, they, we're moving beyond two dimensions.
We're moving into the dimension of time, the dimension of touch, and that really interests me.
Chris Strahl: Bring us home, Kaelig.
Kaelig Deloumeau-Prigent: Yeah, I love this question because This community is heavily biased towards frontend.
In fact, we did When I started the community group, we gathered with Jina and Danny and a few other folks and we did a kind of bias acknowledgement workshop to figure out where our black spots are, where are we completely blind and Danny has worked a lot on mobile multi platform design systems but overall in the group we're fairly biased towards web.
And that said, when we start standardizing things, or specifying things like bolder radii, don't worry, there's going to be squircles in there for sure, like even though the web is not ready for it, we'll make sure it happens.
And yeah, I'm basically sending an invitation to whoever is you guys are way too biased towards, and I'm just realizing in my sentence there's a huge bias as well, but anyway.
If you want to discuss more and you have an interest in getting your voice heard in that specification, come over and let's have a chat.
Chris Strahl: Awesome.
Hey, that's all the time we have for today.
Really appreciate you all again.
Thank you so much.
And without further ado, we'll shuffle off the stage and give it up to Jina.
Thanks, everyone.