Fundamentally, our design system library originated from the need for cohesive components throughout the product. This was intended to prevent user confusion regarding the functionality and visual aspects of common components. Additionally, it aimed to reduce engineers' efforts in duplicating components already present elsewhere on the platform.

Components should have the ability to vary in styling. For instance, a button should be adaptable to include text, an icon on either side (if desired), diverse color variations, and so forth. This empowers designers with flexibility to employ a global component to address their specific use-cases within their domain. However, it's crucial to avoid excessive flexibility; in the same example, if buttons encompass too many color variants, it might lead to user confusion or disdain regarding the overly various color variants, counteracting the initial objective of the component library.

As designers working on this library, our primary challenge was determining the optimal balance between component constraint and maximum customizability. Generally, we followed a rule of thumb: we began with an MVP that leaned towards being more constrained, but allowed for avenues to expand the component's capabilities as its global usage and adoption by designers and engineers increased.

Another significant consideration we faced as designers was whether a particular component was deemed a global necessity. When I joined the team, our library featured a small handful of components. Consequently, it was imperative to prioritize components based on their global necessity throughout the product. As the library expanded, we also confronted the decision of whether certain components should be confined to their specific domain or integrated into the design system.

The determination was made through a combination of responding to requests for usage across various domains and referencing publicly available design systems. We maintained an ongoing collaboration with other product designers at Newsela, consulting them about components they were creating for their domains and ongoing initiatives to identify potential overlaps and opportunities for integration. We also benchmarked against established systems such as IBM's Carbon and Google Material to identify components they deemed necessary or gaps in our design system backlog.

As a core principle of modern design systems, components must be designed with careful consideration of devices, ensuring both responsiveness and scalability. This presents a challenge for us on the design side, as we need to research and define the best practices for components across diverse devices, and be mindful of edge-cases regarding varying screen sizes.

This challenge applies to all components, whether simple or robust. For instance, when handling simple components, it's crucial to consider text truncation and the possibility of rescaling if it exceeds our smallest viewport size. For more complex components, this might entail a layout change on smaller breakpoints, or a complete transformation in how users engage with it.

As a resource team supporting the entire product, we had to continually refine and adapt our processes to effectively serve the broader design and engineering teams. This encompassed enhancing the avenues for requesting additions to the library, implementing tools for coworkers outside the team to monitor our progress, and providing comprehensive documentation on component usage and available variations for designers, engineers, and product managers.

When a component was accepted as a global need and prioritized for creation, the initial step involved conducting research on the component. This included investigating our internal use-case as well as studying how other design systems had constructed similar components.

For internal research, I started with conducting an audit within our product to determine if the component already existed and was in use. I would document all instances across the product where it was employed, along with variations in visual styling and, if relevant, common elements across instances. Working closely with the product designers who initiated the request, I delved into understanding their envisioned usage of the component and their precise needs. Finally, I collaborated with our design system engineer to address any technical considerations associated with the component and gain insights into its implementation on the front-end.

My focus for external research was on grasping all relevant best practices for the specific component. In terms of best practices, I studied how other products had conceptualized the component's role within their libraries, its structural composition, layout and sizing variations, accessibility considerations, interaction states, and any additional facets. Armed with this knowledge, I could then proceed to design the fundamental core of the component.

When starting design for a component in Angelou, I would begin by establishing and documenting the component's designated function within our design system. Subsequently, I would proceed to design the most foundational, simplified anatomy of the component as a baseline.

Utilizing the aforementioned internal research, I would assess if there was potential to expand the component's structure with additional optional elements – elements which were present in either the components on the live product or future facing designs. This was essential to guarantee that the newly standardized component could seamlessly replace all existing instances, as well as grow with the future needs of the component.

Upon identifying the complete anatomy of the component, my next step was to outline it in the documentation. This comprehensive documentation encompassed a description of each element in the component, their respective limitations, and, where applicable, the element's capability for addition or removal.

After establishing the component's anatomy, the next phase involved crafting specifications for spacing and sizing. This encompassed visual representations of padding and margins within the component, as well as spacing considerations for scenarios where optional elements are incorporated.

If a component necessitated multiple size variations, the documentation would cover the adjustments in spacing and sizing for these distinct size variants. It would also provide comprehensive usage guidelines specific to the various size options.

We would then document the overall usage of the component within the design system, outlining its designated role further. When needed, we extended this documentation to encompass sub-types or specific variants of the component. Additionally, we included supplementary explanations that clarified the distinction between the role of the new component and similar components that already existed in the library, such as buttons versus chips.

We also supplied 'Do's and Don'ts' documentation to offer visual clarity to designers regarding frequently asked or requested use-cases. This documentation could cover a range of topics, including approved combinations of components, potential misuses of elements within the component, and other pertinent guidelines.

Accessibility guidelines would vary across components. All components warranted documentation on color usage, with a particular focus on adhering to color contrast standards. Some other common accessibility documentation included tap area, tab order, and read order.

In the case of more intricate components, direct collaboration with our lead accessibility engineer was established to offer supplementary, precise documentation on the component's accessibility considerations during implementation.

Interaction design specifications varied as well. Components with interactive functionality could feature documentation encompassing their distinct visual interactive states and the transitions between them. Each of these component's documentation included details on the skeleton state and how to indicate loading, if applicable.

For components requiring more intricate motion, prototypes were incorporated to illustrate the intended animation, alongside precise property changes and specified motion curves.