Work

About

Work

About

Rolling out Realtor.com’s Improved Design system

Rolling out Realtor.com’s Improved Design system

My role

Sr. Product Designer — Design Systems, Systems thinking, Visual Design, Iconography, Interaction design

Timeline

14 months—Launched in August 2023

Team

Bethany Schwanke, Director of Product Design

Kelly Hanner, Lead Product Designer

Joyce Leung, Sr. Staff SWE

Raymond Eng, SWE

Victor Perez, SWE

Jordan Benning, SWE

Overview

In 2022, Realtor.com launched the redesign of its mobile app and saw growth in usage. As a result, the website and app differed in look and feel—and users noticed.

I along with the design systems team led the end-to-end design direction of the web experience. We launched the third version of our design system, scaled its coverage, and leveraged it to deliver the redesign of Realtor.com

The website's launch saw revenue from sales rise by 7%, and rental revenue by 1.5%. User saved searches increased by 18% on for sale properties, 9.7% in searches, and 2.2% on listings. The new version of the design system increased its adoption by 80%.

Context

Establishing a design system team

In 2022, Realtor.com started diversifying its product portfolio by purchasing various real estate enterprises. These newly acquired businesses had to align with the Realtor.com brand identity. As a result of these acquisitions and additional expansion, the product organization grew by 30%, encompassing 50 designers and several hundred engineers. With this evolution, it became crucial to better support and scale the design, product, and engineering functions. I joined the company's emerging design systems team to contribute to these initiatives.

In 2022, Realtor.com started diversifying its product portfolio by purchasing various real estate enterprises. These newly acquired businesses had to align with the Realtor.com brand identity.

As a result of these acquisitions and additional expansion, the product organization grew by 30%, encompassing 50 designers and several hundred engineers.

With this evolution, it became crucial to better support and scale the design, product, and engineering functions. I joined the company's emerging design systems team to contribute to these initiatives.

The problem

A disjointed app and web experience

Realtor’s website and native app differed in visual language. Users noticed this difference right away: they voiced their confusion and mentioned how dated the website looked in comparison to the app, which was refreshed more recently. This was a severe competitive disadvantage, as Redfin and Zillow were steadily increasing their market share of the online real estate marketplace business. 

Realtor’s website and native app differed in visual language. Users noticed this difference right away: they voiced their confusion and mentioned how dated the website looked in comparison to the app, which was refreshed more recently.

This was a severe competitive disadvantage, as Redfin and Zillow were steadily increasing their market share of the online real estate marketplace business. 

Pain Points

Besides the mismatched experience between the website and app, there were other points of friction with the current design system:
Product inconsistency

Component and visual inconsistency across the web experience.

Accessibility issues

Components built by teams missed accessibility requirements.

Misaligned code and design

Design assets and code were misaligned in functionality and style.

Poor guidance

Users struggled to discover the full capabilities of our components.

Low adoption

Teams created custom components, leading to bloat in Storybook and Figma.

Over complex

Many components were too complex, lacked functionality needed, or were no longer used.

Goals

The design system overhaul provided an opportunity to improve process, advance accessibility, provide written guidance, and increase adoption of the design system. Our full set of goals included:
Establish tokens

Bring stored values from the app and apply them to the web.

Improve accessibility

Meet WCAG 2.1 AA accessibility standards and integrate them into components.

Mirror design and code

Match nomenclature, functionality, and styling between coded components and design assets.

Better support users

Support designers and developers through written guidance, office hours, and feedback

Increase system adoption

Increase the percentage of system usage in product development

Component clarity

Craft components that better met the need of our users.

The approach

To accomplish the web uplift, the work was separated into several phases: design, engineering, testing, and roll-out. 

We started with an audit of the native app to assess the situation. After looking through the app, we decided to establish design tokens, redesign components for web, create new components, deprecate unneeded components, build a design library, and write documentation to support it all. My domain was focused on the design of foundational tokens, component s, and patterns. In addition to the research and design of these components, I also wrote documentation and defined team operations.

We started with an audit of the native app to assess the situation. After looking through the app, we decided to establish design tokens, redesign components for web, create new components, deprecate unneeded components, build a design library, and write documentation to support it all.

My domain was focused on the design of foundational tokens, component s, and patterns. In addition to the research and design of these components, I also wrote documentation and defined team operations.

Specifically, the foundations I owned were:

Typography, Iconography, Brand assets, Documentation templates

Within this, I took lead on components and patterns like:

Cards, Tables, Skeleton loading states, Toast messages, Inline messages, Breadcrumbs, Pagination, Tags, Global navigation, Global footer, Global banner

The work flow

  1. Auditing component usage

I started by taking inventory of where and how a component was used in the product. Through this, I could identify how teams relied on the component,  how they were used, unconventional uses and any inconsistencies in styling.

  1. Interviewing designers to identify component need

I interviewed designers across teams to  understand their component needs. These needs varied from component guidance, missing or additional behavior, asset controls, and training.

  1. Usability and accessibility improvements

With a goal of meeting WCAG 2.1 AA requirements, I outlined existing issues with the legacy components. These ranged from missing or inconsistent interaction states, insufficient text sizes, contrast issues, and inadequate touch targets. 

  1. Designing new components

I built each component and its variants out in Figma using auto-layout, our new token set, variables, and robust controls. My goals were as follows:

  1. Visual testing components

I then took components through visual testing. I tested their limitations, the behaviors, the controls, and eventually found out what didn't work. Afterwards I reviewed the components with my design team.

  1. Documentation

After testing and revisions, I documented how to use the component. I included references to best practices and created visual examples of it in use within the product experience.

  1. Hand-off

Then, I handed off components to our engineering team so they could begin development. When a demo was ready for review, I would test each component’s functionality, usage of proper tokens, interaction states, and review their documentation for engineering. We followed this process, one component at a time, instead of redesigning the entire system in one go.

Establishing foundations

We began by creating tokens based on the app’s monochromatic theme. Color, iconography, elevation, radius, border, and typography were accounted for. This would make designing the web components easier.
A Monochromatic theme

Realtor’s native app replaced red as the call-to-action in favor of black. We scaled this change throughout the design system, using neutral colors for primary interactions. By removing red as the primary color, we could thoughtfully reintroduce it along with green, blue, and yellow to be used semantically, in tokens

Realtor’s native app replaced red as the call-to-action in favor of black. We scaled this change throughout the design system, using neutral colors for primary interactions. By removing red as the primary color, we could thoughtfully reintroduce it along with green, blue, and yellow to be used semantically, in tokens

Design Tokens

With a new monochromatic theme, we needed to establish design tokens. These tokens would include styles for colors, borders, elevation, radius, and typography. Many of these styles were directly pulled from native. Other styles were then created for the web, such as our hover state. This empowered us to scale the redesign of our system.

With a new monochromatic theme, we needed to establish design tokens. These tokens would include styles for colors, borders, elevation, radius, and typography. Many of these styles were directly pulled from native. Other styles were then created for the web, such as our hover state. This empowered us to scale the redesign of our system.

New typography

The native app moved away from Roboto and adopted a new typeface, Galano Grotesque, a rounder geometric sans serif. I was tasked to bring the new typeface into the web design system. But because the scaling for mobile and for the web differs, this translation from app to web could not be a direct copy. It required more nuance.

I reviewed Galano to better understand its characteristics and limitations.  Certain findings were less than ideal for digital experiences. For example, the typeface is especially wide. This meant that titles and paragraphs would wrap onto new lines and push content further down.

Another issue was its small apertures (inner space within characters). A's and O's were especially problematic and difficult to differentiate from one another. This problem was exaggerated when increasing the type weight beyond Bold; the native app used Extra Bold frequently. I decided to differ the web typography from the native app to address these problems. 

On web, I chose to use the alternative character set of Galano. The alternative set was optimized for legibility and addressed issues with the A's and O's. I also reduced the weight of our titles to Bold from Extra Bold, to prevent letters bleeding into one another.

Then, I created a typographic scale, using semantic names (Display, Body, Caption) and a numeric scale (800-100) for sizing. Previously, the system did not have these features and designers/engineers were confused by the naming convention (heading-1 through heading-6). This previous nomenclature gave the impression that  sizes could ONLY be used for H1, H2, H3, and so on. With a numeric scale, we avoid this issue and decouple semantic HTML with sizing.

The native app moved away from Roboto and adopted a new typeface, Galano Grotesque, a rounder geometric sans serif. I was tasked to bring the new typeface into the web design system. But because the scaling for mobile and for the web differs, this translation from app to web could not be a direct copy. It required more nuance.

I reviewed Galano to better understand its characteristics and limitations.  Certain findings were less than ideal for digital experiences. For example, the typeface is especially wide. This meant that titles and paragraphs would wrap onto new lines and push content further down.

Another issue was its small apertures (inner space within characters). A's and O's were especially problematic and difficult to differentiate from one another. This problem was exaggerated when increasing the type weight beyond Bold; the native app used Extra Bold frequently. I decided to differ the web typography from the native app to address these problems. 

On web, I chose to use the alternative character set of Galano. The alternative set was optimized for legibility and addressed issues with the A's and O's. I also reduced the weight of our titles to Bold from Extra Bold, to prevent letters bleeding into one another.

Then, I created a typographic scale, using semantic names (Display, Body, Caption) and a numeric scale (800-100) for sizing. Previously, the system did not have these features and designers/engineers were confused by the naming convention (heading-1 through heading-6). This previous nomenclature gave the impression that  sizes could ONLY be used for H1, H2, H3, and so on. With a numeric scale, we avoid this issue and decouple semantic HTML with sizing.

Iconography

We had recently refreshed our product icon library.  But it didn’t cover all icons that were in use on the website. My team worked with our icon designer to expand the current set into one that met the needs of our web product. 

We also proactively addressed the need for additional icons by creating contribution guidelines. In these guidelines, I defined best practices for creating product icons, created a template with key lines, and outlined the process for how to add them to the library.  Within this process, designers needing icons would book time with our team. As a team, we would determine if an existing icon would suffice; if not, then I’d create the needed icon.  This remediation process prevented additional bloat in our icon library.

With this new process, we led the adoption of over 50+ new icons into our system.

We had recently refreshed our product icon library.  But it didn’t cover all icons that were in use on the website. My team worked with our icon designer to expand the current set into one that met the needs of our web product. 

We also proactively addressed the need for additional icons by creating contribution guidelines. In these guidelines, I defined best practices for creating product icons, created a template with key lines, and outlined the process for how to add them to the library. 

Within this process, designers needing icons would book time with our team. As a team, we would determine if an existing icon would suffice; if not, then I’d create the needed icon.  This remediation process prevented additional bloat in our icon library.

With this new process, we led the adoption of over 50+ new icons into our system.

Redesigning components

With the foundations of our new design system in place, we moved onto redesigning our component library. I focused on all permutations of our cards, messaging components, tables, skeletons, and more.
Cards

Despite how common cards are within the Realtor.com products, the previous design system was limited in supporting them. Shortcomings included: Most card variants not reflected in the design library, users unaware of functionality, users unaware of card configurability.

With missing card configurations, users spent a lot of time managing their own card components, asking around to find a copy, or creating their own. So I worked with designers from each team to understand their card needs. This allowed me to craft pre-configured cards that had the controls and features they needed for their design work. As a result I created these card variants: property, article, news, neighborhood, editorial, and action.

While these configured cards addressed how cards were used today, they did not address future needs. To meet those needs our cards were built as a group of reconfigurable subcomponents. Subcomponents allow for modularity, so that teams could put together cards as needed. This allowed for further exploration of cards and an easier time ingesting them into the system.

Despite how common cards are within the Realtor.com products, the previous design system was limited in supporting them. Shortcomings included: Most card variants not reflected in the design library, users unaware of functionality, users unaware of card configurability.

With missing card configurations, users spent a lot of time managing their own card components, asking around to find a copy, or creating their own. So I worked with designers from each team to understand their card needs. This allowed me to craft pre-configured cards that had the controls and features they needed for their design work. As a result I created these card variants: property, article, news, neighborhood, editorial, and action.

While these configured cards addressed how cards were used today, they did not address future needs. To meet those needs our cards were built as a group of reconfigurable subcomponents. Subcomponents allow for modularity, so that teams could put together cards as needed. This allowed for further exploration of cards and an easier time ingesting them into the system.

Inline message

I also worked on new additions to the system, like the inline message. This component is intended to communicate contextual information in a neutral, warning, or negative way. I noticed that designers created variants of something similar to an inline message, but with inconsistent styling. I wanted to establish this as a known pattern and reinforce our use of color as status within our system

Toast message

I worked on our toast messages with a similar goal as the inline message. Toasts would follow the new color tokens and reinforce color with semantic meanings.

Tables

Our system lacked a table component. However, I discovered that our Storybook had a pattern similar to a table.  So, within Figma, I designed the table to be as modular as possible. But Figma had its own limitations with tables. With code, more functionality was possible. So I wrote documentation to reflect the capabilities of tables in code.  This documentation illustrated to designers that more was possible.

Skeletons

I redesigned our skeleton component as a system of subcomponents. Now, users would be able to use shapes as skeleton text to the exact line-height of our type tokens. 

Rollout

Testing the system

After this full process, design teams tested the new library. Designers across the web products recreated their experiences with the new library. We collaborated to identify areas of improvement and gaps not covered by the current system. In this, I also helped designers maximize their usage of the system and troubleshoot issues.  I saw firsthand how well the components worked and where I could improve documentation, controls, and functionality.

After this full process, design teams tested the new library. Designers across the web products recreated their experiences with the new library.

We collaborated to identify areas of improvement and gaps not covered by the current system. In this, I also helped designers maximize their usage of the system and troubleshoot issues. 

I saw firsthand how well the components worked and where I could improve documentation, controls, and functionality.

Revenue-affecting components

After testing the new library, some product designers from revenue-sensitive areas worried about the new look and feel. We decided to be more cautious about these areas and how the new design system would affect them. For example, certain changes would require more testing. Those tests would drive our decisions with how we approached certain components.

After testing the new library, some product designers from revenue-sensitive areas worried about the new look and feel.

We decided to be more cautious about these areas and how the new design system would affect them. For example, certain changes would require more testing.

Those tests would drive our decisions with how we approached certain components.

One issue was with the Lead Form on the Property Detail page. This form allowed users to submit inquiries into a specific property. Recent tests demonstrated that inline fields and a condensed date picker were superior components for this use case.  We then needed to implement these component variants. 

One issue was with the Lead Form on the Property Detail page. This form allowed users to submit inquiries into a specific property.

Recent tests demonstrated that inline fields and a condensed date picker were superior components for this use case.  We then needed to implement these component variants. 

Sandboxing the new visual look and feel

After we completed these design system updates, the product org froze feature development and testing to prepare for the launch. 22 Product developments teams across the company collaborated to build out sandboxes using our new components.

During this time, I worked with designers and engineers to QA their experiences. This was another time where we could identify any problems with the new system components, and easily fix other quick-win issues. Certain areas of the product where there was a lack of design or engineering resources would be entirely up to my team to handle.

After we completed these design system updates, the product org froze feature development and testing to prepare for the launch. 22 Product developments teams across the company collaborated to build out sandboxes using our new components.

During this time, I worked with designers and engineers to QA their experiences. This was another time where we could identify any problems with the new system components, and easily fix other quick-win issues.

Certain areas of the product where there was a lack of design or engineering resources would be entirely up to my team to handle.

Launch

The rollout of the new look and feel of Realtor.com was phased by traffic, scaling from 1% to 100% over a month. A scaling rollout, gave us the opportunity to capture user feedback, bugs, and monitor metrics closely. 

These data points impacted the timing of the rollout. The full 100% launch happened 2 weeks sooner than expected. Product and revenue metrics reported a greater than expected rise. Revenue from sales rose by 7%, rental revenue by 1.5%. User saved searches increased by 18% on for sale properties, 9.7% in searches, and 2.2% on listings.

The rollout of the new look and feel of Realtor.com was phased by traffic, scaling from 1% to 100% over a month. A scaling rollout, gave us the opportunity to capture user feedback, bugs, and monitor metrics closely. 

These data points impacted the timing of the rollout. The full 100% launch happened 2 weeks sooner than expected.

Product and revenue metrics reported a greater than expected rise. Revenue from sales rose by 7%, rental revenue by 1.5%. User saved searches increased by 18% on for sale properties, 9.7% in searches, and 2.2% on listings.

Reflection

Narrow scope on component functionality

It's tempting to fill out a component's function to all "standard" use cases. When the case arises then expand function, but never before.

Revisit tokens after all components are created

One con of the piecemeal approach is that small style inconsistencies made it to launch

Differ component controls for designers and engineers
Don't s

Engineers and designers interact with components differently. How you build controls for those should be tailored to them.

MENU

Home

About

LINKS

LinkedIn

Codepen

GET IN TOUCH

ericdruperto@gmail.com

© 2025 Eric Ruperto. All rights reserved.

Based in Portland, Oregon

ERIC RUPERTO

MENU

Home

About

LINKS

LinkedIn

Codepen

GET IN TOUCH

ericdruperto@gmail.com

© 2025 Eric Ruperto. All rights reserved.

Based in Portland, Oregon

ERIC RUPERTO

MENU

Home

About

LINKS

LinkedIn

Codepen

GET IN TOUCH

ericdruperto@gmail.com

© 2025 Eric Ruperto. All rights reserved.

Based in Portland, Oregon

ERIC RUPERTO