Chirp Design System [3/n] — Performing the audit of the interface
This article will discuss the next step I executed while building the system. It’ll show how you may approach performing an Audit and how to get the most out of it while you are at it.
Here I am again. If you have read my last article, you’ll know why I chose Twitter over other platforms to build this system. It’s been quite a long time since I wrote about this project, and it had to pause because I was occupied with my other things.
Now that I have time again, I resumed this project and started writing again. Let’s get into it now.
Auditing, but for which platform?
Before starting the audit, I wanted to decide if I want to do the system for all the platforms (meaning iOS, Android, Mobile Web, and desktop).
If I create the system for all platforms, I’d get exposed to more concepts (like style dictionary) which is a good thing. But thinking in a practical way, a product company will have its teams dedicated to each platform.
A design system need not satisfy every team’s needs when it is just starting but it should be built in such a way that it should be able to scale all the platforms, which means serving all the teams. That said, I was, from the beginning aiming to create this for Desktop web.
So, I have decided to build this system for Desktop first and scale it to more platforms as the system progresses.
More details: https://youtu.be/368tC8EIq8U?t=939
The Audit
What exactly is an Audit?
At this point you might think that what exactly does he mean by Audit? Well, let’s see what google says.
Audit: [Noun] an official inspection of an organization’s accounts, typically by an independent body.
One keyword that you can take from this definition is “Inspection”. Yes, that is exactly what Design Audit means. You are inspecting your design to see if there is any violation of the consistency that is aimed to be brought in with the design system.
How does the audit look like in design systems?
A lot of times when an employee at a company wants to create a design system, he thinks that he needs to build everything from scratch and later after building that library of components, people will magically use those components in their designs, and everything will be consistent.
As much as the idea of building from scratch sounds overly exciting and time consuming, it is NOT a good approach when it comes to design systems. You need to build on top of what already exists. In that way, you respect the designers and developers that have built those components and they would feel that their work is contributing to a design system as well. Adoption of your design system becomes easy in this way.
It is easier to Revise than to Create.
So, how do you perform a design audit of the interface? Easy. Take screenshots of every component you see and place them all in one place.
Wanna directly see how it is done? Here’s the YouTube video of Figma’s team auditing the interface for their Twigma product.
While the audit is primarily focused on components (like buttons, dropdowns, text fields, checkboxes etc.), you can also capture color styles, text styles, shadow styles, different corner radii values used etc.
Categorization of the Audited Elements
Okay now you have all these screenshots at one place (any whiteboard tool — I use FigJam). What to do next? Well let’s see what you have here.
You have the screenshots of various individual components that are used across your entire product. What good is the information at one place if it is not organized properly to make sense? Organizing + Making sense = Categorizing. Yes, the next step is to categorize your components into their respective categories.
The above Figma’s video shared earlier has this demonstrated. Please look at it below as well.
Note: I have not yet done the categorization in my FigJam file. You might have noticed it if you had opened it. The reason was that I quickly realized that Twitter was doing some design changes on their website. So, I thought I’ll do the audit again once the new design changes are implemented.
Conclusion
Well, that is it for this article. In the following article I’ll be discussing about how I planned the architecture to be in Figma, Prioritizing the component to be built.
