Ordenar las librerías de Figma de todas las plataformas de Amphora para que diseño y desarrollo trabajen con las mismas piezas: fundamentos, iconos y componentes de app y de web, documentados.
Product Designer · Amphora Logistics · design system · [2025-2026]
Había componentes. No había un sistema.
La librería global ponía web y app en el mismo índice, sin categorías: Date Picker junto a SideBar, Switch junto a Toggle button y una página llamada «Page 1». Para usar un componente había que saber de antemano que existía y en qué página estaba.
En las librerías de app y web casi no había componentes, sino elementos parecidos copiados uno al lado del otro. Y los que sí lo eran no tenían propiedades: cambiar un texto o un icono obligaba a buscar otra variante o a separar la instancia. Cada diseñadora acababa resolviendo lo mismo a su manera, y desarrollo recibía pantallas parecidas con medidas distintas.
Una librería para todo.Web y app compartían los mismos componentes, sin clasificar. Un botón pensado para escritorio, con hover, acababa en una app que se usa con el dedo.
Fundamentos e iconos comunes, y una librería para cada plataforma.App y Web se separan, pero se ordenan con las mismas nueve categorías: cada plataforma tiene lo que necesita y quien conoce una sabe moverse por la otra.
Cada control con su propio tamaño.Había tamaños, pero no coincidían entre componentes. Un botón podía medir 16 o 20 px y un badge, 18 o 24. Elementos que en el diseño iban alineados no encajaban.
Una sola escala de tamaños de control.Todos los elementos que pueden acabar alineados, como botones y badges, comparten la misma escala. Colocados uno al lado del otro, encajan sin ajustes.
Primary, secondary, tertiary.Los tokens de color tenían nombre de jerarquía, pero no estaban asociados a ningún uso. Elegir uno era una decisión a ojo cada vez.
Una propuesta de tokens por uso.Cada color se asocia a dónde se aplica, para que la decisión esté tomada en el sistema y no en cada pantalla. Primitives, tokens globales y tokens de componente, en cascada: se explica justo debajo.
Tipografías sin uso real.Había estilos definidos, pero nadie sabía cuál tocaba en cada caso, así que cada pantalla resolvía la jerarquía a su manera.
Investigación y definición de uso.Se revisó cómo se usaba la tipografía y cada librería tiene ahora su página con el uso de cada estilo. [Completar con lo que encontraste en la investigación.]
Los tokens, en cascada.
En Foundations, los tokens se organizan en tres niveles. Cada nivel solo apunta al anterior, así que ningún valor se escribe a mano dos veces.
Esa cadena es la que da coherencia: si un valor cambia en la base, cambia en todo lo que lo usa.
Un ejemplo: el botón.
Antes, cada combinación de botón era un dibujo distinto. Ahora es un solo componente por plataforma: las variantes deciden tipo, tamaño y estado, y las propiedades deciden lo demás, sin duplicar nada.
El mismo componente, adaptado a cada plataforma.
App y web hablan el mismo idioma.
Las dos librerías se ordenan con las mismas categorías, por lo que hace cada componente. Quien conoce una, encuentra lo que busca en la otra.
Un sistema documentado se puede cuidar entre todos.
Ir más despacio al principio para ir más rápido después.
Hacer componentes bien pensados lleva más tiempo: hay que estudiar desde el principio todos los casos posibles, o el máximo que se pueda. Pero ese tiempo se recupera. Después, el equipo los usa mucho más rápido, sabe cómo se comportan y tiene una guía de cómo usarlos.
Estandarizar no es producir menos. Es dedicar el tiempo donde más rinde.
Ordenar las librerías de Figma de todas las plataformas de Amphora para que diseño y desarrollo trabajen con las mismas piezas: fundamentos, iconos y componentes de app y de web, documentados.
Product Designer · Amphora Logistics · design system · [2025-2026]
Había componentes. No había un sistema.
La librería global ponía web y app en el mismo índice, sin categorías: Date Picker junto a SideBar, Switch junto a Toggle button y una página llamada «Page 1». Para usar un componente había que saber de antemano que existía y en qué página estaba.
En las librerías de app y web casi no había componentes, sino elementos parecidos copiados uno al lado del otro. Y los que sí lo eran no tenían propiedades: cambiar un texto o un icono obligaba a buscar otra variante o a separar la instancia. Cada diseñadora acababa resolviendo lo mismo a su manera, y desarrollo recibía pantallas parecidas con medidas distintas.
Una librería para todo.Web y app compartían los mismos componentes, sin clasificar. Un botón pensado para escritorio, con hover, acababa en una app que se usa con el dedo.
Fundamentos e iconos comunes, y una librería para cada plataforma.App y Web se separan, pero se ordenan con las mismas nueve categorías: cada plataforma tiene lo que necesita y quien conoce una sabe moverse por la otra.
Cada control con su propio tamaño.Había tamaños, pero no coincidían entre componentes. Un botón podía medir 16 o 20 px y un badge, 18 o 24. Elementos que en el diseño iban alineados no encajaban.
Una sola escala de tamaños de control.Todos los elementos que pueden acabar alineados, como botones y badges, comparten la misma escala. Colocados uno al lado del otro, encajan sin ajustes.
Primary, secondary, tertiary.Los tokens de color tenían nombre de jerarquía, pero no estaban asociados a ningún uso. Elegir uno era una decisión a ojo cada vez.
Una propuesta de tokens por uso.Cada color se asocia a dónde se aplica, para que la decisión esté tomada en el sistema y no en cada pantalla. Primitives, tokens globales y tokens de componente, en cascada: se explica justo debajo.
Tipografías sin uso real.Había estilos definidos, pero nadie sabía cuál tocaba en cada caso, así que cada pantalla resolvía la jerarquía a su manera.
Investigación y definición de uso.Se revisó cómo se usaba la tipografía y cada librería tiene ahora su página con el uso de cada estilo. [Completar con lo que encontraste en la investigación.]
Los tokens, en cascada.
En Foundations, los tokens se organizan en tres niveles. Cada nivel solo apunta al anterior, así que ningún valor se escribe a mano dos veces.
Esa cadena es la que da coherencia: si un valor cambia en la base, cambia en todo lo que lo usa.
Un ejemplo: el botón.
Antes, cada combinación de botón era un dibujo distinto. Ahora es un solo componente por plataforma: las variantes deciden tipo, tamaño y estado, y las propiedades deciden lo demás, sin duplicar nada.
El mismo componente, adaptado a cada plataforma.
App y web hablan el mismo idioma.
Las dos librerías se ordenan con las mismas categorías, por lo que hace cada componente. Quien conoce una, encuentra lo que busca en la otra.
Un sistema documentado se puede cuidar entre todos.
Ir más despacio al principio para ir más rápido después.
Hacer componentes bien pensados lleva más tiempo: hay que estudiar desde el principio todos los casos posibles, o el máximo que se pueda. Pero ese tiempo se recupera. Después, el equipo los usa mucho más rápido, sabe cómo se comportan y tiene una guía de cómo usarlos.
Estandarizar no es producir menos. Es dedicar el tiempo donde más rinde.