[community-group] Standardizing the Handoff - Conceptual (#220)

ipaintcode has just created a new issue for https://github.com/design-tokens/community-group:

== Standardizing the Handoff - Conceptual ==
# 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!

Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/220 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 1 June 2023 19:04:12 UTC