Te incorporas a un producto con años de interfaz inconsistente y sin design system. ¿Por dónde empiezas?

Empieza por una auditoría y un caso de negocio, no por una reconstrucción. Inventaría los componentes que existen de verdad en producción, cuenta las variantes, y cuantifica el coste en tiempo de ingeniería y bugs. Después arregla primero la superficie de más tráfico y más dolor, y extrae los cimientos compartidos a partir de trabajo real: color, tipografía, espaciado, y luego los dos o tres componentes más usados.

No abriría con una propuesta de rediseño, porque nadie tiene todavía motivo para confiar en mí. El primer mes es una auditoría. Hago capturas de cada pantalla y saco el CSS real con un ingeniero, y el resultado suele ser impactante de forma útil: en un producto teníamos catorce tonos de gris y nueve tratamientos de botón, cuatro de los cuales eran el mismo diseño implementado cuatro veces por separado. Ese artefacto convence por mí, mucho mejor que un manifiesto sobre la consistencia. Después le pongo un número: cuánto se tarda hoy en construir un formulario nuevo frente a hacerlo con componentes compartidos, más los fallos de accesibilidad que tendríamos que arreglar de todos modos. Luego elijo un flujo de alto tráfico, idealmente uno que ya esté en el roadmap, y lo hago bien, extrayendo tokens de color, tipografía y espaciado sobre la marcha. Los componentes reales salen de trabajo real, no de un diseñador sentado a solas construyendo una librería que nadie pidió. Y un ingeniero es copropietario desde el primer día, porque un sistema que solo existe en Figma es un moodboard.