(highlight:: Building Design Systems are More Complicated Than They Seem
Summary:
Design systems are complicated because they involve more than just designing and coding.
Before creating a component, decisions need to be made about its relevance and who it is for. This requires reaching out to diverse communities for input.
In addition, design and code steps involve engaging people outside your team for feedback and documentation.
It is important to be disciplined about versions and breaking changes to maintain stability and reliability for other teams.
Transcript:
Speaker 1
And so people ask those creating design systems, why is this so complicated and why is it takes so long to build a button? For example, it's a story I use. And the reason is because you don't just have a design step and a code step and a designer and coder working together, you have a step that precedes that to decide, in the case of the button, You know you're going to have a button. But for other components, not just should we make it, who's it relevant for? Is it worth putting in a system? And you have to reach out into communities of people, designers and engineers that sort of spider web all the way through an organization to get their input. And that still happens at the design step and at the code step two, pull requests that engage people outside your team as a natural part of the course of getting work done, asking them For feedback on APIs. Oh, and then you have to document it. You have to release it in a pipeline. You have to be really disciplined about versions and breaking changes because you're the dependency of their group. And they depend on you to be stable and work with discipline.)
- Time 0:07:01
-

(highlight:: Design Systems are More Than Just Visual Systems, They're Systems That Manage the Connectedness of People and Teams
Summary:
Managing the connectedness of people in design systems takes up more time for designers or engineers on a product squad.
Transcript:
Speaker 1
The design systems aren't just systems of visual style propagated through your work modes, there's systems of people. And managing the connectedness of those people takes a significant greater proportion of your time than it would if you're a designer or an engineer on a product squad itself.)
- Time 0:09:36
-

(highlight:: Thinking About Organizations and Their Users as a Complex System
Summary:
In large organizations with design systems, there are different levels of participation.
At one end, there is the central team responsible for making the system. At the other end, there are users who benefit from the system.
In between, there are the extended team members who are closely connected to the system and have a high degree of influence.
On the other side, there are adopters who become contributors and actively contribute to the system's development.
Managing this spectrum and people's sense of self and belonging is a challenge.
Transcript:
Speaker 1
I identify with the degree to which people participate and the role that they play in a system. And at most large orgs now that are making significant investments in design systems, you've either got an actual full team or in cases of some of these really large systems or well-known Systems in large tech companies. You have teams of teams that are assigned to do the system, that is their job. But you think about the remainder of nodes around the community of people you work with on a day-to-day basis and systems are nodes and connections between nodes and the way things pass Between them. There's this spectrum that people lie on. And on the one side is really the central team making stuff as a part of the job. On the other side of that spectrum are people that use a system. It's your run-of-the-mill customer that takes those packages, those assets and uses them as tools to improve their day-to-day work. And then there's that space in between. And that's probably the most challenging one to form rigorous processes that are well-defined that everybody understands. And the two nodes between it, the one closer to the systems core team, I often just term as an extended team. Who are those designers or developers, often like a guild or a set of ambassadors or champions or advocates, whatever you call them, that are really strongly connected to the systems Effort itself. They can speak to what's going on. They're very well-versed in the roadmap of things and where the system's going. And they have a high degree of influence because they participate a lot. They're maybe even expected to review pull requests or attend design critiques or whatever it is. And then on the other side, closer to adopters, you have people that see themselves as passionate and they really like what the system's doing and they have something of value that can Put back in it. And so when you transform that adopter into a contributor, maybe it's a simple fix. Maybe they start to get acclimated with how the system works and they enhance a particular component. Maybe, but it's complicated. They work with you to create a new component. Those folks aren't necessarily on the extended team per se, but they start to become a vibrant part of that tapestry of people that are pushing the system forward. So that's a hard spectrum to manage people's sense of self and where they fit.)
- Time 0:11:12
-

(highlight:: Information Architecture and Its Role In Organizational/Enterprise Effectiveness
Summary:
I.A. plays a crucial role in managing and designing design systems, as well as ensuring scalability.
Dan focuses on discovery and UX work, while also addressing issues of hierarchy, taxonomy, and creating flows. They excel in tackling granular challenges like coding visual styles, as well as understanding organizational charts, product timelines, and dependency trees.
Their goal as an architect is to guide teams by providing structure and support, while empowering them to fill in the necessary blanks and overcome challenges.
Transcript:
Speaker 2
I feel like there's not enough discussion of the role of I.A. In solving not only the kind of nuts and bolts management and design of design systems, but maybe more importantly, the kind of scalability you're just referring to.
Speaker 1
There's no question that while Dan remains in discovery and UX work that's probably more closely aligned with the I.A. We both know and love, that issues of hierarchy and text onomy and naming things and connecting dots and creating flows permeates everything that we do to make a system work in an enterprise. I bring those skills to bear on challenges as granular as tokens that describe a visual style in code and data, like a big property value hierarchy that describes color and type and so On. And I openly admit to my clients, I'm like, if you want, that's where my energy is, if you need somebody to do that, like I'm all over that task. But just as much I see organizational charts and I see product timelines and I see dependency trees and all these things, they all still like the same fire of architecting information. And one of the things that I like to do with teams that I'm trying to lead is say, I've built a lot of these structures before. I can help you create all the blanks you need to fill. And when you discover there are new blanks to fill that I haven't articulated, I can help you think about the challenges and the boundaries where you're going to trip up and where you're Going to get stalled. But please fill in the blanks yourself. And so that to me is an architect's job to help those kinds of teams succeed and designs and sources like one of those challenges.)
- Time 0:21:48
-

(highlight:: Building Design Systems are More Complicated Than They Seem
Summary:
Design systems are complicated because they involve more than just designing and coding.
Before creating a component, decisions need to be made about its relevance and who it is for. This requires reaching out to diverse communities for input.
In addition, design and code steps involve engaging people outside your team for feedback and documentation.
It is important to be disciplined about versions and breaking changes to maintain stability and reliability for other teams.
Transcript:
Speaker 1
And so people ask those creating design systems, why is this so complicated and why is it takes so long to build a button? For example, it's a story I use. And the reason is because you don't just have a design step and a code step and a designer and coder working together, you have a step that precedes that to decide, in the case of the button, You know you're going to have a button. But for other components, not just should we make it, who's it relevant for? Is it worth putting in a system? And you have to reach out into communities of people, designers and engineers that sort of spider web all the way through an organization to get their input. And that still happens at the design step and at the code step two, pull requests that engage people outside your team as a natural part of the course of getting work done, asking them For feedback on APIs. Oh, and then you have to document it. You have to release it in a pipeline. You have to be really disciplined about versions and breaking changes because you're the dependency of their group. And they depend on you to be stable and work with discipline.)
- Time 0:07:01
-

(highlight:: Design Systems are More Than Just Visual Systems, They're Systems That Manage the Connectedness of People and Teams
Summary:
Managing the connectedness of people in design systems takes up more time for designers or engineers on a product squad.
Transcript:
Speaker 1
The design systems aren't just systems of visual style propagated through your work modes, there's systems of people. And managing the connectedness of those people takes a significant greater proportion of your time than it would if you're a designer or an engineer on a product squad itself.)
- Time 0:09:36
-

(highlight:: Thinking About Organizations and Their Users as a Complex System
Summary:
In large organizations with design systems, there are different levels of participation.
At one end, there is the central team responsible for making the system. At the other end, there are users who benefit from the system.
In between, there are the extended team members who are closely connected to the system and have a high degree of influence.
On the other side, there are adopters who become contributors and actively contribute to the system's development.
Managing this spectrum and people's sense of self and belonging is a challenge.
Transcript:
Speaker 1
I identify with the degree to which people participate and the role that they play in a system. And at most large orgs now that are making significant investments in design systems, you've either got an actual full team or in cases of some of these really large systems or well-known Systems in large tech companies. You have teams of teams that are assigned to do the system, that is their job. But you think about the remainder of nodes around the community of people you work with on a day-to-day basis and systems are nodes and connections between nodes and the way things pass Between them. There's this spectrum that people lie on. And on the one side is really the central team making stuff as a part of the job. On the other side of that spectrum are people that use a system. It's your run-of-the-mill customer that takes those packages, those assets and uses them as tools to improve their day-to-day work. And then there's that space in between. And that's probably the most challenging one to form rigorous processes that are well-defined that everybody understands. And the two nodes between it, the one closer to the systems core team, I often just term as an extended team. Who are those designers or developers, often like a guild or a set of ambassadors or champions or advocates, whatever you call them, that are really strongly connected to the systems Effort itself. They can speak to what's going on. They're very well-versed in the roadmap of things and where the system's going. And they have a high degree of influence because they participate a lot. They're maybe even expected to review pull requests or attend design critiques or whatever it is. And then on the other side, closer to adopters, you have people that see themselves as passionate and they really like what the system's doing and they have something of value that can Put back in it. And so when you transform that adopter into a contributor, maybe it's a simple fix. Maybe they start to get acclimated with how the system works and they enhance a particular component. Maybe, but it's complicated. They work with you to create a new component. Those folks aren't necessarily on the extended team per se, but they start to become a vibrant part of that tapestry of people that are pushing the system forward. So that's a hard spectrum to manage people's sense of self and where they fit.)
- Time 0:11:12
-

(highlight:: Information Architecture and Its Role In Organizational/Enterprise Effectiveness
Summary:
I.A. plays a crucial role in managing and designing design systems, as well as ensuring scalability.
Dan focuses on discovery and UX work, while also addressing issues of hierarchy, taxonomy, and creating flows. They excel in tackling granular challenges like coding visual styles, as well as understanding organizational charts, product timelines, and dependency trees.
Their goal as an architect is to guide teams by providing structure and support, while empowering them to fill in the necessary blanks and overcome challenges.
Transcript:
Speaker 2
I feel like there's not enough discussion of the role of I.A. In solving not only the kind of nuts and bolts management and design of design systems, but maybe more importantly, the kind of scalability you're just referring to.
Speaker 1
There's no question that while Dan remains in discovery and UX work that's probably more closely aligned with the I.A. We both know and love, that issues of hierarchy and text onomy and naming things and connecting dots and creating flows permeates everything that we do to make a system work in an enterprise. I bring those skills to bear on challenges as granular as tokens that describe a visual style in code and data, like a big property value hierarchy that describes color and type and so On. And I openly admit to my clients, I'm like, if you want, that's where my energy is, if you need somebody to do that, like I'm all over that task. But just as much I see organizational charts and I see product timelines and I see dependency trees and all these things, they all still like the same fire of architecting information. And one of the things that I like to do with teams that I'm trying to lead is say, I've built a lot of these structures before. I can help you create all the blanks you need to fill. And when you discover there are new blanks to fill that I haven't articulated, I can help you think about the challenges and the boundaries where you're going to trip up and where you're Going to get stalled. But please fill in the blanks yourself. And so that to me is an architect's job to help those kinds of teams succeed and designs and sources like one of those challenges.)
- Time 0:21:48
-