During our recent engagement with Keller Williams, we had the opportunity to help define the future of the KW Technology suite. This suite of products aimed to enhance the workflow of their 20,000 person network of Real Estate Agents across the United States and abroad, and ranged from a CRM to an AI personal assistant.
While designing these products, we established a set of design principles to create consistency across each of the tools within their product portfolio. As the products gained complexity, we found the documentation of these principles to be increasingly challenging. To increase visibility and documentation across the team, we built a web-based design system that included our guiding design principles, component library, and overarching brand guidelines. This gave us a tool that would allow consistent implementation of these principles across a multitude of platforms and mediums.
Understanding the Problem
To begin, we needed to understand who the users of the system would be, and uncover what their current pain points were when working and designing within their current workflow. This included members of several different teams, including development, design, and product. During this process we uncovered many crucial perspectives on how internal teams currently approached building new products and how certain aspects could be improved.
During the second part of the Discovery Phase, we audited the current product ecosystem to get an accurate landscape of the breadth of the elements requiring consideration. In the interest of bringing consistency to disparate products, the Ecosystem Map was pivotal to determining what to include in the design system. Below is a look at the output of that exercise.
In certain cases, this product ecosystem can get rather complex. This is especially true when looking at a company with multiple departments building both internal and consumer facing products. The Discovery Phase exercises gleaned the following insights:
- Provide for scalability
Working within an extremely agile environment, the design system needed to be scalable enough to handle constant updates- both within current and future products.
- Consider the large user base
There are hundreds of people spanning a myriad of roles utilizing this system to help define and update their own products. The system had to accommodate for this by thoroughly documenting each component with why and how it can be utilized in a way that was relevant to all users.
- Build a solid foundation
With this design system being the first of its kind internally, we needed to ensure the design principles formed a great foundation for the technology brand going forward.
- Define a governed way to update
Working within a fast paced technology environment, teams needed a way to propose and publish updates in a clean and efficient manner. This was paramount in ensuring the design system stayed accurate and up to date.
Outlining the Design System
Utilizing the data we gathered in the Discovery Phase, our teams were able to work closely together to create an outline of what the design system needed to include. In working through this collaboratively, we were able to get a collective buy-in on what the specifics of this system would include. The following is a high level example of that outline:
– Design System Overview
– Design Principles
-Glossary of Product Terms
– Motion Design Principles
– Motion Behavior
– General Layout Principles
– Grid System
– Page Structure
– FTU Experiences
– Formatting Dta
– Voice Input
During this process, we took a deep dive into the various products to determine out what components could be consolidated. A component checklist was created to define and categorize each of these in a way that could be easily translated into the design system. This checklist was used as a prioritization tool to establish which aspects needed to be designed first and which could wait until later in the project.
The biggest challenge during this process was defining, at a high level, which components could utilize the same rules and patterns as others. It is important to think in general terms when dealing with various components. Becoming too detailed and prescriptive can lead to difficulties in evolving them to fit new technologies. The best solution for this is to create context agnostic principles.
Implementing the System
During implementation, one of the main considerations was to find a place for the system to live that was readily accessible across departments. The teams weighed a couple of options, and ultimately decided on using the Storybook platform. This allowed us to get the system off the ground quickly and with little overhead. Storybook was a great tool to set up the system in a way that provided not only the guidelines, but was also equipped with components in a coded library for ease of development in the future.