Goals

We set out to create a design system that would benefit all of RE/MAX's digital product teams, regardless of the pace at which their respective teams were able to implement such a system. We knew that each product and team is a unique situation and by no means were we in a position to dictate the cadence of the adoption of our system, so we needed an approach that could be implemented at different paces.

This included things as simple the entirety of the design team opening up communication and agreeing on stylings to use going forward and creating Figma libraries and rules for the team to use and follow. But that was just the tip of the iceberg. We also set out to create a universal design tokening system that could be used by all the teams to attain consistency at a deeper level. We also connected with front-end developers in a much closer manner by helping out with component construction directly in the code (all while using our design tokens).

Responsibilities

This project required quite a few responsibilities from me as it was the inception of our design system and there was much to do without many resources. My responsibilities included creation and management of:

• Design resources
• Design tokens
• Documentation
• Jira project and board

On top of the general design system responsibilities above, I also worked within one of our web product's repository to tweak and style the coded components (utilizing our design tokens). Additionally, as the lead of the project, I oversaw and directed another member of the product design team who was allocated part of their time to work on the system. I also led the charge for teaching about and advocating for the system across different teams and departments within the company.

Product structure

As mentioned above, RE/MAX had a wide range of digital products and, as such, needed a bit of structure, or at least common understanding, to help us determine how best to make a new system function. Documenting this overarching product hierarchy would prove to be the framework needed to structure our Figma libraries and also a model for our design tokening structure.

The RE/MAX tech. product structure

RE/MAX brand

We started by creating an overarching system that any of its children systems could pull from so that those child systems could be unique, yet still consistent with the RE/MAX brand. This overarching system consisted of a brand color palette, iconography, and other assets such as logos and images.

Audiences

RE/MAX's tech. products can be categorized by the audiences that they target: those for use by its agents and those used by its consumers (people looking to buy and/or sell property). One of the long-term goals was to unify both of these systems, but we decided that in the short term we should focus on making the products within their respective audiences align with each other.

Platforms

Within each audience, the products can be further categorized by the platform that they're on. For instance: Android and iOS both have native paradigms that should be respected, and both differ from a web implementation.

Design resources

Library management

The tool of choice within the product design team was (unsurprisingly) Figma. Since our design system structure was multifaceted, we created multiple, interconnected libraries within Figma that could trickle down changes when needed.

A couple of the connections between libraries

Components

Loving the technical aspect of design, constructing components that work the way that the team needs and expects them to is right up my alley. This process went beyond just the design side, but also included aligning our Figma components with the dev. teams on how those components would actually be built; I take pride in being a bridge between design and development!

A few of the components from the consumer web library

Design tokens

While there are innumerable examples of systems utilizing design tokens, we struggled to find many that were publicly available that matched our needs. Because of the breadth of RE/MAX products that we set out to unify, we wanted to create a tokening system that would accommodate multiple platforms, products, and themes. Adobe's Spectrum design system and Google's Material Design system provided great resources for us to go about establishing our tokening system. Both of these systems utilize a multi-level token structure which we felt would be extremely beneficial for our needs.

The token class structure (view the FigJam)

If this looks similar to our product structure to you, good eye! There's a theme! Diagraming out the product structure really helped in determining how our tokens could and should be structured. It also vastly helped with showing and explaining to the design team how the tokens translate each other as well as giving other stakeholders a visualization of how our system was structured and interconnected.

Token translation

The RE/MAX design system utilized three classes (or levels) of design tokens, each with a unique role in what it is meant to accomplish. Each class gets translated to its reference all the way up to the absolute value.

The journey of how tokens are translated for multiple themes

Global tokens

The global token translation

Global tokens represent absolute values that make up the RE/MAX technology look and feel. Everything from color hex codes to font families and weight to icon and logo files to size distances. Every building block that makes up the RE/MAX technology look and feel is represented in the global token set.

Global tokens JSON for color

Theme tokens

The theme token translation

Theme tokens give the design system a way to accommodate the varying looks and feels that RE/MAX technology may have depending on the audience or platform of an individual product. These tokens reference global tokens so that we can design for a specific product's needs while still maintaining the RE/MAX technology aesthetic. They also help us to quickly and easily transform a product's style to match its segment, such as with the remax.com standard and luxury (Collection) styles.

Theme tokens JSON for color, including both themes

Platform tokens

The platform token translation

Platform tokens are an exhaustive representation of every spec associated with a component within a product's platform (Android, iOS, web, etc.). These tokens reference theme tokens so that an element can be easily themed while remaining the same in its construction.

Platform tokens JSON for the button component

The process for the creation and implementation of the platform tokens started off a bit circular:

1. Creation of design component by the design team
2. Creation of coded component by the dev. team
3. Tokens created by the design team
4. Tokens implemented by the dev. team
   
5. Tweaks to tokens or component by both teams until finalized
   

But after getting us set up in the design system repo., we eventually took over the implementation and final tweaks for a much simpler process:

1. Creation of design component by the design team
2. Creation of coded component by the dev. team
3. Tokens created and implemented by the design team as well as any needed tweaks to the component

Accessibility

Creating accessible and usable products was a top priority (as it always should be). The goal was to bake in WCAG standards into as much of the system as we could, but we also acknowledged that it's just not possible to make it 100% perfect systematically and that we would need processes in place at the time of usage to make sure we were adhering to standards.

Color

The aliased colors that we created and their respective names were explicit to their use case so that the chances of inaccessible combinations would be mitigated. We also made sure that any components utilizing a danger (red) or success (green) color included support text defining its status.

Images

We created a component solely for the usage of images. By doing this, we could surface properties so that engineers placing an image (with potential help from a designer) would have to make the distinction of whether the image was informative or not and, if so, provide appropriate alt text.

Text

We also created a component solely for the usage of text. This ensured that text on any given page was using the appropriate element type, such as paragraph, heading, etc. On the topic of headings, we ensured that the proper hierarchy was adhered to (h1 → h2 → h3 → h4 → h5 → h6) and that only a single h1 was used on a page.

Interactive elements

With interactive elements, we made a point to not override any focus outlines. Proper tab order was emphasized as well as a solid focus trap for our modal component. Buttons and links were also well defined as separate components, even though some links had the appearance of buttons. This ensured that the differing keyboard interactions (space vs. enter/return) worked as expected. We also made sure to give any interactive element descriptive language in its label and/or title using a standard {verb} {noun} pattern.

Documentation

We needed an an out-of-the-box documentation solution so that we could focus our effort on the system itself and not the system's system. We found zeroheight to meet most of our needs.

zeroheight was great to work with for its integration with Figma and Storybook. We could tap directly into our library files and stories to pull styles and components into the documentation and could update from Figmaand Storybook as needed. We also created a dedicated documentation file in which we created frames for examples and callouts that, just like with the library integration, could be updated easily without having to deal with exports and uploads.

General documentation

Since we had a tiered system, you utilized our global system to capture some of the general aspects such as info on our design tokens.

The global documentation for the design tokens

Styles

Styles were documented mainly to capture available options for designers and also technical specifications, including their platform tokens, for developers.

The consumer web documentation for typography

Components

Much like the style documentation, the component documentation aimed to capture any and all of the technical specification for each component. Usage guidelines were to come when the designer working with those components had time to formulate that information.

The consumer web documentation for the button component

Postmortem

In July of 2022, RE/MAX announced that it would be sunsetting most of its internally-developed technology offerings. As a result, 17% of its staff, including myself, was laid off thus ending my work on the project.

What I learned

I'm honestly not even sure where to begin with what I've learned from this project since I felt like I was learning something new pretty much every day, and I love that. While some aspects such as Figma and design resources I already had a firm grasp on, others like the design tokens and Git were completely new to me. But everything captured in this write up has helped me to grow as a design system product designer including further expanding how I think about all aspects of a project or system such as this one. Opening up paths of thinking into areas that could be affected by a decision on a completely opposite side of things is a skill that has been invaluable to have and further sharpen.

What I would have done differently

Reflecting back on this project, I think that the one main thing that I would have liked to go more in on was vocalization about the system to outside parties within the RE/MAX tech. org. While there was general awareness of work on the design system in attempt to unify our products, I felt it was mainly in the dark to most, partially because it was still fairly in its infancy. I don't necessarily think that many outside of the products that we were focused on for the system would have gained all that much from insight on our progress, I do feel that it could have opened up even further communications between teams, even if just a little. I think that this is key for any company, let alone for a design system, and it can absolutely go a long way in not just product cohesiveness but also just inter-team camaraderie.

Final thoughts

While my time on the projects was fairly short, I feel extremely proud of all we were able to accomplish. The learnings and experience gained devising such a multifaceted system and building a foundation that was created from the ground up was invaluable. It was a joy to work with my teammates who were there with me along the ride and who put their heart and soul into this project just as I did. I'll absolutely miss the team and working on this project, but I'm thankful for the opportunity that I was given to be part of it. ❤️