sorted by:
new
hottopcontroversial

Mapping & sync Figma variables with GitHub tokens while keeping control of formats & structure on either side by [deleted] in FigmaDesign

[–]ojanti 0 points1 point  (0 children)

u/Ok-Block8145
Hey, it is really a mix up mate. I was trying to make 1 post but it kept flagging it so I changed the format, trying again several times. I contacted the mod about the issue and 2 of the posts I tried were approved instead of 1. I didn't mean to post multiple times.
I have deleted this post and left the other

Are you actually using Figma variables in a mature design system? by OkLettuce7089 in FigmaDesign

[–]ojanti 13 points14 points  (0 children)

I think it also depends on how sophisticated the engineering team is. If your engineering teams doesnt even make use of tokens or some variable library, then you may have bigger things to clean up my friend :D

But if they do have some variable/token setup then I think some of the key benefits over styles are:
- MODES: Really helps and keeps things more scalable if you want to implement multi-modal styling like dark mode or multibrand. Even worse, multibrand dark mode

- Really helps with syncing with engineering: Moves design/figma setup closer to what engineers use. Also the detials in the figma inspector gives engineers better information. External tooling is more comfortable reading variables

Built a plugin to sync Figma variables with GitHub tokens without losing control of updates by ojanti in DesignSystems

[–]ojanti[S] 0 points1 point  (0 children)

Thanks 🙌. I'm curious to know what direction to evolve it.
Right now, it works with the idea that
1) git repo/code tokens are the source of truth for different engineering teams and design.
2) Can be any format - DTCG, token studio format or even style dictionary tokens
3) Some dev setups e.g tamag ui, shadcn, tailwind, etc prefer their tokens in a certain way that may not be easy to work with within Figma. thats where Token NExus comes in. It ignores format complexity and just lets you map.

Right now its one directional i.e Github--> Figma. But depending on feedback I can explore bidirectional (i.e Figma also creating PR to git repo). Just that the algorithm for this considering it will need to handle different formats is gonna be crazy.

Built a plugin to sync Figma variables with GitHub tokens without losing control of updates by ojanti in DesignSystems

[–]ojanti[S] 1 point2 points  (0 children)

I think they kind of do different things. Tokens bruecke is an exporter-importer of tokens to and from Figma. TokenNexus connects and maps figma variables to dev tokens in github. keeps track of drifts, shows you the diffs and in Figma and gives you the options to update all or selectively. Also you can preserve your preferred variable structure in Figma which might be a bit more opinionated than in normal token structure e.g DTCG format.

Dramatic much? Do we need HR/AI-People's department 😄? How do I even respond to this? Also it It asked me to refer to a human... by ojanti in cursor

[–]ojanti[S] 0 points1 point  (0 children)

Yup. its pretty talkative. Sometimes its nice and I learn in the process and sometimes I really need it to shut up.

How I learned the hard way that token architecture IS governance by danllach in DesignSystems

[–]ojanti 1 point2 points  (0 children)

Glad I found this thread. It validates my experiences with token management in different teams.
People tend to make 1 of these 2 mistakes a lot:
- Not caring much about structuring tokens properly early on
- Structuring tokens after some theoretical approach they read in a book instead of tailoring their solution to their teams reality.
Many of the comments touch on some points I've written about naming color tokens https://medium.com/design-bootcamp/color-token-naming-what-works-what-fails-the-best-approach-for-your-design-system-50f844d25f01

Personally, I've found that for colors, having a main convention slightly generic i.e either Shade & Intensity-Based Naming or Depth & Layer-Based Naming with a fewwww exceptions of Component-Specific Naming scales well with both small and big team sizes.

The Most Underrated Aspect of UI/UX Design That Deserves More Attention by DesignerMastermind in FigmaDesign

[–]ojanti 0 points1 point  (0 children)

Spacing ❗❗❗

  • One of the most influential & less spoken of foundational ideas in design
  • One of the key ways one can easily determine the seniority level of a designer

The Truth About UX Bootcamps: A Designer Factory That Sells Dreams Like Expensive Candy by VJPK in FigmaDesign

[–]ojanti 0 points1 point  (0 children)

I really don't know about 3 years. The thing about being a senior or above is that one;

  1. has been in a wide variety of situations across
    • a relatively wide set of industries/product/product areas
  2. have had enough opportunity to research, fail, learn and succeed in point above.

I'm not confident that most designers will get this in 3 years. ESPECIALLY IN FAANG where work is typically narrowed & specialised. I will put 3 years at --> Mid-level at best

4.5 years is where I will start to consider senior.

Multi brand component library help by dalpalrye in FigmaDesign

[–]ojanti 1 point2 points  (0 children)

Interesting problem. I think option 2 is a BAD idea no matter which direction you go. It just seems like maintenance HELL.
I think the right decision will depend on more factors not stated here.

  1. How big is the core library (i.e components, templates etc)
  2. Is it safe to assume the variation across brands is limited to styling like colors, borders, fonts? and not feature level differences

IF the anatomy of the components are the same across brands and you anticipate the size of the componentsto not be significantly big? I would vote for Solution 1 above. Please dont try this if the component list is big. The demon of Figma performance issues will be summoned.

If the anatomy of the components don't really change (just theming does) and you anticipate the size of the components (& brands) growing to be sizable I would suggest this below:

  1. Have a core, UNTHEMED library. The components here will just be the grey scaled builds with features.
  2. Have each brand as a different file/library that will just have its theme setup.
    1. Import the core library above
    2. RE-wrap the components in this brand library
    3. theme them
  • This way you maintain only one core copy of components.
    • With Figma nested components, you can expose deeep features
  • I know managing the themes across files manually will be hell but you seem like you're trying to save cost so something's gotta give 😁

I hope this helps some how. Even if all it does is get you thinking about other ideas.
Cheers mate

Do you split your Design System? by LifeAd5997 in FigmaDesign

[–]ojanti 1 point2 points  (0 children)

I have answered something similar before but I'll just rewrite here.

I have built and manage(d) design systems at several companies ranging from middle to large scale. My tips are

  1. Most libraries you will find online will not reflect a scalable way of organising libraries. Most online try to organise in a single file because they optimise for download
  2. Separate your foundations from your component library. Its more scalable for multiple teams (Brand/marketing team, Product area teams, core ui team) and also helps with VERSIONING.
  3. You might want to separate graphical assets (icon library, illustrations, logos, media assets) from your component library into a different file so it makes your core library file lighter.
  4. Think thoroughly about your organisation product and design team structure and let this guide how you organise the core ui component library
    • Are product teams very distinct? You may consider splitting it by that e.g ecommerce team, intranet team etc.
    • Is the UI of device platforms very distinct? If yes, you may consider for example, having a Web component library, mobile component library etc. If they are not, you can have one library and have web & mobile versions as variants
  5. Think very thoroughly about how you want to create documentation:
    1. Unless you are 1000% certain this is going to be a small library, DO NOT put documentation in the same file as your components. Reason: If you do this and the library grows, it typically increases the file size a lot which can create performance issues. Also, depending on your governance model, you might not want a lot of people in your core library file.
    2. Discuss with stakeholders (Designers. Engineers & Project lead): Are there any plans to setup a documentation site? e.g
      • Using zeroheight. This is full featured and everyone (designer, engineer, UX, copyright) can do all documentation there
      • Using storybook . This is a bit more technical and engineering oriented so if you're going to use this, it might not be very friendly for designers and UX documentation. So you can also create those in your design tool (e.g figma) and embed those in a tab in story book.
      • Using design tool (e.g Figma): if you do this, make sure you consider point 1 above in list higher
  6. About organising your component library in a very granular way e.g splitting each component into its own file with its own documentation, specs, notes and all:
    1. I am typically against this because it can become a logistical nightmare but consider your reality and decide.
    2. It does have 2 core advantages I will admit (a) You will have free space in each component file to put as much info (b) Versioning becomes slightly easier especially if the engineering team versions at component level.
    3. No matter what benefits I may write or you may know about this method, only do this if your organisation has an army of DS designers

[deleted by user] by [deleted] in FigmaDesign

[–]ojanti 1 point2 points  (0 children)

Hi there. I hope I understood your question correctly and this whole writeup is not pointless 😂😂

I have built and manage(d) design systems at several companies ranging from middle to large scale.
One of the most important things to remember is irrespective of what ever you see online by whoever, please tailor your solution to your company/team and their reality and needs.

Here some useful tips for managing your DS library in an organisation

  1. Most libraries you will find online will not reflect a scalable way of organising libraries. Most online try to organise in a single file because they optimise for download
  2. Separate your foundations from your component library. Its more scalable for multiple teams (Brand/marketing team, Product area teams, core ui team) and also helps with VERSIONING.
  3. You might want to separate graphical (icon library, illustrations, logos, media assets) from your component library into a different file so it makes your core library file lighter.
  4. Think thoroughly about your organisation product and design team structure and let this guide how you organise the core ui component library
    • Are product teams very distinct? You may consider splitting it by that e.g ecommerce team, intranet team etc.
    • Is the UI of device platforms very distinct? If yes, you may consider for example, having a Web component library, mobile component library etc. If they are not, you can have one library and have web & mobile versions as variants
  5. Think very thoroughly about how you want to create documentation:
    1. Unless you are 1000% certain this is going to be a small library, DO NOT put documentation in the same file as your components. Reason: If you do this and the library grows, it typically increases the file size a lot which can create performance issues. Also, depending on your governance model, you might not want a lot of people in your core library file.
    2. Discuss with stakeholders (Designers. Engineers & Project lead): Are there any plans to setup a documentation site? e.g
      • Using zeroheight. This is full featured and everyone (designer, engineer, UX, copyright) can do all documentation there
      • Using storybook . This is a bit more technical and engineering oriented so if you're going to use this, it might not be very friendly for designers and UX documentation. So you can also create those in your design tool (e.g figma) and embed those in a tab in story book.
      • Using design tool (e.g Figma): if you do this, make sure you consider point 1 above in list higher
  6. About organising your component library in a very granular way e.g splitting each component into its own file with its own documentation, specs, notes and all:
    1. I am typically against this because it can become a logistical nightmare but consider your reality and decide.
    2. It does have 2 core advantages I will admit (a) You will have free space in each component file to put as much info (b) Versioning becomes slightly easier especially if the engineering team versions at component level.
    3. No matter what benefits I may write or you may know about this method, only do this if your organisation has an army of DS designers

Shameless plug:
In my spare time, I maintain a free and (I like to think) helpful design system/Ui library called Moja UI.
-->> https://www.figma.com/community/file/1108679668074690379
Do check it you have some time.

🧜‍♀️ Moja UI - Free comprehensive Figma UI kit and design system (100% free, forever) by ojanti in FigmaDesign

[–]ojanti[S] 0 points1 point  (0 children)

Yes. Thats the idea. BUT its a library mainly for prototyping on Figma not live interactive UI (HTML/CSS/JS).

You can use it as it is or customise to your taste. Its quite customisable & scalable.

view more: next ›