← Back to list

Fénix 2.0, Parte 2: El Plano Maestro de la Reconstrucción

Para resolver un problema sistémico, el equipo necesitaba una solución sistémica. Si la Parte 1 fue el diagnóstico de una ciudad que creció…

Nicolás Dimov in PeYa Tech · 2026-03-12 15:33 · 7 claps · 4.5 min read
#fenix #technology
Open on Medium ↗
Wiki topics: STP · Startups & Venture

Fénix 2.0, Parte 2: El Plano Maestro de la Reconstrucción

Para resolver un problema sistémico, el equipo necesitaba una solución sistémica. Si la Parte 1 fue el diagnóstico de una ciudad que creció de forma orgánica y fragmentada, la Parte 2 es el plano del arquitecto. Fénix 2.0 no fue un simple cambio de fachada; introdujo una nueva arquitectura basada en criterios, diseñada para aportar lógica, claridad y escalabilidad a nuestra librería de componentes.

El Relevamiento del Terreno: Limpiando los Escombros

Antes de trazar la primera línea del nuevo sistema, tuvimos que entender la magnitud de lo que habíamos construido en la oscuridad. No podíamos diseñar el futuro sin auditar el presente. Así comenzó una fase de relevamiento exhaustivo: un esfuerzo coordinado donde todos los equipos de UX de la compañía se convirtieron en arqueólogos de su propio producto.

El objetivo era identificar, capturar y ordenar cada componente vivo bajo criterios de uso y propósito. Fue en este proceso donde la teoría del caos se hizo tangible: recordamos aquellas 50 variantes de elementos “lista” que mencionamos en la Parte 1. Al ponerlas todas sobre la mesa, descubrimos que, aunque cada equipo creía estar resolviendo un problema único, en realidad tod@s estaban intentando comunicar lo mismo con dialectos diferentes.

Este relevamiento nos permitió informar la creación de los nuevos componentes. En lugar de 50 soluciones aisladas, diseñamos un único componente robusto y flexible. Un elemento “maestro” que, a través de su configuración y propiedades, era capaz de satisfacer todas las necesidades que antes requerían de medio centenar de versiones huérfanas. Pasamos de la acumulación de objetos a la ingeniería de soluciones.

La Pirámide de Propósito: Una Nueva Estructura de Tres Niveles

Con el terreno limpio, la arquitectura de la nueva librería se concibió como una pirámide. Es un modelo donde cada nivel se construye sobre el anterior, definido por la “naturaleza del componente”. Esto es el qué del sistema: su estructura física.

  1. La Base: Sistema. En los cimientos se encuentran los elementos fundacionales, el equivalente moderno de los Base Components. Son los átomos elementales: botones, etiquetas, campos de entrada y controles básicos. Son la materia prima, pura y universal.
  2. El Pilar: Patrones. El nivel intermedio consiste en patrones. Son compuestos inteligentes construidos combinando elementos del nivel de Sistema. Su propósito es sistematizar elementos reutilizables que resuelvan problemas transversales. Un Vendor Swimlane es el ejemplo perfecto: utiliza componentes de Sistema para crear una estructura compleja con un propósito definido. Son las paredes y ventanas prefabricadas de nuestro ecosistema.
  3. La Vanguardia: Específicos. En la cúspide se encuentran los elementos únicos, con un contexto de uso tan particular que no deben reutilizarse. Aquí vive, por ejemplo, un Home Hero Banner. Son los arcos o vitrales personalizados: necesarios para su ubicación específica, pero no destinados a ser replicados en cada esquina.

El Principio Rector: El Eje de Agnosticidad

Si la pirámide es la estructura, este eje es la filosofía de implementación. Es el porqué que determina el lugar de cada pieza. Es un espectro que mide cuánto contexto necesita un componente para funcionar.

  • Alta Agnosticidad (Baja Especificidad): Un botón a nivel de sistema es altamente agnóstico. No necesita saber si está agregando un producto al carrito o cerrando una sesión; su función es universal. Su alta reutilización nace, precisamente, de su falta de contexto.
  • Agnosticidad Media (Especificidad Media): Aquí se sitúan los Patrones. Un Vendor Swimlane es menos agnóstico que un botón; ya lleva consigo contexto de negocio — sabe que muestra comercios — lo que lo hace útil en muchos lugares, pero no en todos.
  • Baja Agnosticidad (Alta Especificidad): En el extremo opuesto están los Específicos. Un componente de este tipo está profundamente ligado a su entorno. Su propósito está definido por su lugar único en la pantalla.

Este marco previene el fallo más común de los sistemas de diseño: la aplicación incorrecta de componentes por falta de criterio.

La Gramática del Diseño: Nomenclatura Sistemática

Una arquitectura lógica requiere un lenguaje lógico. Para complementar la estructura piramidal, introdujimos una nomenclatura diseñada para que los componentes se autodescriban. Esta convención no es arbitraria; incrusta el propósito y el comportamiento directamente en el nombre.

  • Nivel 1: Agrupación Conceptual (El ‘Porqué’): Responde al objetivo o función del componente en el producto.
  • Nivel 2: Agrupación por Componente (El ‘Cómo’): Define cómo se comunica o se comporta.
  • Nivel 3: Tipología (El ‘Qué Tipo’): Proporciona especificidad sobre la variación (ej. tamaño o estilo).

Al unirlo todo, el nombre de un componente se convierte en una fórmula: Agrupación Conceptual + Agrupación por Componente + Tipología. Por ejemplo: Vendor + Swimlane + M.

Lecciones Forjadas en el Fuego: Conclusiones de la Renovación

El viaje hacia Fénix 2.0 fue tanto sobre procesos y filosofía como sobre píxeles y código. Nos dejó lecciones críticas para la escalabilidad:

  1. Explorar con Criterio vs. Deambular sin Rumbo: El éxito se basó en establecer criterios objetivos que gobernaron cada decisión. Este marco proporcionó una base racional para analizar los más de 750 componentes auditados. Antes, los equipos deambulaban en la oscuridad; ahora, exploran con mapa y brújula.
  2. Conocer el Camino para poder Desviarse: La fase inicial fue estrictamente centralizada. Una librería única en Figma se convirtió en la fuente de verdad. No se trataba de limitar la creatividad, sino de dibujar el mapa. Uno solo puede elegir desviarse creativamente si primero sabe dónde está el camino principal.
  3. Un sistema es un producto, no un proyecto: Fénix 2.0 es un organismo vivo. La implementación se gestionó en “lotes” estratégicos, con una hoja de ruta clara y una estrecha colaboración entre el equipo central y las tribus de producto.

Conclusión: El futuro es federal

Con Fénix 2.0, hemos forjado el orden desde el caos. Pero esta no es el final de la historia. La centralización necesaria para el lanzamiento fue solo la primera fase.

La visión a largo plazo es evolucionar hacia un modelo federalizado. Esto no es un regreso a la fragmentación, sino un equilibrio: el control central sobre los fundamentos y principios, pero empoderando a las “tribus” para que contribuyan con nuevos patrones al sistema compartido. Fénix 2.0 consistió en construir una base sólida y dibujar el mapa; el próximo capítulo trata de cultivar un jardín próspero sobre esa base, potenciando la innovación sin volver a fracturarnos.


메타데이터
post_id
baa4fa0d5d31
slug
fénix-2-0-parte-2-el-plano-maestro-de-la-reconstrucción-baa4fa0d5d31
url
https://medium.com/peya-tech/f%C3%A9nix-2-0-parte-2-el-plano-maestro-de-la-reconstrucci%C3%B3n-baa4fa0d5d31
canonical_url
https://medium.com/peya-tech/f%C3%A9nix-2-0-parte-2-el-plano-maestro-de-la-reconstrucci%C3%B3n-baa4fa0d5d31
author_url
https://medium.com/@dimovnicolas
status
ok
fetched_at
2026-06-23 17:05:31