Filevine Platform Redesign

Taking an existing product with a massive, wide-reaching interface and introducing a new design system alongside a new front-end architecture is no small task but with patience and a high level of collaboration can be incredibly rewarding.

My Role

By 2020, Filevine had been a functioning product for more than four years and was seeing a lot of success in the legal industry, specifically in the Personal Injury discipline. This was success was reached with little to no design support. Engineers had made the vast majority of decisions related to the experience and the interface of the product. As the company continued to grow, they saw a need for design. I was brought in to Filevine to establish a design team and bring design thinking and a UX-focused expertise to the product.

I created the Filevine design system from scratch. In my first three months at Filevine, I completed a full audit of the Filevine application, created conceptual designs to guide our design efforts and worked closely with the CEO to ensure our designs would meet the expectations of our leadership team, our customers, and our end users. Finally, I established the core set of components and styles, defined typography, heirarchy, and grids, and prepared a design system for our eventual design team to build on top of and eventually bring into the Filevine application.

Design Audit

After joining Filevine, I immediately got to work. I spent a great deal of time working inside the application to understand how the software functioned and learn the patterns that were currently in place. I also wanted to gain as much empathy for users as I could, trying to understand the biggest pain points in the app. I worked side-by-side with the Product Feedback team to analyze recent feedback and try to gauge where our weaknesses were from an experience perspective.

During my audit, I found wild inconsistencies throughout the app. Interactions such as dropdown menus had as many as fifteen different experiences or interface styles. I discovered more than a dozen different fonts being used without any rhyme or reason to the chosen font sizes, weights, or styles. Layouts suffered from a variety of widths, margins, and padding. Even colors had joined the chaos, with more than 500 unique hex codes used throughout the app.

The Path Forward

After reviewing the app and user feedback, I next set to work on determining a path forward. The audit helped me understand the scope of the design work required, but I also needed to understand the engineering efforts that would be required in order to implement a new design system. I worked closely with engineering leadership to understand how resources would be allocated for building out design systems, tokens, and a consumable component library.

For Filevine, the path forward was going to be long. Due to the incredibly large size of the code base and feature set, a one-time re-write of the front end was out of the question. By some estimates, we believed it would take anywhere from 18 months to 4 years to complete the entire project. Instead, we chose to go with a continous rollout, focusing section-by-section, one component at a time. We created a plan for targeting specific, global elements first that would help us better define layouts and architecture.

Conceptual Design Work

Before beginning any engineering or system-level design work, I needed to get buy-in at the leadership level. While our re-write was going to be green-lit, we needed approval on final designs and direction. With no design team yet in place, I had to work alone to define the styles and direction for the app, and I had to do it quickly.

At this point, my time at Filevine was still very short. I had no more than a few weeks under my belt, but we still needed to move forward. Without other designers, I relied on leadership and experienced front-end engineers to help define the direction. I created a series of designs with wide variation for navigation styles, layouts, colors, and overall aesthetics. Each time, I would review the work with multiple other people and we would discuss the options. This feedback was critical in helping me define a solid, functional layout with so little context.

Over the course of a couple of weeks, I narrowed down the design and began finalizing concepts. Within these concepts, I also had the constraint of building a system that could absorb different themes. With a custom component build, our options for styling would be limitless, but I also wanted to ensure the design system could be maintained easily and that our users would not be subjected to overwhelming visual style changes upon theme change. Instead, we limited the styling a theme could change to just colors and a couple of other key styling elements such as border radius.

With designs in-hand, I reviewed the work with exeuctive leadership. We quickly got the approvals we needed and had a direction ready for implementation.

Defining a Grid

Building concepts is fast and easy. With a blue sky limit, concepts can be beautiful and quick. But translating a concept into a design system is much harder work. Considering the difficulty of maintaining a custom design system, I wanted to give our design system the best possible starting point I could. Knowing our product is heavily text-based with few images, I knew our users spent a lot of their time reading content, notes, comments, and updates on our app. Legibility was going to be key, but I also wanted to ensure our interface balanced the need for legibility with the need for displaying as much data or content as possible.

I started the grid by first establishing the default font size and line height we needed for a common block of content. Our company brand had a dictated font and we wanted to incorporate the font into the product. The font, Helvetica Now, is a beautifully-designed, digital-first font that has a strong variety of styles and weights. With this font in mind and through in-depth testing on multiple displays, browsers, and environments, I established a font size of 14pt with a line height of 20pt.

This 20pt line height is the most critical measurement in the design system. From here forward, I designed every part of the system to revolve around this measurement. I initially experimented with the design world's most favorite grid system, the 8-point grid. But with 20pt being a half-measurement of the system, I found it difficult to work out interchangeable components that lived in harmony with the 20-point line height body of text.

I went off the beaten path and experimented with a 5-point grid system. At first, this was incredibly uncomfortable. I found a number of instances where I struggled to line up 15-point-tall items with 20-point-tall items. Finally, I decided to let the grid decide the sizes of elements. I quickly found that the 5-point grid was actually incredibly flexible and quite a bit easier to use than an 8-point grid from a math perspective. Instead of working on 4, 8, 16, 32, and 64 point measurements, I was able to switch to multiples of 5.

As I continued to build out the system, I found that virtually all elements could work incredibly well on the grid system. Heirarchy was created through a simple 5-point increase for every step up or down.

Elements like input fields were set at 35 points in height and buttons were the same, allowing buttons and input fields to have perfect visual alignment. Icons were defined at the same heights as primary, secondary, and tertiary text, allowing icons to live in harmony with text.

Creating Building Blocks

With the grid system fresh off the press, I was able to move forward and begin defining components. While Filevine had a consistency problem, it did not have an architecture problem. Most of Filevine was well-architected from a navigation perspective. We wouldn't need to alter too much about the architecture of the app to move forward. Instead, we were focused on a find-and-replace approach to most of the experience.

I created a number of early components that the engineering team quickly got to work implementing. We started with the base guidelines for text and common HTML elements. Then we implemented input fields, menus, and eventually navigation. We also created components for user messaging, like snackbars and dialogs.

As the months moved on, designers joined the team and the design system effort. While I had created the core of the design system, the work moved quicker as more hands joined the team. We expanded our component system to cover nearly every interaction that currently existed within the application.

Collaboration with Engineering

Designers began to take components and create designs for how we would adapt existing application areas to the new design system. Over the months, we eventually created designs for every section of the app and began negotiating with the Product and engineering teams on how we would implement the designs.

My design team walked a tightrope as they worked. They balanced the requirements of the design system with scope exercises and prioritization changes. They often created designs that showed areas with some new components and some old as engineers rolled out parts of the design system.

Phased Rollout

We broke our rollout into phases. We had committed to customers and leadership and users that they would see a high degree of progress on the project quickly. But in order to successfully implement the design system, we first had to bring in our core styles. We focused on changing the font and typography first. This effort took a lot of engineering and design collaboration and effort. We found dozens of different fonts and hundreds of different styles and font sizes. Our team went through the app by hand to identify and replace existing styles with new ones.

Next, we focused our efforts on replacing existing navigation components and page titles. This effort took months of engineering work and required a number of revisions from our design team.

After replacing the navigation, we knew that if we introduced any more new components into the app, we would be introducing even more colors. We wanted to reduce the number of colors used anyway, so we made the decision to replace all colors in the app with tokenized versions that would adhere to the new design system. This effort required a number of months of manually reviewing color styles and finding an appropriate replacement.

Eventually, we released the first set of changes to production. We had a strong, negative reaction from users who were unhappy. Change can be difficult on users, especially within an app that users spend a large amount of their workday in. We followed the feedback very closely. We launched CSAT surveys prior to changes and a few weeks afterward to better understand the effect our changes had on users. We then went back to the drawing table and updated our designs, again improving our work using the feedback from our users.

The last piece of this part of the work involved activating themes. With our new, tokenized app in-hand and an appropriate navigation structure, we enabled theme switching for our users. This allowed our users to select one of three different themes. We wanted to distance ourselves from the beige theme that had dominated the app since its inception and allow customers to select a more modern light or dark theme. Our users responded very positively to this change.

Future Work

This project continues to move forward. While the major pieces of the engineering effort are complete, we still have thousands of components, areas, pages, and instances where we need to inject the new components. This ongoing project has been a lot of work, but our users are gruadually seeing the rewards from our efforts.