Angelou Design System

As Newsela continued to grow as a digital product, our demand for a unified visual and interactive experience grew in tandem. To address this, Newsela established a design system team responsible for developing a modular component library to be integrated throughout the entire product. The aims were designing components for validated global needs, providing some customization for sustainability, and offering detailed specifications for engineers and designers.


Visual product designer




2020 – 2023

Team Size:

~6 members

i. Challenges

Constraint vs. flexibility.

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.

Validating components.

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.

Standardizing responsiveness.

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.

Evolving team processes.

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.

ii. Component Design Process

Component research.

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.

Anatomy and variability.

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.

Spacing and sizing.

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.

Usage guidelines

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

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

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.

ii. Select Contributions

Info modal

The modal solution was the most intricate component I led the design effort for. This component required meticulous attention to responsiveness, resulting in the creation of two distinct states: floating and screen takeover. These states catered to large and small screens respectively. Consequently, I developed detailed documentation that elucidated the specifications for each and explained the transition between states, which was contingent on varying viewport dimensions.

The internals of the modal also required flexibility due to its versatile usage. To address this, I designed the component with sub-components: a modal header, body, and footer. This approach provided structure and standardization for the header and footer, while allowing the body to remain adaptable for various potential uses by designers.

Filter and input chips

Designers requested the incorporation of chip components into the platform without fully recognizing how the component would fit within our component ecosystem. Upon conducting research, I realized the importance of categorizing chip usage into sub-types: filter and input chips. This decision aimed to prevent any overlap with the role of the button component in our library and ensure clear and distinct usage paths for chips.

Both chips needed to have a chip-like appearance, yet each had distinct states. "Filter chips" required toggle states (on and off), while "input chips" contained user-entered or selected information, necessitating a clear dismissible action. Both types required comprehensive documentation detailing their placement within chip groupings, as the ability to group them was a fundamental aspect of the overall chip design.

Progress indicators

Progress indicators were categorized into two sub-types based on their timing: determinate and indeterminate. Both these styles, linear and circular, required consistent visual design. To differentiate their timing types, I utilized animation styling and text elements to allow for accessible, textual communication on their loading states.

"Determinate" progress indicators aimed to communicate the remaining amount or time until loading completion. In contrast, "indeterminate" indicators avoided specifying the remaining amount, necessitating a more ambiguous motion to indicate timing. Both types required various potential sizing and color options, dependent on their implementation within the product.

Other Case Studies