1. WHERE WE STARTED (AUDIT)

The original Marketing rebrand (which occurred shortly before I joined Fabric) did not include consideration for the product experience, which was built by a different design director. You can see in the comparison below that the two brands look visually disparate in several ways:

2. RESEARCH

We knew going into this project that we’d need to (1) expand our current brand guidelines, and (2) create a unified design system to scale upon. We researched the design systems of brands like Google (Material Design), IBM (Carbon), Airbnb, Zendesk, Monday.com, Mailchimp, Adobe (Spectrum), and more, to better understand the areas where our current, custom-built design system – called Tapestry – was lacking.

Based on our research, the Design and Engineering teams agreed that our best path forward was to use Material Design as the design language to build our system on. Because of our limited resources, we were already struggling to maintain Tapestry and agreed that building on top of Material would give us the freedom to focus on Fabric-specific problems, while leaning on Google’s resources for general UI/UX best practices.

3. ITERATE, ITERATE, ITERATE

Now that we knew we’d be building on top of Material Design, we began iterating to create a product experience that still felt like our current one, but improved. For background, Fabric’s product experience is primarily centered around their insurance application – i.e.: taking what is traditionally a very long paper application filled with a live agent’s help, and turning it into a digital-first experience that anyone can do on their phone or desktop. Because the majority of Fabric’s purchases come from mobile, our explorations were mobile-first.

Below is an example of the exploration that we did with our yes/no toggle input, which is one of our most commonly used components. Issues we were looking to solve:

• Better toggle placement: We stacked the yes/no buttons instead of having them side-by-side to make it easier for mobile users to click without having to reach their thumbs across the screen.

• Clearer selected state: In the original version, it’s difficult to see the selected state (it’s just a thick bar at the bottom of the button). We played with color, shadow, borders, and elevation.

• Improve accessibility: We looked for ways to improve accessibility, such as adding a checkmark to the selected input.

ISSUES WE FACED

In the example above, while we liked the clarity of the green checkmark for the selected state, when we applied the component to other use cases, we found that it did not work in instances where the button is less than a certain width.

Looking at '“2. Iteration” in the image to the left, you can see that the checkmark cuts off the word “Excellent” in the toggle. It was clear that there were instances where our solution was not going to work.

In response to this, we explored other ways to show an accessible selected state without the checkmark, and landed on a version that used elevation and accessible colors together to indicate a selected button.

BEFORE / AFTER

Scroll down to see the redesign, as well as a summary of changes made:

BORDERS

• Before: Heavy borders were intimidating, especially in long checklists

• After: Subtle fill makes the application more friendly

COLORS

• Before: Muted and not a proper reflection of the brand

• After: Brighter and aligned with brand

TYPOGRAPHY

• Before: Same font size and weight used throughout + center aligned text. Difficult for user to know where to focus.

• After: Clear type hierarchy + left-aligned text makes it easier for user read and interpret information.

HEADER BAR

• Before: Header on same background and plane as questions – difficult to focus the eye

• After: Elevation distinguishes header from questions – allows user to focus on the question

PROGRESS BAR

• Before: At the top of the page

• After: At the bottom of the page. We referenced this SurveyMonky report, which found that simple progress bars on the bottom of a survey had the highest completion rate compared with (1) no progress bar, (2) progress bar on the top of the page, (3) progress bars with percentages (top/bottom of page).

TOOL TIP/HINT

• Before: Difficult for mobile users to click; sometimes hid important information that affected response accuracy

• After: Auto-expanding hint gives users information that might affect their response, which increases response accuracy and reduces workload for underwriting team