Open ipaintcode opened 1 year ago
caoimghgin
commented
1 year ago 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
ipaintcode
commented
1 year ago 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 👍.
phun-ky
commented
1 year ago @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.
caoimghgin
commented
1 year ago @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...
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 ;-)
phun-ky
commented
1 year ago @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
ipaintcode
commented
1 year ago (@caoimghgin, @phun-ky) Thank you for your valuable insights on the Design Token Contract. Let's refine our thoughts to further progress the conversation:
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.
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
JayHalligan
commented
1 year ago 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.
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.
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
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.
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.
caoimghgin
commented
1 year ago @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.
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.
JayHalligan
commented
1 year ago @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.
caoimghgin
commented
1 year ago 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.
Standardizing the Handoff between Designers and Developers: The Design Token Contract
Howdy folks, we're all aware of the power of a good handshake, right? Now, visualize that for the handoff between designers and developers. I bring you the concept of a "Design Token Contract".
Just like an API contract creates a clear and shared understanding between front-end and back-end developers about data structures and data exchange, a Design Token Contract could be our lighthouse in the foggy sea of designer-developer interaction. It's about defining, exchanging, and interpreting those crucial nuggets of design information we call tokens.
So, what would this contract entail? Let's drill a bit deeper:
Token Naming Convention: We need to establish a clear and consistent system for naming. Something along the lines of
category-property-value(thinkcolor-background-primary) This will allow both designers and developers to understand and use tokens effectively, ensuring that the design intent is accurately reflected in the final product.Token Values: It's crucial that we have a shared understanding of units (px, rem, vh, etc.) and color formats (hex, rgb, hsb, hsl, etc.). This will help to avoid confusion and ensure the design is executed as envisioned across different platforms.
Token Structure: How are we grouping these tokens? Grouping by category (colors, typography, spacing) seems intuitive, but what if we're dealing with multi-brand scenarios? A structure that accommodates variants for different brands (e.g.,
brandA-color-background-primary,brandB-color-background-primary) could ensure scalability and maintainability while preserving brand uniqueness. We should consider potential structures and their implications for usability and management.Token Modification Rules: Establishing clear guidelines around who can change or add tokens and under what circumstances they can do so will help to maintain consistency and avoid potential conflicts.
Token Usage Guidelines: Providing clear instructions on how to use tokens in different contexts will make it easier for everyone involved to leverage them effectively. Think of it as a user manual for our design tokens.
First, it's key to note that the purpose of a Design Token Contract isn't to establish a hierarchy between designers and developers, but to facilitate better communication and collaboration between these two roles. However, it's worth discussing what might happen if one side had too much control over the contract.
Designers Dictating Developers
Pros:
Cons:
Developers Dictating Designers
Pros:
Cons:
We need to find a harmonious middle ground. Collaboration is the key to this balance. Designers are the champions of aesthetics and user experience, while developers are the wizards of technical feasibility and efficiency; both skills can live within one.
So, let's remember, we're all on the same team. The Design Token Contract is here to improve our lives and products. It's a tool for collaboration, not a battlefield for control.
Let's hash this out together. All thoughts and feedback are welcome!