Standardizing the Handoff - Conceptual

[ipaintcode]

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 (think color-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:

• Design Consistency: The design vision is faithfully maintained, ensuring a high level of consistency across the product.
• Efficiency: Designers can streamline the design-to-development process by directly translating their design decisions into tokens.

Cons:

• Limited Technical Feasibility: Design decisions might neglect technical considerations, leading to tokens that are difficult or inefficient to implement.
• Limited Flexibility: Developers, as the primary consumers of the design tokens, might find their hands tied if the tokens don't account for certain coding requirements or constraints.

Developers Dictating Designers

Pros:

• Technical Efficiency: Tokens can be tailored to be efficient and easy to implement, optimizing the development process.
• Flexibility: Developers would have more freedom to adapt tokens to suit technical requirements or constraints.

Cons:

• Potential Design Compromise: If developers dictate the design tokens, the design's original intent might be compromised due to technical considerations.
• Communication Gap: Designers might find it challenging to express their design intent if they have to conform to a design token structure primarily dictated by developers.

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!

[caoimghgin]

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]

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]

@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]

@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 ;-)

[phun-ky]

@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]

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

[JayHalligan]

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.

[caoimghgin]

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.

[JayHalligan]

@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]

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.