Design System - Jennie Yip

[Hanastevenson]

Hey Team,
Please add your thoughts on Jennie's Talk at Schema.

Edit by @kelenelee : this task is no longer required by onboarding due to our conversation during the all-hands meeting on 4/25 and the results of this poll

[rcurtis2]

[kevinmoutoucarpin]

It seems like Atlassian’s governance is hybrid model : so in our case, we need to define the our governance, which made me think that we need to ask questions for our research to understand how is our organization in order to define our governance model (centralized, distributed, hybrid)

It's easy to be overwhelmed with lots of requests/questions but first, we need to set boundaries (starting from defining values and principles) :

• Values : Values are fundamental beliefs (what we hold true)
• Principles : Principles are guides to behavior (how we achieve our values)

A design system doesn't aim to solve user problems, it aims to make those who are working on the product or service more efficient. If the product or service isn't used, then we're implementing the system in the wrong way.

It's true that it's important to be consistent in terms of brand identity if we have several products like Atlassian or Google for instance but it shouldn't come at the expense of the overall user experience.

[BobbyBishopUX]

My thoughts as of now:
We may have to consider that this project is too big for us to handle. Maybe even too big for Hack for LA. Maybe Code for America is better able to handle it.
We may need to rethink the project and it's name, as Design System seems to prescribe the solution.
I am thinking that we should consider doing task analysis as a research method.
We could also do experiments with parts of a design system if we have enough of a sample size.
We may also want to look into systems thinking and what that would mean for this project.
We should do more research on the organization of Hack for LA. How are teams structured? Size? How does information flow? Who should we interview that is the most knowledgeable about the system of Hack for LA and the individual projects?
We have to establish boundaries and the scope of different phases.

[Hanastevenson]

@BobbyBishopUX points one and two were discussed in the meeting.

[nasimbiglari]

> As I was thinking about what goes into the design system, these 2 moments stood out for me. It made me think about the complexity of these systems. Also I found her final remarks crucial for a success design system and also any project. As much as we zoom in to figure the detail of something out , we have to zoom out and not forget about the bigger picture.

[Hanastevenson]

This week the team watched 'Design Systems are for People' by Jina Anne. Jina Anne is one of the senior figures in the Design System community. She also runs the Design Systems slack community.

Resources/Instructions

'Design Systems are for People' talk

[hdchangie]

Some takeaways after watching Jennie Yip's presentation:

• A design system is the foundation of a design but they also need to be changed from time to time.
• design system sparring sounds like a wonderful platform to bring and invite customers to the design team and make the contact.
• documentation is key to keeping consistency and increasing efficiency in scalability. In the process of working with a large number of designers/team members, it's crucial to document everything so that others who take on the same task in future can simply follow the same principle and steps of work.
• it's interesting to know the differences/gaps between the design in design systems and user experience design of the whole product for end-users. It is true that design systems are there to create consistency across platforms, but designing a user-friendly product needs to rely not only on design systems but also on other teams together.

[winoue90]

While watching Jennie Yip's presentation, I couldn't help but draw parallels with Atlassian's challenges with their multiple products with the challenges we face with HfLA's design system. Listening to the evolution of and struggles of the Atlaskit mirrors our struggles with addressing the diverse range of projects at HfLA, as well as enforces the decision to put focus on creating the foundation rather than an all encompassing design system.

One segment near the end stuck out to me the most, when she mentions the shift in mindset for building a design system from the ground up. Her explanation of switching from a product mindset to a platform mindset is a very applicable takeaway for this endeavor and one that I find very helpful.

[rosaliechung]

From her talk, it seems like design systems is a newer "product" in recent years, as companies have grown bigger with multiple products and realized a need to have consistency in language and design for more efficient product development. Unfortunately, for many of these larger companies, creating and implementing a design system can be a pretty big overhaul when they already have many products in place with their own sets of designs. However, Jennie highlights the importance of having a design system because it can actually save a lot of time on the backend - as companies progress forward and make new products, they may run into bugs or issues that need to be fixed, but it is difficult to do so because of prior design/developer decisions. Similar to the text we read, she also provides an example of how having a core set of values and principles across all the product teams in a company is important because it helps shape the design decisions in the design system.

I think she also makes a strong case for why documentation is important in design systems, particularly for a large company. In a large company with multiple teams and product lines, if everyone is operating under the same design system, in order for them to understand how to use it and the rationale behind how the system was developed, it is important for people to document this information so people can be empowered and learn about the design system. As Jennie mentions multiple times, doing this makes the design system much more scalable, which means it'll likely be used more often in the company.

Finally, she emphasizes that design systems do not solve user problems or issues. From her framing, it seems like this is a common misconception in the field. But her point here resonates with the purpose of design systems that we read in the text, which is that these systems are created so that we can focus on how to create a product that focuses on users' needs and experiences, rather than arguing over how something looks or should practically function.

[alenayaovich]

I think for me a few important ideas in this video were:

• thinking about the design systems as hyperobjects: something that is beyond our comprehension so we are able to create for it a foundation while the ceiling is always open

- **a starting point** of creating a design system is defining its **values and principles**

- in order to create a scaleable product and successfully grow design systems, we need to prioritize **documentation**

Also, I think their struggle with combining two sites: design and engineering was very interesting and made me think about the importance of working with the dev team while creating a design system...

[kmedhi]

Some important takeaways from Jennie Yip's talk:

1. Design systems comparison with hyperobjects as they are overly massive and vast that is beyond human comprehension.
2. The way any organization functions is thoroughly intertwined with the existence of the design system.
3. The identity of an organization through its values gets reflected through the design system.
4. Strong foundation for a design system is crucial for future scalability plans for the organization.

[kelenelee]

Design systems are overwhelmingly large, complex entities that need collaboration across teams in order to be maintained. They can be difficult to manage.

Atlassian faced some challenges as they tried to update their design system. To re-synchronize their design guidelines and component library, the design team and developer team had to talk to each other and align on one "source of truth."

Before fiddling with detailed features, Atlassian defined foundational values that they wanted their design system to follow.

Atlassian also organized a documentation system to encourage design system users to be independent and make clear documentation of their own.

[kelenelee]

this discussion is locked. can it still be replied to

[cunninghamej]

I was intrigued by Jennieʻs use of Mortonʻs "Hyperobject" concept. I agree with her analogy in terms of the incomprehensible complexity of these systems, but disagree with it in terms of thinking how we might approach and attempt to manage these systems. The concepts of "Panarchy" and "adaptive cycles" are perhaps more productive.

With these systems the focus in on how various components begin to interconnect and operate, building conservation (which is often what we intend to maintain), but also giving rise to emergent phenomena that may ultimately weaken the character of the system and drive a shift.

Understanding that we are not able to "control" or perhaps not even "manage" such systems is key, I think, in that it forces us to rethink our interventions. How can we make such open-ended systems (assemblages?) robust, collaborative, and resilient?

[nansah]

Creating a single source of truth is necessary and a design system essentially is the way an organization works

[tamalatrinh]

Ideas that stuck:

• Configuration over Customization
• Implementing a design system and using its parts does not affect user experience.
• As a design system matures designers must create values and principles to guide them.

Lastly, try not to get overwhelmed by practicing systems thinking and approach each problem from a new perspective. Also, don't forget to zoom out!

[sandraberjan]

Biggest takeaway from Yip's talk:

Design systems are hyperobjects. They can't be imagined as a whole.
For example: A plastic bottle is easy to grasp. All of the plastic in our oceans? Overwhelming!

My response:

Language is also a hyperobject.
We can point to words and sentences. But it's impossible to hold language in our minds in its totality.

Despite that, we use language every day.

• We have grammatical rules that we all follow (despite imperfections and disagreements).
• We can communicate with each other.
• We have agreed on which words will refer to which things.

Language is messy, always changing, imperfect, but it works. Without it: chaos!

Suggestion:

If we approach our design system the way we do language, we can have structure and not chaos.
To do that, we have to embrace a certain level of imperfection, change, and even messiness.

To borrow an idea from literary theory, we can think of the design system as always iterable:

• a basic structure that allows for fluidity around it and
• does not resist change if it is needed.