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
Sr. Product Designer — Design Systems, Systems thinking, Visual Design, Iconography, Interaction design
Timeline
14 months—Launched in August 2023
14 months—Launched in August 2023
Team
Bethany Schwanke, Director of Product Design
Bethany Schwanke, Director of Product Design
Kelly Hanner, Lead Product Designer
Kelly Hanner, Lead Product Designer
Joyce Leung, Sr. Staff SWE
Joyce Leung, Sr. Staff SWE
Raymond Eng, SWE
Raymond Eng, SWE
Victor Perez, SWE
Victor Perez, SWE
Jordan Benning, 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%.
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.
Component and visual inconsistency across the web experience.
Accessibility issues
Components built by teams missed accessibility requirements.
Components built by teams missed accessibility requirements.
Misaligned code and design
Design assets and code were misaligned in functionality and style.
Design assets and code were misaligned in functionality and style.
Poor guidance
Users struggled to discover the full capabilities of our components.
Users struggled to discover the full capabilities of our components.
Low adoption
Teams created custom components, leading to bloat in Storybook and Figma.
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.
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.
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.
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.
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
Support designers and developers through written guidance, office hours, and feedback
Increase system adoption
Increase the percentage of system usage in product development
Increase the percentage of system usage in product development
Component clarity
Craft components that better met the need of our users.
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
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
Cards, Tables, Skeleton loading states, Toast messages, Inline messages, Breadcrumbs, Pagination, Tags, Global navigation, Global footer, Global banner
The work flow
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.
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.
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.
I interviewed designers across teams to understand their component needs. These needs varied from component guidance, missing or additional behavior, asset controls, and training.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
Engineers and designers interact with components differently. How you build controls for those should be tailored to them.