The challenge of creating a house that shares all of its data with its homeowner.
There’s lots of talk of smart homes these days, but our homes really aren’t that smart. Our homes can’t tell us anything about themselves, and what little information we do have is hard to find. Never mind trying to share this information or pass it down to the next homeowner.
And so, we set out to design the kind of homeowner experience we all want. One that’s simple and easy, benefiting everyone who touches the home: builders, owners, real estate agents, and contractors. An experience that improves the lifestyle of homeowners for generations to come.
Overview
The Mission:
Making every piece of data about a home, instantly accessible for the homeowner, for the lifetime of the house
Designing a System to Design Data, Designed for Homeowners
Setting a course to lead the way for intelligent homes isn’t an easy task. Because HomeKey manages data starting from the moment homes are built and for the entire life of the home, there is a need for a whole ecosystem of data applications and solutions to serve the right information at exactly the right time to the right person.
Data that starts once construction begins, continues once the homeowner steps into their home the first time, and is handed down to other homeowners, is data that is potentially changing among static data that will stay permanent. This has been my challenge.
The problem:
Making a home a giant IoT device:
How do we solve making data one-touch available for non-digital, real-world things like backyards, paint and floor tiles along with their information like their locations and support products in each individual home?
HomeKey customers are home builders, home owners, and third-party contractors. This means that everything from the builder options in a home, how it is maintained, and the data to maintain it all fall into the data ecosystem that moves between all those customers in various, contextual forms such as paint locations, room volume, item descriptions combined with supported maintenance products, distances, customized inventory, and the list goes on and on.
B2C complexity:
These types of items need to be available to be seen first by the builders, then the homeowners, and then lastly, shared to contractors by the homeowner.
Compounded data complexity:
Items that are installed in homes can change at any time, at any point of the home lifetime, by any of the customer types. How do we keep the data, attached to the home, as the point of truth?
The Requirements:
HomeKey is a brand-new concept in the PropTech space and is really multiple businesses running as a single system. It has multiple business requirements (at times technically conflicting) running both parallel and simultaneously with each other.
So with that, there are different UX challenges for each set of requirements, which can occasionally collide together.
In addition, some UX design challenges emerge as Service design issues, or Customer Experience design issues, but only through the User Research could we educate ourselves on this.
Requirements by User Type
Homeowner:
Home Builder:
Home Contractors:
Requirements by Design Type
UX design:
Service design:
CX design:
The Work
Research
Tons of research had to be conducted, not just for users and usability, but also for what services would be required and for data support that would allow us to build for every scenario and overlapping scenario.
Data Research
Generative Research:
We developed an understanding of how accurate our data was and where we needed to fill gaps by capturing events from our homeowners (real homeowner user data), but the most useful information came from our builder-partners when we combined the home onboarding feedback directly from them with the event data.
Generative Research - Surveys:
Getting to know the thinking of homeowners throughout the U.S. about smart home and IoT technology was a real driver for key insights into how to further develop more meaningful data as well as how to market that data back to homeowners to help them engage with their own home information. So the cycle of data became truly 360 degrees.
Journey Mapping
Building the homeowner Journey to gather further insights:
Once we understood the basic homeowner lifecycle, we could better understand the obvious engagement touchpoints, but creating a brand new experience required discovery of engagement opportunities.
Application Architecture Research:
After developing what data we needed and where it needed to be utilized and displayed, we had to make some architectural decisions for the entire stack all the way into the Information Architecture. Essentially, the IA would dictate the UI structure, and where we needed the data integrations to pull from.
Pre-design: Information Architecture
Design
Data + User Patterns
Executing primary design for data patterns - then user patterns, in order to establish common UI for multiple applications became our approach building wireframes, proof of concepts, and prototypes.
Designing for scalability and multi-service data integrations
The main and constant consideration has always been data purity and ‘point-of-truth’ in the data served up for both builders and homeowners. So making sure that this purity was served immediately through all channels and integrations was our priority.
Every design decision had this purity consideration built into every tool we used, built and integrated.
Data-scalable, content-agnostic, and modularly designed navigation UI
Development Support
Building a design system that can handle fast, iterative additions to a shared library
Starting with a technology stack that includes the design tools which can push code and assets into an environment that allows engineers to be able to pull at agile speed was the first step to designing a true back and forth design/dev pipeline.
Working at the speed of design technology, and adapting
Building a scalable platform that runs multiple applications means fast, modular thinking for a design system.
Using Figma for design but also as a central design repository required introducing Anima for syncing to the codebase as well as token management in order to keep parity with ongoing engineering needs as well as being alerted to code changes that affected the design.
Because Anima turns props into Figma variants, responsive CSS into Auto Layout specs, and maintains all naming conventions from the code, it was a cinch to build out a design system that was able to be integrated across applications.
