Mortar design system

Background

Overview

Apartments.com already had a design system in place that all the designers on our team used. It was robust enough to create many designs with minor adjustments, but it came with its fair share of problems due to insufficient maintenance. Although having a set of rules was good for guidance, it was so difficult to receive support for Mortar that new designers were barely referencing the design system. The design system also desperately needed a refresh as it had not been touched in years. After designing with the system for a few months, the design team collected our frustrations with the system and I began making updates.

⌚ Timeframe

2022
3 months

🗣️ Team

2 designers: Nathan Pak and me
3 front-end developers: Jana Abumeri, Martin Ayon, and Leah Klamkin-McCarter

📦 Deliverables

Updates to the documentation and design system files

Problems

Obscure hosting sites

Invision Design System Manager

Our documentation was hosted on Invision Design System Manager. Because our team worked entirely on Figma, it did not make sense to access the Invision Design System Manager (DSM) for clarification about our design system.

Storybook components

Only a few front-end developers were aware that there was a Storybook resource that contained all the coded design system components. During my time at the company, developers were constantly copying over code from previously created pages or coding from scratch in order to put together the pages they needed. This meant that plenty of code was not linked to the correct style definitions.

Inconsistencies

UX designers were breaking components out of necessity in order to fit them into recent designs as components were based in outdated Figma technology. This meant many designs required developers to hardcode parts of the page that should have been otherwise reusable.

The lack of awareness about the Storybook site further escalated this problem and made any overall design change to the site difficult as items were not properly linked. This made updating the various pages of the site unnecessarily time consuming for developers.

What we did

My role

Served as the primary point of contact for design system.
Increased visibility for design system resources.
Ensured regular communication with designers and developers.
Modernized the component library and fixed broken components.
Made accessibility enhancements.
Transferred documentation between technologies and and documented new Figma components.
Communicated with developers to ensure parity between Storybook and Figma

Team communication

Our design system team held weekly meetings on Thursday in the afternoon to regroup and share updates on the changes made to the system, further understanding, revisit the usage of the system currently in implementation, and discuss any related topics.

In addition to those meetings, I met with designers multiple times a week to compile concerns and share new developments to the design system.

Fixing components

With the inclusion of auto layout and component properties in Figma, our outdated components desperately needed a upgrade. The focus was on making sure that all components resized properly to all screen sizes, and simplifying components offerings by removing any repeats that could be represented with component properties.

Component & accessibility enhancements

More readable text and buttons

The design system currently in implementation required multiple different style definitions for text. Not only were there sizing disparities, there were different shades in implementation for various text sizes as well. This made the visual hierarchy of pages jumbled.

Old design for the listing detail page

New design for the listing details page

Improvements made to this page:

Hierarchies are more clear as headers are now using bold to create a more notable difference between headers and other text.
Non-header text is all 16px in size to allow for easy readability.
The green used in these designs are now AAA compliant.
Text is consistently left aligned to allow for easy readability.

Adding focus states

One key accessibility concern that our design system had was the lack of discernable focus states. Through comparative analysis with the Google Material system, Intuit Quickbooks, and other design systems, I took notes of different implementations for focus states. After experimenting with shaded backgrounds and increased border prominence, the final design I settled on involved adding a new border with 2px of padding.

conclusion

Outcomes

I gained a deep understanding of the implementation of a design system.
The constant communication with front-end developers taught me more about the way that Apartments.com is coded. These regular weekly meetings informed my choices about how to proceed with my responsibilities.

Takeaways

As much as creating a design system is important, so is the education of new hires about the related resources. Since people were unknowingly locked out of vital references and wiki documents, it became difficult to effectively implement the design system.
Adding more rules about how to use elements in a design system is not always good, especially with minimal support to guide internal users to proper resources for regulation and education.