Homebase Coverage Plugin

Overview

Wayfair’s Design System is called Homebase. It is a catch all name for all the libraries that the team manages. Homebase supports a range of different end users ranging from Consultants, Suppliers, Warehouse employees and more.

In addition to maintaining the library and site, we also provide tooling such as the Homebase Coverage Plugin. This plugin can be downloaded from Chrome extensions and runs through the developer panel. Once the plugin is running, it will show how compliant the current page being viewed is using our Homebase component library vs local components made by a feature team.

The Problem

The Homebase Coverage Plugin exists, however our users do not understand how to use it and how it truly benefits the team. It was originally created and put together by engineers due to limited resources on the team. The plugin lacked intuitive designs and smooth user experience.

• Crucial data was separated into multiple views causing constant back and forth
• Percentage of Homebase components was not an accurate representation
• Exporting a CSV action was not clear
• Both Homebase and local components were appearing at the same time
• Users didn't understand deprecated components were not maintained by Homebase
• Plugin was built using local components and not from the Design System
• Extra information such as FAQ was shown within the plugin when it can be better utilized in a better location

User Story

As a user, I want to understand if the team's implementation is compliant or not. Having the most crucial information is important for us to make the necessary changes to any components and understand how much effort will be needed to maintain any that is considered to be local.

1. Understand what components have become deprecated since implementation
2. Show the breakdown of Homebase vs local components
3. A simple way for me to relay this information back to the team

Business Needs

Wayfair recommends all product teams to have a 90% coverage using Homebase Design System components. The higher the coverage, the more time the team can spend innovating and developing new product features. Teams will always get the latest updates to components and improvements. This will ensure scalability and efficiency across the development teams.

The Approach

For me to truly see the experience and understand the product, I mapped out the current experience into a user flow. Even though this isn’t extremely complex, it’s a great way to see any pain points in one view.

Within the user flow I attached emotions that the user might feel at certain points in their journey. As mentioned, this helps identify pain points and where the most clean up and/or focus should be.

Few things that were revealed

1. Debug menu prominently showing
2. Metrics were not accurate
3. Component type wasn’t showing a readable name
4. Deprecated components were shown within Homebase components

Based on this information it was crucial to think of how these pain points can be eliminated. I started by grouping information that directly impacted each other in order of importance. This involved showing the information our users would need the most and other elements that didn’t need much prominence.

1. Showcasing most important information upfront (Metrics, Components and actions)
2. Proper differentiation of components
3. Metrics shown first as a high level indicator of information presented
4. Deprecated components to be shown within local to indicate Homebase will not be maintaining this anymore
5. Clear actions the user can take based on the data presented

Sketching

Using our design system components, I created sketches for how we would showcase features to our users

Functionality and Behaviours

Core functionalities and behaviours of the Plugin include Metrics, filtering by component type and downloading the data currently being viewed. As the user toggles components on and off, the metrics will reflect with updated percentages viewing either Homebase or Local components at a time.

Metrics

Metrics appear at the top of the screen indicating a percentage of the component that is either Homebase or local components. A few options for how to visually represent the chart were created.

Actions

In order for our users to understand the connection between the actions and information, I wanted to keep them closely together. Having actions at the top level presented a level of hierarchy and better user experience as to what would be downloaded. The information icon provided a small summary to our users of what the Plugin did and how they can get more information if needed.

In case our users need additional help, support channels and debugging was shown at the bottom with smaller prominence. It was large enough for users to catch, but not too big where we had users clicking into debug without reaching out to a Homebase member first.

Based on the sketches, we met with stakeholders to go over all of the findings and discuss any concerns. During this meeting we discussed having a Progress Bar was more appropriate than a pie chart due to readability and understanding the information that is truly being conveyed.

Prototype

Final mockups were created based on the direction from the sketching phase. Homebase components appear as purple, Local appears as yellow and deprecated as red. In addition, within the Local section, additional information is provided for deprecated components for extra clarification.

Outcome and Takeaways

With these improvements alone, there were so many enhancements made to the plugin for our feature teams to use. The coverage plugin traffic went up by 10% after implementation. Innovation doesn’t stop here. As we progress, we’re looking into what additional data we can pull for our users to support them more.