The UX Design Library was an organizational-wide effort to systemize and centralize all of our UI components from a Design & Development perspective. The effort produced a matching set of library components in both code and design repositories.
This project was a fun collaboration between another designer and me. We both nerded out on organizing and codifying the library. While I did not create the initial set of components, we took this initial collection. We made them organized, symbolized, discoverable, searchable, responsive, and fully mapped to a base set of styles.
I also created a complete click-through prototype to serve as a documentation website for Devs, Product Managers, et al. The objective being a centralized documentation site.
UX Team - Sr. Product Designer
Internal UX Team, Development Teams, Product Managers, et al.
Organize Common Components, Codify Browsable & Searchable Naming Conventions, Responsify & Symbolize Components, and Documentation Website Prototype.
The three most pronounced challenges were around organizing, renaming, remapping, and responsifying the components. For example, we needed to organize and collate the various components, which were already centralized, but needed to be organized. We also needed to determine the most systematic way of renaming and remapping all styles to a baseline set of colors, typography, and layer styles. Lastly, we need to build each component with the ability to resize and expand gracefully based on the component type. For example, buttons that auto-expand, icons with fixed size and aspect ratios, pinned nest containers for consistent spacing, etc...
Due to the weight and inflexibility of maintaining one centralized file, my colleague Sam and I split the work and divided all major component types into their own respective files. For example, we broke down the files into fundamental categories such as Typography, Buttons, Colors, Containers, Forms, Icons, etc.
Taking this path made it easier for any given designer to jump into a file and update a component with less risk of overwriting someone's work. It also lightened the library's overall memory footprint, which helped with computer performance and the reduction of grey hair production.
Once we codified and organized all of the components into symbols, it was now super easy to quickly query or browse for components you needed to build out a page. To make symbols easily searchable, we used a numbering system that allowed us to control the sort order of the results; this helped with the browsability of the symbol menus and more accurate search results.
As part of establishing a consistent naming convention, we also grouped components by category and state, making it super easy to select a different type or switch the state of a given object. For example, with input fields, you can dynamically change the state of the component from Default to Empty, Placeholder, inFocus, Selected, Filled, or Disabled state, all while maintaining the value entered into the input in the first place.
Once the library files were fully assembled and working great as a daily design tool, we put together a click-through prototype to serve as a centralized reference for our Devs, Designers, PM, etc... to reference when needed. Since each library file was standalone, a designer could easily change it anytime they needed to make an update and push the changes to the docs site with the updated styles and specs.
An interesting challenge arose as we were remapping and symbolizing all of these components. The more components we added to the library, the more it gobbled up the compute of the design program. Chopping the library into various pieces allowed designers to choose the libraries they needed while leaving the rest turned off to have a more performant design experience. This also made the library easier to maintain because multiple designers could edit different files simultaneously.