One of the ways to have a harmonious product is to make sure there is consistency across the interface. This can be particularly difficult if the product has a certain age and if over the years, multiple people contributed to it, without having a clear design system. When the product is complex, this process of updating or aligning the interface can take some time, you might forget to update some components or you might need a lot of resources in order to rewrite parts of functionality.

You can make it your objective to create a comprehensive design system that wants to cover all the design language across the interface (from content, to color, iconography, typography, to all the visual components - check Carbon Design System as example) or you just might want to tackle a single interface component (sometimes you just need to start somewhere).

Example: Modals

The bigger the product is, the harder will be to create an interface inventory. Familiarity with the product is essential in order to not miss occurrences. For example, I was interested in finding out how many types of modals XWiki is using. You either need to know by heart all the functionalities and applications that are using modals, or you might need to rely on the source code. Doing some searches within the source code is the optimal way to not forget component instances, but you need to be comfortable understanding and creating interface components. For example, you might need to know that when you are creating a modal you need to use the class="modal-dialog". Looking for this class inside the source code might return these results:

The issue is that this might not be the only way of creating modals. Especially in Open Source projects, people can contribute functionality using their preferred frameworks or components. Sometimes you might prefer to encourage contributions instead of enforcing a particular component, other times the code just might be very old and nobody might had the time to update it.

For example, XWiki is having more than 5 ways to create modals. In some places there are even plain browser modals, or no modals at all (cases that were optimised for when JavaScript is disabled).

Doing an interface inventory might show you that you are still using some old modals and you might want to prioritise to replace them. You could take functionalities one by one and take screenshots with the modals that still need to be made consistent and with the modals that are done.

You can take a look at this example of modals usage report.

Other examples

You can create interface inventories for any component you are interested into. See some more example of icons usage or place inside XWiki where we would need auto-complete on references.

After you've investigated all the occurrences, you can create issues in order to plan and prioritise what to tackle and fix.

Creating such inventories can take a lot of time. It depends on how complex the product is and how thoroughly you want to be. Also this process can not be relied on a single person. In order for the information to not become deprecated fast, the data needs to be maintained by multiple contributors (designers and front-end developers alike).

Benefits

You can create smaller inventories, just for the mobile or desktop mode, just for core functionalities or certain components. You can create inventories for buttons usage, font-sizes, colors, messages, etc. For general styling provided by the global CSS files you can use a tool like CSS Stats to have a quick overview. This approach works better for website, but less good for complex applications.

The biggest benefit of knowing the status of a component's usage and creating a plan to update it, is assuring consistency and having a cohesive experience for the end user. This covers the graphical display, but most important the way the users interact with these components.

Such inventories help you determine the level of effort required to change the design for a particular component. In order for the interface to look fresh, you need to update it from time to time: either in term of how it looks like, or in term of how you interact with it.

If you manage to finish such interface inventories, these will be the first steps in having an interface design system. This will ensure the people designing and developing on top of your product, share the same design vocabulary and know what patterns they can use when creating new functionality.