My role
Vision painting, tear down and assessment of third-party systems, designing foundational assets, color set, type scale, page templates, page grids, components and patterns. Documentation writing, art directing product designers using the system and system designers designing for the system. Creating and contributing design tokens.
What you'll find here
Following are snippets of the documentation that was found throughout the design system Figma files. These snippets summarized the work that was created and explained how it should be used.
Page sizes
There are two page layout types: Fluid and Max-width. Max-width pages have three different sizes: small, medium, and large.
Typography
OS system font
The system uses the OS system font stack. This method pulls a user’s local operating system font and uses it as the application’s primary typeface, matching other operating system applications and reducing page load.
Type scale & paragraph measure
A broad type scale offered our product teams a wide range of paragraph sizes and headers to work with, and the built-in paragraph max-widths ensured better readability in wide layouts. This exact type system had already been well developed by other talented folks in the UX organization, and I saw no reason to deviate from something that had worked so well. The only adjustment I made was to the exact paragraph measure (max-width) calculation, which I increased since B2B experiences tended to have denser copy than shopping experiences.
Icons
Another way we accomplished a lot in a little amount of time was to use the Material Design icon library for our utilitarian icon needs. Of course there are trendier, more appealing (in my opinion) icon sets out there. However, none of those sets are as comprehensive, widely-understood, and scalable as the MD icons. When a small team needs to do a lot in a little amount of time, the MD icon set can make a lot of sense.
Color
This is a simplified version of the color set I created for the system, using 3 brand colors as the starting point. I am presenting this simplified version because if I were to do this all over again, this is the way I would do it. The original set accomplished exactly the same thing with naming that was a bit more confusing and some colors that were not meaningfully different from each other. In the version you see here, I've omitted the darkest and lightest values from each hue except for the neutrals. This makes the system's black and white colors the business of the neutral hue, leaving the accent colors to only serve the jobs assigned to their hue.
Accessible combinations
Different hues available in different brightness values allows for accessible contrast requirements to be met by following an established combination.
Buttons
About halfway through the life of the system, we rolled out an update to our buttons that responded to feedback from our product teams, both directly about the visual design, and through our own observations of confusion around which buttons styles to use when. We simplified the button types from four to two—primary and utility—and used variations within those types to serve the needs of various nuanced scenarios.
Cards
Another update made to the system after some time in use was to simplify the card formats. We originally had quite a few very specific card types and layouts made for very specific scenarios in the product. We updated to introduce more flexibility to teams while reducing the number of card types.
Form elements
In addition to setting up the styles for the expected form elements, I also created a layout structure that standardized the spacing between form elements. Whether working in Figma or code, the structure, spacing, and naming of elements was the same.
Data tables
The functional requirements for data tables was massive, and no internal system had ever accommodated everything. Our first effort therefore, was to look outside to third-party design systems to see if anyone had solved all the table problems we needed solutions for. We had no luck. The best we found was that Material Design had a pretty good base structure in place, and we decided to use that to build on top of.
With all different use cases and requirements documented, I again looked to third-party solutions to see how the rest of the world solves these problems. Some of our requirements seemed to be anomalies, with no reasonable alternative solution, while many others were solved by other systems, albeit, and of course, without regard for our other requirements. One method would cause problems for another. I worked through all these issues to create a data table framework that solved all of our documented use cases.
The work below is just a glimpse of the documentation that extensively covered all that a designer working with data tables was able to work with.
