My company has multiple brands under one roof managed by one team of designers. Each friend has its own UI KIT. We have discovered over time that we are re-creating many of the same elements such as sign-up flows, buttons, input forms, pop-ups, icons, shadows, etc.
My first thought was to create one company-wide UI kit housing frequently used elements like these. The problem I’m facing is what happens when one brand has a different font than another? As any designer knows, x-height varies across fonts making it difficult to assign a specific font size as a component. I know you can make changes to components such as padding, font, etc. but to me, it defeats the purpose of having a component if you can’t push updates to it.
I know a little bit about branching but would it still work in this scenario when the designer will need to create a whole new set of buttons for each individual brand?
I also considered not using components but rather a library of static elements to choose from and including guidelines and best practices to make sure designers are keeping up with industry standards.
Any suggestions or ideas would be greatly appreciated.
Hey Trina! I’m in a very similar position at the company I work for (this was also true of my last job). Our designers maintain multiple products, each with their own UI library in Figma, but the products overlap significantly.
This is about to be a lengthy reply, so if you’re short on time here’s the TL;DR: I personally recommend not mixing brand identities in a single Figma file. Keep them separate, even when you share elements/patterns.
Okay the longer part:
Some things to think about and talk through with your team to help you make the decision about how to proceed:
Does the business plan to keep the brands separate? If so, separate UI libraries (one per brand) is the best way to go. This would allow any of the brands to undergo a re-brand or visual design overhaul without disturbing the others. But if the business does intend to eventually consolidate brands, then your UI libraries may want to try and match the timing of this event.
How much is truly “re-created” between brands VS things that “rhyme” with each other, but are still unqiue? It could be good to do a component cut-up workshop (or an adjusted version of it) to find out. If you’ve truly got a lot of 1-1 matches between elements shared by the various brands (same properties, same layer architecture, same token usage, same interaction patterns) then sharing a brandless “core” library to establish efficient layer architecture, properties, and interaction patterns could be beneficial. @Eric10 has illustrated this idea in another thread. Could be worth checking out.
Who manages each brand’s UI library? And are they working alone? Or is there a whole team dedicated to this work? Are they working across brands, or does each brand have someone maintaining their UI library? Maybe there is no dedicated person or team and it’s the responsibility of the designers using the library to also maintain it? Are all brand UI libraries maintained using the same processes? This is important because consolidating libraries also means shaking up whatever processes are in place to maintain what exists today. A more positive way to spin that is: this could be an opportunity to revisit processes and get more efficient!
Who uses each brand’s UI library? What’s their experience like? Does every designer hop between brands in their day-to-day work (using different libraries as they switch brands)? Or do designers specialize on one brand and focus on it exclusively? If the former, I could definitely see the appeal of consolidating libraries into one to make sure the experience of using, say, a button component, is the same no matter what brand you’re working on. But as I mentioned earlier, I don’t recommend this. Again I’d advise you to check out the illustration of a system of libraries from the other thread.
Hope this was helpful! It’s a gnarly problem but I’m hopeful we’ll all find our way to some strong best practices the more folks ask. Thanks for starting this thread!
but I’m hopeful we’ll all find our way to some strong best practices the more folks ask. Thanks for starting this thread!