@caoimghgin I'm all for a spec and naming convention, but I think a DT spec should not dictate A naming convention, but rather dictate that a naming conventions MUST be made for the current project/product/hand-off etc. Or at least set a base naming convention, which could be built upon or modified to suit the required needs.

If you want, you can take a look on my presentation regarding designers/devs and different languages: https://slides.com/phun-ky/enabling-developers-and-designers-to-speak-the-same-language#/0/0/0

from community-group.

Advancing the Design Token Contract Discussion

(@caoimghgin, @phun-ky) Thank you for your valuable insights on the Design Token Contract. Let's refine our thoughts to further progress the conversation:

Token Naming Convention:

• Establish a clear and consistent system for naming, such as category-property-value (e.g., color-background-primary).
• Consider adopting a more comprehensive taxonomy like the CTI+ model, which includes Domain, Category, Type, Item, SubItem, Variant, and Context, with additional metadata tags for subbrands/subthemes and modes.
• Strive for alignment within the community to ensure a defined 'schema' that maps tokens to code output effectively.

Token Values:

• Foster a shared understanding of units (px, rem, vh, etc.) and color formats (hex, rgb, hsb, hsl, etc.) to avoid confusion and ensure accurate design execution across platforms.

Token Structure:

• Explore grouping tokens by category (e.g., colors, typography, spacing) for intuitive organization.
• Consider accommodating multi-brand scenarios by including variants for different brands (e.g., brandA-color-background-primary, brandB-color-background-primary) to ensure scalability, maintainability, and brand uniqueness.
• Evaluate potential structures based on their implications for usability and management.

Token Modification Rules:

• Establish clear guidelines on who can modify or add tokens and under what circumstances to maintain consistency and prevent conflicts.

Token Usage Guidelines:

• Provide clear instructions on how to use tokens in different contexts, serving as a user manual for design tokens and facilitating effective utilization.

Let's keep in mind that the Design Token Contract aims to improve collaboration, not enforce a hierarchy between designers and developers. By working in tandem and making multi-disciplinary decisions together as a team, we can harness the strengths of both roles. The Design Token Contract serves as a tool for better communication, bridging the gap between design and code.

While it's crucial to avoid dictating a specific naming convention, we should encourage the creation of tailored conventions for each project, product, or hand-off. A base naming convention can be established, which can then be built upon or modified to suit specific needs.

As we navigate the path towards standardization, let's also examine the deviations in Figma Variables' implementation and their alignment with the evolving Design Token Contract. This will ensure that we stay informed and incorporate relevant advancements.

Exploring Figma Variables and their Alignment with the Design Token Contract

I would like to delve into the topic of Figma Variables and their relevance to the Design Token Contract. While Figma Variables offer promising features, it is essential to evaluate their alignment with our ongoing efforts to standardize design tokenization.

Figma Variables, currently in beta, introduce some variations in their implementation. As we examine their specifications and the direction Figma is heading, we should consider their potential impact on the broader design token ecosystem. By understanding these deviations, we can ensure that our discussions and recommendations remain informed and adaptable to evolving industry practices.

As the Design Token Contract gains traction, it is crucial to consider the compatibility and interoperability of design tools and platforms. While Figma is widely adopted within the design community, we should assess how its variable implementation aligns with the principles and goals of the Design Token Contract. This evaluation will enable us to determine the best practices for incorporating Figma Variables into our design token workflows.

By addressing the Figma Variables issue within our conversations, we demonstrate a comprehensive understanding of the design token landscape and a commitment to fostering collaboration and standardization. Let's continue exploring this topic together, sharing insights and findings that can help shape the future of design tokenization.

Thank you for your contributions, and I look forward to engaging in further discussions.

– Mark

from community-group.

I like your thought process! While not a definitive/prescriptive way to name tokens, I found a naming taxonomy that is universal and may help guide a way forward. All opinions welcome. https://medium.com/user-experience-design-1/how-to-name-tokens-in-a-design-system-5b218589dadc

from community-group.

While my intention wasn't to advocate for a specific naming convention, I couldn't agree more that it's a conversation we need to ignite. The universal taxonomy detailed in the article provides a very insightful naming taxonomy 👍.

from community-group.

@ipaintcode The road you've started to tread has many pitfalls :P I've been trying to bridge the designer/developer waters for a very long time, and I always come to the same conclusion, it's not possible, for now. But, luckily, the usage of design tokens is a tool that minimized the pains for that communication. I've held a couple of talks regarding design tokens and how designers and developers speaks different languages. They also have different cultures and where those professions originated from.

I think the purpose of design tokens (where a design token contract is one option) is to minimize the secondary activities we have when communicating design and code.

The concept of design tokens is inherited from what developer has had for years, variables. And we have to remember that design tokens is a way of communicating design, but within a code context. I think it's easier to say that design tokens is the interface (or glue) that sticks between design and code.

In my experience, it all boils down to where the source of truth is defined, and that is done per project, or per design system (not everyone uses or should use a design system). Continuing with my experience, no designer, ever, has the capacity to always maintain design sketches (best example is in a design system team), but a developer can update and maintain code more easily. Design System decisions are made by a team, and then the change is implemented, in code and in the sketches. Design tokens helps a lot with those changes.

What I'm trying to say is that designers and developers should not dictate each other, they should work in tandem, and make multi-disciplinary decisions together as a team.

from community-group.

@phun-ky Well said, and absolutely true! Designers and developers do speak different languages, share different cultures, and approach problems from distinct perspectives. Yet, if we took one suggestion from @ipaintcode and solved that, wouldn't the world be a better place? For instance...

• Token Naming Convention: A clear and consistent system for naming. Category-property-value (think color-background-primary)

This is a step in the right direction, though I would advocate for the much richer taxonomy that CTI+ offers (Domain, Category, Type, Item, SubItem, Varient, and Context) with additional metadata tags to indicate subbrands/subthemes, and modes. Possibly a bit more. However, such granularity requires a defined 'schema' to map input from tokens to code output. As a community, I don't think we're nearly aligned on that concept, as JSON was created to be simple to read and not require an additional file to make code sense of it.

While I advocate strongly for @ipaintcode ideas, I'm not sure we're ready. Perhaps W3C Design Tokens v2.0. But let's try not to wait another year or more before v1 gets out the door ;-)

from community-group.

CIT vs. CTI

@JayHalligan I'll have a fully functional CTI+ Style Dictionary demo available on GitHub before the end of the year, so everybody can give it a try. One nice thing about the CTI+ schema is the dynamics (Category, Type, Item, etc) can be ordered in any way you like (So, color-button-font rather than colour-font-button). Instead, it will be highly opinionated on the consistency of the dynamics order for all tokens.

Where CIT feels natural for buttons, it may seem odd for other definitions, or so I've noticed. I suspect 99% of us would be happy with CIT and make that the default order. A large sample of token names and/or an interactive web app asking users 'what would you call this?' would be a handy tool to dive deeper. Finally generating a fully ordered set of tokens according to simple input from the user and asking if they agree with the output.

Figma Variables

I had high hopes for variables but it's all the same from a Tokens Exporter/Style Dictionary POV. We can transform Styles/Variables or both.

from community-group.

You bet @JayHalligan! I'm excited. I suspect composite/component tokens (if I understand) would be something to tackle when we have a consensus on taxonomy/dynamics. Once that is settled, I believe our higher-level components would be easy. But I always say that before I actually do it, so take all with a grain of salt.

In any case, CTI+ is purely focused on primitive tokens.

from community-group.

As an ex-developer turned UX/UI designer, I fully understand the lack of a universal language and believe we should have a Before we can decide on whether this should be implemented, we should understand the use cases to determine the levels of standardisation and guidance.

While collaboration is the main factor in the success of design tokens, it isn’t always possible and we can’t assume that the business will allow time for it. This will be especially true for companies that contract designers or developers at different stages of a project.

Given that naming design tokens is the biggest pain point and can even become a deterrent, any guidelines or standardisation will go a long way to expand the usage and expand their reach to large businesses to SMEs.

Token Naming Convention

The CTI structure seems to lean towards a technical background. While developers may find this structure makes sense, I fear designers will find it difficult to find styles. Let’s look at how each applies styles to components.

Developers take time to group individual tokens into classes so, running a search or using autocomplete in VSCode makes it easy for them to find and join them together. Setting a component style means calling one class e.g. “primary-button”

In Figma, designers apply each component style individually, chosen from a drop-down list. If the designer wants to set a button background colour, it will be easier to find styles grouped as Item/Type e.g.

• colour-button-background-primary
• colour-button-background-secondary
• colour-button-font-colour-primary
• colour-button-font-colour-secondary

This structure is much more readable and therefore more attractive to all stakeholders. The CTI structure forces the user to drill down into the token name whereas, grouping by component means the user can ignore the first two columns. Also, the alignment helps to distinguish each component group

• Colour-background-button-primary
• Colour-background-button-secondary
• Colour-font-colour-button-primary
• Colour-font-colour-button-secondary

Figma variables

I may be being shortsighted but, I wonder if we need to consider Figma Variables at all. I agree Figma does set the bar and the new feature will have an effect on the design community however, it’s not the only design tool in the box. I may use a spanner to build a box but, I don't expect it to write the instructions.

I’m looking forward to hearing your thoughts and insights on this area.

Future users

When thinking of design tokens, I immediately think of large enterprises. Standardisation will open the door to smaller companies and enterprises will eventually become the edge case. We need to keep this in mind when creating the guidelines.

from community-group.

@caoimghgin Thanks for that, I'll look forward to giving your CTI+ Style dictionary demo. I did something similar a few months ago using Figma Tokens Studio but, I couldn't get it to work with composite types. My limited (or rusty) knowledge stopped me from working with the API.

From your suggestion of switching the Category/Type/Item around, we could look at different dynamics for semantic and component tokens.

from community-group.