As a Product Design Intern on the design systems team, I worked on maintaining the health of the design systems by designing and building components used across CBS Sports mobile and web brands and creating the anatomy of our documentation for the components.
I worked with the design systems team to identify blockers in their current process and used that information to design and develop an internal tool, a design linter Figma plugin, that automated steps of the design to development handoff for the CBS Sports Design team.
One of the roles of the design systems team is to audit the design team's spec files to make sure the designs adhere to the design systems before handing it to the developers. However, after taking a closer look at this auditing process and speaking to my team, I learned that the current auditing process on Figma was inefficient and tedious.
A design linter would be able to scan the design files for any missing styles and flag them for the designers. It also would also clarify which elements are currently in use and still need to be componentized by the design systems team.
I conducted competitive analysis and feature comparisons of the different Figma design linters. After presenting these options to the team, we found that none of these options fully aligned with our current processes.
Utilizing my technical background, I proposed to build on the open source design linter plugin, Design Linter by Discord and Daniel Destefanis. This would allow us to customize the linter to fit the specific needs I had identified from speaking with the design systems team.
What are the capabilities and limitations of this plugin?
Based on the needs of the design systems team:
Flexibility and organization is important to the design systems team, especially when we need to systematically audit spec files and communicate our progress with the design and engineering team. This was one of the biggest limitations of the existing design linter.
This is how the original design linter displayed the list of errors.
Consider this scenario:
You have a spec file in front of you and your task is to lint and correct all the color errors today. What would you need to do?
The most intuitive thing to do would be to disable all linters besides the color linter, but the plugin doesn't have this feature. Since the errors aren't grouped, you would need to scroll through a lengthy list of 100+ errors to find all the color errors... feels a bit tedious, doesn't it?
1. There’s no way to specify what properties you want to lint for as a user.
For example, even if you don’t want the plugin to lint for color, the color linting functionality cannot be disabled from the plugin window interface. The only way is to manually change the linting functions from the code.
2. The error types are not grouped or organized in any way.
The linter lists all the errors in the order it was found, making it difficult for users to systematically lint designs.
Creating an error filtering functionality would allow the user to select and deselect which properties they want to lint for, making their linter more adaptable to different use cases.
How do we add a new feature is cohesive with the overall flow and style of the plugin and is intuitive to use?
After exploring e-commerce websites and search engines for inspiration, I made sketches and wireframed four versions of filtering layouts.
Out of the four layouts, I decided to go with the horizontal scrollbar. This treatment is mindful of the limited space on the plugin window, easy to find, and makes toggling between linter categories intuitive.
Drawbacks:
1. Having to scroll horizontally can be unintuitive
2. Some linter categories will be hidden and the users needs to scroll to find them.
Let's explore another potential solution in the next iteration!
How do we preserve the advantages of a horizontal scrollbar, but make it more intuitive to navigate and visibly accessible?
What if we still listed them horizontally, but turn the overflow into a new line instead of a scroll?
One initial concern I had was that if there were many linter categories, the filter section could push the rest of the content far down the page.
However, after talking to the design systems team, I learned that the current linter included most of the properties they needed.
On the left are potential ways the category linters could be displayed. I presented this layout to my team and received positive feedback! They liked how the design enabled them to view all the linters and see which ones were selected at a first glance, validating the benefit of a multi-line display over a horizontal scrollbar.
Now that I decided on the layout of the error filtering feature, I wanted to refine the visual design and make small organizational adjustments, AKA making it pretty and delightful to use!
Changed the checkbox to tags
Separating 'All' from the list of linter categories
In addition to designing this feature, I was really excited to use my development background and build a demo of the error filtering functionality.
To understand the technical feasibility, I started by testing/tinkering with the plugin and reading through the code. I mapped out the file structure, learned about function relationships, and created diagrams and tables to demonstrate how the code interacts with the UI. This helped make development easier for handoff to the other developers on the team if we wanted to customize more features.
My goal was to focus on the functionality of error filtering and to make sure it addressed the limitations I had originally identified, (1) to be able to enable and disable linter categories on the plugin window interface directly and (2) group the errors by category to help organization and process.
I used React and Typescript to prototype the error filtering functionality, utilizing the pre-defined input type checkbox and default content overflow to prioritize demonstrating funtionality in my proof-of-concept.
Here is the design linter with the coded addition of the error filtering feature!
I'm currently working on building out the actual plugin! If you have any additional suggestions or if you're interested in learning how I built the prototype in more depth, please send me a message on LinkedIn, I'd love to chat/share :)
1. Balance designing for UI and UX
We often talk about UI and UX together because both are crucial to an intuitive and effective product. However, through this project, I learned that there are times where there is a conflict between the best design treatment for visual aesthetic vs. interaction experience. Learning to make design decisions that balance and optimize both is really important.
2. There are different types of prototyping with respective benefits and trade-offs.
Design prototyping (with software like Figma) is quick, low-barrier, and makes it easy to convey a high-fidelity vision of the product. This is great for making iterations on feedback and outlining key interactions, but difficult to replicate the true experience of user input and interactions.
Prototyping with code is responsive, interactive, and better simulates nteracting with the real product, but can take significantly more time to start and make iterations. In this project, having a coded prototype meant that users could run it on their actual files, making it easier for them to visualize how this plugin could be applied to their work and workflow.
The goal of prototyping is to find the most effective way to get feedback on your designs. There will be times when prototyping in design tools like Figma is more useful than prototyping in code, and vise versa. Being comfortable with both makes me a flexible designer and effective prototyper.
1. Presented and demoed my prototype to the CBS Sports design systems team. The plugin was well received and the team is looking to move forward with this in the next quarter.
2. I wrote documentation for the design linter plugin with the added error filtering feature, which outlines the file structures, plugin anatomy, and file functionality on the CBS Sports internal documentation. I also documented the plugin development environment set-up and API calls so others can easily begin developing plugins in the future.
3. I shared the new feature I built with Daniel Destefanis, the original creator of this open source Figma plugin and a designer at Discord. He loved the idea and we are looking at possibly incorporating this feature onto the main plugin, which has over 48,000 downloads. Will update once it's finished being developed!