Operations

Design roadmap

The key to our team’s success is our quarterly roadmap. Built in Google Sheets (hey, we use the technologies we have available to us), I review the roadmap with my team every Monday, going through each line item and tracking the progress of my team’s projects.

Here’s a high-level overview of the roadmap:

Below is what the roadmap looks like in action. From the information below, I can see that there looks to be a delay on the “Add ons” feature that is also delaying the “Cancellations” feature. This gives me information to discuss with our Product/Engineering team, to ensure that we are hitting our company OKRs. Because “Cancellations” is a low priority item, the team may decide to delay the launch in favor of more high priority items.

Product Designer career tracks

Fabric had two career tracks: Engineering and Business, which encapsulated all non-Engineering functions, including Product Design. Because of the broadness of the tracks, the designer were reliant on the growth plans that I created for them. I flagged this issue to my CEO, but he was originally hesitant to create a new career track for a small subset of the company. I partnered with my Product Director, who was struggling with the same issue on the PM side, and together we pitched that a product-driven company needed specified career tracks for its Product teams—it was crucial that our teams could see a future with the company and understand what was expected of them. We created tracks for our respective teams, working together to ensure that we had consistent leveling, and launched them to the organization.

As a result, one of my designers wrote in the performance review that the new Product Design IC tracks were “one of the most impactful tools we’ve had this year...[giving] me clear benchmarks for where I stand and where I can improve.”

Figma file reorganization

My team’s Figma files were getting unwieldy. The the main issues we faced were:

1. Files were getting too large and difficult to navigate
2. Lack of standardization—each designer organized their files in their own way
3. Lack of clarity around what was a permanent feature v. experiments v. bug fixes
4. Version control was getting out of hand

We also had to solve for the fact that Figma was often used by stakeholders around the company for different purposes. Leadership and Marketing used it to reference what was live in production (our product funnels are so long that it’s usually easier to reference Figma), Engineering referenced it to determine what was ready for development, Product referenced it to see the upcoming designs that were in progress.

To tackle this issue, I researched best practices from other companies and compiled the ones that I thought would be most effective to my team. I presented the issue and recommendation to my design team, giving them room to add their own thoughts and input.

As a team, we talked about what was most important for us:

1. We liked the idea of organizing by swim lanes, and decided to use the categories that corresponded with the statuses in our roadmap, which would make it easy to track at our weekly team meetings. The statuses we used were: “Live / Ready for development / In progress.”
2. We didn’t want to use as many emojis as in the inspiration above—it felt too overwhelming. Instead, we chose to use emojis strictly to dictate the whether a design was for a feature 🎬, an experiment 🧪, or a bug fix 🐛.
3. We decided to file all work related to active designs but outside of the designs themselves in the “Resources” bucket—this included prototypes, competitive research, graveyard designs, and designs that we would like to revisit in the future.
4. We decided to specify an “Active Archive” for designs that were no longer active, but that we still wanted available for reference. Designs outside of this criteria were pulled out of the file into a separate “Archive” folder.

While the team was generally excited for the file reorganization, some team members were apprehensive about how the new system would affect their work flow. We agreed to do a “trial run” where we would duplicate files, so that they could still access the old files, if the new system didn’t work.

As a result of the Figma file reorganization, we were able to achieve each of our initial objectives:

1. Files were now easy to navigate—not only for designers, but also for our various stakeholders.
2. Each file was standardized and every designer was using the same organizational system.
3. We could now easily discern which designs were for permanent features v. experiments v. bug fixes ( 🎬 🧪 🐛).
4. Only the most relevant versions were surfaced, making version control much easier to manage.