Systems of Systems, Composability and Wedding Planners

Recently I sat down with Chris Strahl to discuss the relationship between composability and systems of systems within the context of design systems.

Richard: You mentioned two overlapping topics: systems of systems and composability. While some might see them as distinct, you see a strong connection between them. Let's start with composability and then expand to the bigger picture of systems and systems.

Chris: Composability is crucial because it focuses on creating simple, reusable, and repeatable UI elements. Consider highly modular and reusable components like buttons or lists, which are straightforward parts of any interface. For more complex interfaces used less frequently, such as a shopping cart, the design becomes intricate due to varying implementations. In the middle complexity range you’ll find something like a card. According to atomic design principles, atoms are highly reusable and appear frequently, whereas organisms are purpose-built and context-specific. The challenge in traditional design systems is distinguishing these components clearly, as failing to do so leads to a proliferation of UI elements that are difficult to manage.

Richard: So, if you're a designer or developer managing a design system, you might think about limiting your components to a core collection, but also consider variations that might be needed?

Chris: Exactly, but it's not about creating more components like a small versus a large button; those are just variants of one component. It's about composability—like placing a button inside a card. This isn't typically a property adjustment but a nesting of components. This aligns with atomic design principles where you can’t place a button inside another button, but you can place a card alongside other elements like headers or images. What you end up with is a three layered structure-like a pyramid. At the top is a core selection of components, say 10-20, then below that are the combined components that play nicely together. Finally, at the bottom, you have all the variations of those components in their product environments.?

Richard: In our conversations you’ve also used the analogy of human relationships to describe components. At the center of your friendship circle are your ride-or-die friends. These core friendships are your core components. Beyond that inner circle you have acquaintances, which you interact with regularly or occasionally-like work friends. Can you elaborate on this idea??

Chris: Right, think of it this way: every product needs fundamental components like buttons or labels, but not every product needs a complex product detail page. Your core friendships are your core components that you don’t want to do without. Change at this level only takes place if something significant happens. There’s a lot of stability and trust there. Outside of this core circle, your acquaintances are the elements you regularly interact with. These things can be regular connections, like work colleagues, and collections of your core relationships. The relationship comparison would be having a couple of core friends meet you at a work sponsored event. This collection, or page in the product context, might include specific elements like an image or a color picker, akin to an organism in atomic design, where core elements are assembled for a specific purpose.

Richard: And this assembly is for achieving a specific outcome but may not persist beyond that use case?

Chris: Yes, you might consider a product detail page not as a standalone component but as a composed pattern based on fundamental elements. This approach prevents the system from becoming overwhelmed with too many specific components, which complicates finding and using what's needed. It’s about maintaining simplicity and discoverability.

Richard: Is this a good point to transition to discussing systems of systems?

Chris: Definitely. Systems of systems intersect at the point of discoverability and the balance between modular and purpose-built components. Let’s go back to our pyramid. Imagine different levels within a design system where the highest level stores basic, highly reusable components and standard defaults. Below that, subsystems cater to specific divisional needs, and the lowest level covers specific product applications. This structure supports both broad usability and specific innovations.

Richard: So you’re suggesting that the middle layer acts like a wedding planner, orchestrating which components interact without conflict?

Chris: Precisely. That middle layer is where you find the social glue, people who organize and integrate different components effectively. The design system team, like social organizers, needs to ensure that these components work harmoniously across different settings.

Richard: And the goal for these design system teams?

Chris: It's about facilitating meaningful integration where changes at the foundational level are minimal and deliberate, while allowing for more dynamic adjustments at the product level. This middle layer bridges foundational elements with innovative applications, ensuring the system remains both functional and adaptable.

If you want to be a part of this forward looking group of design systems leaders, register to attend one of Knapsack’s upcoming Design System Leadership Summits. Find the information you need on locations, dates, and how to apply here. If you can't make it to the in-person leadership events, then join us for our webinar How to Craft a Business Case for Design System Investment on May 22nd, 2024.