HomeLight

Process, Data, and Documentation (2020-2023)

HomeLight is a prop tech company founded in 2012. At time of launch, the service was dedicated to matching potential home buyers with the best real estate agents in their respective areas. After a great deal of success on this front, HomeLight decided to expand operations beyond agent matching and into the entirety of the home purchasing process.

Roughly, this process has three stages: finding an agent, engaging with the market, and moving into the financial transaction. HomeLight already had the first stage covered, and chose to approach the latter two by acquiring SF-based Disclosures.io (where I served as Lead Designer), and NYC-based mortgage startup Eave Inc. HomeLight’s challenge then became unifying these 3 products into a comprehensive, end-to-end real estate operating system. And equally important was the task of cultivating a new company culture, bridging its traditionally biz dev-centric approach with a contemporary, Design-led product development process.

To get started, we focused on 3 core areas:

  1. Creating a product knowledge repo filled to the brim with useful info, research, and design artifacts

  2. Building a proper Design System

  3. Expanding, improving, and standardizing design file format and documentation

Here’s what it looked like.

Introduction

Understanding the Challenges and Mapping the Terrain

Historically, the core of HomeLight’s UX happened on the phone. While digital interfaces were used for onboarding clients, tracking agents’ progress with leads, and for internal sales operators to manage their work, the company’s money was ultimately made or lost in real-time phone calls between real estate agents and home buyers and sellers. So facilitating those is where much of the attention went.

Accordingly, parts of the website had been built in something of a high speed “design-as-a-service” model, responding to business needs as they arose. There wasn’t a lot of documentation, similar components were built multiple times and in slightly different ways by siloed business units, and there was a lack of visibility into how data moved into and around the HomeLight system.

If we were going to establish a standardized, repeatable product design process for the whole company, we had to start by mapping what was already there. Through the creation of detailed data diagrams, user flows, information architecture maps, and service blueprints for already-existing products, we started building up a knowledge base for each piece of the website.

Creating a Design System
With the Design Team growing and several big new projects emerging from the integration of HomeLight, Disclosures.io, and Eave, it made sense for us to start building HomeLight’s first proper Design System. We brought in some interested developers to help us plan scope and select technologies, and eventually settled on using the Figma plugin Storybook to connect our master component library with the live implementation of the code.

For this first version of the DS, the team chose to keep it simple and focus on foundations - type, color, buttons, inputs, toasts, etc. It’s never easy getting a design system properly implemented, so confining our first pass largely to “atomic” elements with a handful of frequently-used “molecules” like modals or wizard flows made the most sense. More complex components could be approached later dependent on the uptake and utility of what we’d build in the first pass.

Documentation & Delivery
As remote work continued through the end of 2020 and HomeLight Engineering team grew substantially through hires in Brazil, Argentina, and Mexico, the need for consistently formatted and clearly documented design files became more pressing. Whether onboarding new teammates, getting veteran employees quickly up to speed on new projects, or preserving institutional knowledge, we wanted all our teammates to know exactly what Design resources would be available, where to find them, and how to use them.

To accomplish this, we built a subset of our Design System dedicated to laying out and marking up Figma files, then set standards for how to use them.

At minimum, a finished delivery file included visual design, UX flows, documented components, and a functional prototype. The prototype was used both for demonstrating active functionality to developers and for running usability tests either through Grain or Usertesting.com.

Example 1: Urgent Escrow Leads

Example 2: Sales App Universal Comms Panel

While this case study has mostly been about team-level projects, I wouldn’t feel right without sharing the most fun interaction I got to create while i was at HomeLight: a DIY Boolean constructor for HomeLight Sales operators.

The ”Task Automation” feature for the internal HL Sales App allowed its users to define specific conditions and “rules” in their transactions whereby new Tasks could be automatically created and assigned to the responsible parties.

For example, a user could create a rule for all transactions that when any part of the HL system learns that a client signed a Listing Agreement with their seller agent, a Task for the client to provide photographs of their property would instantly be created in both the client’s and the agent’s dashboards, and upon property photo upload by either party, that Task would automatically resolve.

Creating this feature had the dual impact of reducing cognitive load on Sales operators while also sparing our developers from being sidetracked to hand-build dozens of individual Tasks as the need arose, as procedures and requirements in the home buying process often vary from state to state.

Closing Out on a Fun One