Stephen Peaslee
RDC Design System

A small team's journey in creating a design system helps homebuyers find their dream home via an iOs, Android apps and web experience. Our goal on the DSM team was to introduce efficiencies into the design and development process through a new system that would allow designers to build faster, and developers to receive designs that primarily used components that match what is in their library. This story is a brief account of our endeavors what we learned over the 9 month project.

Design stack

Project goals

1 Build

Build an early stage design system

Increase designer efficiency and consistency

2 Integrate

Integrate into existing processes

Increase dev efficiency and quality

3 Adopt

Ramp up adoption

Better tech performance, scalable experiences

Project challenges

30x~ designers distributed across 3 offices designers were distributed across New York, Vancouver and Santa Clara offices. Teams were further subdivided by vertical or group, such as buy/rent/sell or pro/consumer, causing us to plan for many variants in our system, with close collaboration with all partners.

3 platforms with different feature sets and UI

Web, mobile web, Android and iOS were our primary properties, however each experience had drifted slowly apart over years in terms of patterns and features. One of our goals was to consolidate these experienes.

Dev inconsistencies and a need for a common library

Developers were finding it tough to keep up with developing so many custom pages and components. While everyone agreed that we needed common components - finding common ground wasn't easy, as designers had good reasons for permutations, and different products/verticals had different needs.


Six steps to building RDC DSM

1. Learn + listen

What does the system need to accommodate? What do our users need?

2. Plan & Prioritize

What were the primary initiatives that would improve our system and increase adoption?

3. Collaborate

Cross-collaboration between development, design and product partnering for integrated solutions

4. Build

Bi-weekly releases adding new features and components and improving foundations

5. Document

Create a better system of documentation helping designs and developers find answers more quickly.

6. Operationalize

Implement DSM into existing processes and ramp up it's adoption.


Learn & Listen

When I joined, the Design System was an early stage component library just being introduced

At the start, the Design System was just released to designers to try out as they pieced together the new designs. It did not seem that many designers were actually using the system, though many had played with it. We listened to their feedback to help us prioritize next steps.


  • How is your experience using the design system today?
  • What would help you in a design system?
  • Why do you, or do you not use the design system today?
  • When you build a new design, where do you start
  • Where are the painpoints in the design process?
  • How does handoff happen with developers?

Learnings sample

Feedback Category Actionable
"The design system doesn't have the components I need Depth Expand component library
"Too time consuming to access type styles from DSM panel every time Usability/Accessibility Sketch integration, workflow
"Sometimes I'll use a DSM component, but usually unlink to make changes" Flexibility Component variants, specializes to teams needs when broadly accessible
"It's hard to tell what's available, DSM panel isn't intuitive" Discoverability Sketch integration, component organization, master sketch sheet

Plan & Prioritize

We categorized learnings and prioritized deliverables on a roadmap

Phase 1

We started by prioritizing our designers pain points, as they would be the ones carrying our system forward. We focused on making hte system easier to use, and building out a solid library.

Components at this phase focused on creating order around what existed on live properties

Phase 2

The next phase, then built out the system aspect, adding major foundations and building extensible rule sets. We continued to improve designer experience, and built out initial comprehensive documentation set.

We continued to build components, but they were now more influenced by evolving and future work.

Phase 3

In the final phase, we continued to move forward with major themes, but directed more attention to integration with development and the design process.

Components were still added on a regular basis, but now with a focus on states, variants and flexibility.

Responsive image


Cross-collaborative effort between product, development and design

Consolidation initiative

Once the DSM defined new components, we needed to figure out how we would enact these changes on our live properties. There were many variations existing on 4 different platforms, and new ones getting designed each day.

For existing instances, developers were able to catelog lists of instances that existed on properties for a component. Design and dev would then look at each and categorize which were similar enough to just replace, and which required further conversaionts. One such example was the Hero Component in the diagram.

For new instances, we found the need to publicize component availability to designers and ensure they were used in new designs to the best of our abilities.



Weekly iteration on system foundations and standardization across experiences


Finding an accessible and sustainable type ramp

Type was an important piece to get right in the DSM. The way that designers collectively use type gives voice to the message.

Unless we created a ramp that was easy to access, and truly added value, designers wouldn’t use our type styles and would continue using custom values.

Read full story Coming soon


Evolving the color Palette collectively

Creating an icon library that is consistent, extensive and meets everyone’s needs is never easy.

We tried to keep the typeface relaxed and approachable like the Realtor brand. Readability, clear meaning, and lack of overlap were key factors.

Read full story Coming soon


Creating a library that was was useful for designers, on-brand and extensible

Web, mobile web, Android and iOS were our primary properties, however each experience had drifted slowly apart over years in terms of patterns and features. One of our goals was to consolidate these experienes.

Read full storyComing Soon Coming soon


Improving design and development documentation

Beginning our documentation journey

Documentation must to start somewhere. But where exactly?

We had a good idea where we wanted to end up, but starting from nothing, and with just a few designers and many priorities we had to take it piece by piece.

We moved from static documentation to a model where our design tokens and components were more closely tied with our docs. As our documentation evolved, our requirements for a documentation platform

Read full story

Component documentation

Component documentation covered everything you need to know about a specific component, including purpose, visual examples of UI, differences across platforms, and do/don’t examples for usage.

See full example

Foundation documentation

Foundation documentation covered the rules of the system for topics such as type, color grids ect. We also included info here on how to access and make the most of DSM styles through Sketch interface.

See full example


Increasing designer adoption and integrating system into existing processes

Following the component flow

How do we make this system extensible in a way that it could evolve alongside the organization?

There needed to be two-way influence between new designs and the system, and some kind of enforcement to ensure that the system was used more often than not to reduce one-off custom builds that slowed down development over time.

DSM drop-in

DSM team held an extended morning standup with design and development partners, where non-DSM designers (or anyone) could drop in to see what is happening, contribute to the system, or get feedback on evolving designs.

Sometimes we invited people we saw were doing unique work, or in verticals we were not involved with, and found out how we could make the system work better for them. Other times people just showed up by themselves with questions, ideas and new perspectives.

Consolidate, adapt or one-off

When reviewing any design at either touchpoint, we checked to see whether their design followed the rules of the system and used approved components. Any components that were new, we highlighted and discussed. They were then either:

  1. refactored into an existing component if there is one that fits the use case or is similar
  2. adopted to the system, if the design had a broad use case that was not yet covered
  3. or added to one-off library which consisted of exceptions that we let pass but would not include within our system

Challenges in sequencing

One of the more interesting challenges here was sequencing. Designers have so many components designed, and developers have so many of those built - how do you filter new incoming designs through what is available on both sides?

Our answer was close collaboration between teams working on UI library and DSM team, and a focus on documentation. At DSM Review, and as a design hit development, we had two opportunities to flag a design and ensure it was categorized correctly.

In conclusion...

Though we were able to quickly build and operationalize a design system, the work was just beginning

Work for a design systems team is never complete

Many times throughout this project, we were asked by stakeholders and partners, "So, when will it be done?". It always gave us some odd pleasure to reply, "never". A design system is always evolving and on it's way from here to there.

We saw the RDC DSM system on it's way from crawling to walking. With a sustainable set of fundamentals, a strong component library, and an integrated documentation system - it was in a good place to continue growing and adding efficiency to the organization.

Thanks for reading!

back to Home