Brand tunning

[yceballost]

Traigo una pequeña reflexión para abrir un pequeño debate.

Actualmente existen customizaciones por marca, como los colores (lógicamente) o los textos (caso Movistar) y no existe customización por borderRadius y otras cosas.

Todo lo anterior entra bajo el paraguas de los tokens, cierto? Y aún podríamos meter muchas otras cosas.

La idea de Mística es llegar a ser muy flexibles de cara a las marcas... pero hasta dónde?

A nivel de componente, deberíamos aceptar customizaciones por marca? O en el nivel componente debería ser algo cerrado para evitar problemas y mantener esa capa lo más sencilla posible?

Érase una vez en Mística, existió una customización de marca en un componente como el Feedback Error Screen, en el cual la marca vivo no mostraba el asset. Esto era algo muy sencillo, pero este debate viene a raiz de pensar en.. si las marcas de repente cada una quiere que existan customizaciones de este tipo?

Planteo esto por abrir el debate a si tiene sentido marcar restricciones en esta capa de cara a un mantenimiento (y posibilidades con figma que esa es otra) y por tener claro hasta donde se puede llegar a tocar.

Ya dije que era una pequeña reflexión

[aweell]

Tendría cuidado en caer en customizaciones que:

• Intentan acercarse a lo que es posible hacer con CSS
• No sólo impactan en la presentación visual de los componentes sino en su anatomía interna

Desde mi punto de vista el límite debería estar donde la abstracción de CSS genere mayor valor a los usuarios del sistema:

La API de los componentes de alguna manera también permite un grado de customización (Ej. Elementos opcionales vs requeridos). Podría pasar que también para determinadas marcas se quisiera que esta definición cambiara y para algunas algunos elementos siempre estén presentes y para otras no

Tendría en cuenta otros dos aspectos:

• Valor aportado vs valor percibido
• Coste y complejidad

Determinado usuario del sistema querrá que éste se adapte lo máximo a cómo quiere construir interfaces y que satisfaga sus necesidades en ocasiones hasta el más mínimo detalle, esta posibilidad transforma el sistema en un modelo excesivamente complejo para aquel usuario que únicamente quiere utilizar el sistema tal y como viene presentado.

Ejemplos:

El sistema es muy configurable, pero es demasiado complejo --> Me es mas sencillo hacer cosas custom que resuelvan mis necesidades en vez enfrentarme a lo que cuesta adaptar el sistema.

El sistema es muy estricto y no me permite hacer esta configuración --> Tengo que construir lo que necesito custom.

Por regla general se percibirá más valor en un sistema que permita mayor configuración, pero no considero que esto signifique que el sistema realmente aporte más valor. Considero que un DS aporta mayor valor cuando se trata como una estandarización y no como una herramienta de configuración.

Esta estandarización debe cubrir aquellas propiedades que se considera relevante exponer a cada marca para ser manipuladas.

Ejemplos de abstracciones relevantes:

• border-radius
• animaciones

Ejemplos de abstracciones irrelevantes:

• overflow
• display
• box-sizing

La especificidad de a qué nivel impacta la customización también es algo a tener en cuenta:

• Impacta de una manera transversal a todos los elementos del sistema
• Impacta de una manera especifica a un elemento del sistema

Esta especificidad puede ser definida con un layering de tokens que permita atacar la customización desde diferentes ángulos

---

A nivel de componente, deberíamos aceptar customizaciones por marca? O en el nivel componente debería ser algo cerrado para evitar problemas y mantener esa capa lo más sencilla posible?

La anatomía de los componentes y sus posibilidades de customización a éste nivel deberían ser tratadas a través de abstracciones de los elementos de interfaz ya sea a nivel atómico o a nivel de primitivas (componentes de mayor flexibilidad que lo que se considera core)

Si la customización por marca tiene en cuenta la anatomía de componentes aumenta la complejidad en su mantenimiento y construcción, aumentando el número de variables en escena a la hora de:

• Añadir un nuevo componente o feature
• Refactorizar un componente existente o feature

Aquí considero que una feature en un componente debe exponerse en su API o no si es un estándar y no venir definido por la customización.

Ejemplo:

Si en Vivo no se muestra el asset y en el resto de marcas si en una feedback error screen, valoraría si ese componente debería tener un value "none" para su asset.

Evitaría en la manera de los posible acercar la línea hacia una construcción customizada por marca, porque la línea entre tener un único design system y tener uno por marca se vuelve difusa.