DLUX Design System • Custom PagesHomepage Photo Uploader


CASE STUDY 1

DLUX Design System

Late 2017-2019

 

ZapLabs, owned and operated by Realogy, is a technology team focused on delivering great web & mobile products to real estate agents, brokers, and their clients.

When I joined ZapLabs in 2017, the team had grown from 4 to 14 teams, and we had to wrangle what had become a mess of errant patterns, duplicated experiences, and far too many button patterns. The team had already identified a potential solution: creating a design system. Only, we weren’t quite sure where to start.

 
 
We needed to deliver consistent UI specs across 14 teams, so we built a Design System for our standards could scale.
dlux-designsystem.jpg

The Team

Working with a team of designers and front end engineers, DLUX is truly a design driven effort. The team consists of Melissa Gamo, Visual Design, Rogelio Calleja, Product Designer, Charles Solla, Dir. of Design, as well as created channels to allow the larger design team to contribute. For Engineering, we worked directly with engineering leads and contribution team across the org.

My role in this project was to lead the concept development and definition, as well as drive the team into execution for our dlux.zaplabs.com microsite. I had the opportunity to conduct design thinking events that were foundational to defining our design system, as well as delegate key activities across the team, all while contributing directly to the content guidelines for Design Principles, Mobile First, and Grid behaviors.

 
 

Design Approach

After the team identified the need to create a single source of truth with a design system, the following process went underway:

  • Audit existing products for all patterns & their variants.

  • Work with team to redesign patterns

  • Create Sketch library that contained all new patterns and share to teams.

  • Replace inconsistent patterns with new pattern iteratively as engineering time allows.

  • Socialize new patterns with comprehensive guidelines across product and front end dev teams.

We hit a major road block as we realized that even if we all used the same patterns in design, development still ended up with duplicate work. So we ventured over to the front end team, and had a chat about reusability and development practices.

 

Collaborating with our Developers

After realizing this initiative was bigger than just design, in Dec 2017 we got together with our developers and asked: why was it such a challenge to keep work to a consistent quality? why did shared spec artifacts only get us so far?
We looked at other design systems. We learned we were missing a few key items: A living code repository and a core foundation of shared principles.

Enter Web Components

A design is only as good as it’s medium. In this case, we wanted to understand what frameworks were critical to support.

A design is only as good as it’s medium. In this case, we wanted to understand what frameworks were critical to support.

Our developers decided
to eschew popular frameworks. We chose to build out the patterns as reusable web components
in a common vanilla javascript markup for maximum portability across different apps, including PWA’s. Components could be (and later were successfully) ported into frameworks like React.js, Vue.js, etc.

 

Design Principles

While our development team went to define their own practices, we created a list of attributes we admired in high-quality design work: things like Clarity, Beauty, Intuitive. The team never really found these actionable, and they weren’t helping us stay aligned as the team grew from 4 to 14 designers in the course of a year.

 
IMG_8416.JPG

I wanted to know from the team, what keeps getting in our way of offering great design to our agents? We then wrote out a list of our worst habits.

I asked the team, how do we counter these habits, and define themes that we felt empowered us to do better. With fresh eyes a few days later, we narrowed it to just 5:

  • Be Useful

  • Be Clear

  • Be Where Our User is

  • Find Confidence

  • Respect Relationships

Into Execution

5. Mobile @320.png
Tour Home module prior to DLUX - Not mobile friendly,

Tour Home module prior to DLUX - Not mobile friendly,

 

We took some of our most egregious legacy patterns, such as our Request a Tour modal, and re-imagined it with our new system. Could the UI kit we created fix our lack of responsive layouts? Could the new standards easily flex to our Brand patterns?

We vetted our designs and web components for extendability within the production environment for a full month before porting the components to new features, ensuring stability.

Showing Mobile, Tablet and Web Breakpoints

Showing Mobile, Tablet and Web Breakpoints

Specs for visitor v. logged in states, w/ cascading brand logic.

Specs for visitor v. logged in states, w/ cascading brand logic.

 

Our UI had to be white-labeled to many different branding schemes. Lucky for us, Century 21 went through a major rebrand in 2018 giving us the opportunity to pressure-test DLUX against static brand work provided by Mullen + Lowe. We were able to stay true-to-brand with our system, proving our guidelines were rigid enough to allow dynamic re-skinning without breaks, but fluid enough to allow for major differentiation in look & feel. A huge win for DLUX.

 
Modal Spec Patterns

Modal Spec Patterns

UI Spec Examples

UI Spec Examples

DLUX v1 Type & Color System - Corralling the legacy system.

DLUX v1 Type & Color System - Corralling the legacy system.

Type & Color v2 — Moving beyond the boundaries of the legacy platform, and improving readability & ADA compliance.

Type & Color v2 — Moving beyond the boundaries of the legacy platform, and improving readability & ADA compliance.

 

Outcomes

Our design system impacted is in a bit of a cascade as we hit each milestone:

  • Milestone 1: Delivering a V1 sketch library

    • By simply corralling all of our patterns into a shared library, released to the team mid q4 2017.

    • Our designers were no longer creating duplicate work for their contributing engineers, providing a more consistent end UX.

  • Milestone 2: Delivering our first web components

    • Q1 & Q2 of 2018 was all about building out our code components. We launched our first dynamic web component, the global sites navigation, in June 2018 to most of our consumer brand products.

    • Our developers no longer needed to recreate existing patterns, coding to new DRY, SOLID, stamp-able standards.

  • Milestone 3: Creating our first DLUX-only feature

    • Our Custom Pages feature was the first product delivered entirely with DLUX standards & web components. We even replaced some of our legacy work.

    • We were able to release parts of this feature outside of our monthly release cycle, accomplishing a continuous delivery goal alongside this milestone.

    • Once launched, it was our first truly responsive feature.

Since hitting these milestones, we have converted our entire product development process to utilizing the DLUX standard, and these web components are driving the rapid development of our next generation of real estate products.

 
 

CASE STUDY 2

Custom Pages

Early 2018

Of the many products ZapLabs offers, one key offering are Agent Websites. Any agent at one of our large brands (Century 21, Coldwell Banker, ERA, Better Homes & Garden Real Estate) gets access to their own SEO optimized listing search website.

Often this feature was contentious amongst users, as it didn’t offer the level of customization many agents would prefer to see. They needed to be able to create landing pages for unique listings to support their seller clients, or offer information about neighborhoods in their market, in addition to hosting a plethora of unique marketing experiences.

 
 
Our agents are unique and needed unique marketing, so we launched a dead-simple page creator for ultimate flexibility.

The Team

I worked in a pod consisting of Maryam Bacchus, Product Manager, David Gil, Lead Engineer, and other pod contributors to deliver this v1 custom page content creation experience.

Goal

Offer a light weight custom page creator UX within our legacy CRM to allow Real Estate Agents and Brokers a simple, highly flexible content experience. The UX needed to be simple, straight forward, and provide room for iteration as new functionalities, such as contact forms, are appended to the experience overtime.

 

Outcomes:

Since launching in late 2018, 2,000 agents & brokers have added over 4,000 custom pages.

We extended the same functionality into our Blog to improve our content creation UX & extend Quill functionality to all our content experiences, and saw over 3,500 agents create over 16,000 pages created with this UX as of 6/2019.

NPS comments have gone up significantly, with requests for more customization around websites down in correlation.

 

CASE STUDY 3

Homepage Photo Uploader

Early 2019

 

Our brand partners had relied on manual deployments to update homepage content for their global websites. We wanted to give our partners an easier way to self-manage content in their homepage carousel, and allow them to link high quality hero images to featured listings or unique marketing content to support their digital media mix. Our goal was to offer something completely self-service, that would give brand teams freedom to update and manage their homepage hero content.

 
 
We had a small window to build something really useful for an internal tool, so we did.

The Team

I worked directly with Saurabh Mallik, Product Manager, alongside members of our product operations and brand success team to identify opportunities to simplify this manual process.

With contribution from our lead engineers, as well as contribution work from Jessica Dee, Jr. Product Designer, we identified a simple yet powerful application that could be built quickly for our brand partners. My role was to oversee the definition and execution of a simple solution that would allow brand teams to manage content directly with minimal ongoing engineering overhead from our team.

Design Approach

After defining a basic information structure with our engineering leads, we took the following steps:

  • Whiteboard a few initial layouts with the internal team trying to balance speed of execution with something that would really improve the workflow for our brand partners, ensuring we could identify necessary dev constraints up front.

  • iterated with continuous feedback via internal sanity testing, some usertesting.com testing with marketing professionals, and finally tested a vetted high fidelity prototype with our brand partners.

  • As the primary advantage of this feature was to reduce our own overhead effort to maintain our brand partner sites, we measured how self-service the UI was by asking users to explain to us what they were seeing and what they expected to occur.

  • Along the way, we fine-tuned the final experience after collecting feedback across all user groups and identifying the smallest meaningful offering, one that offered enough functionality to support the daily operating needs of our brand partners with minimal development sprints.