Volver al blog
BrandingFrontendArquitecturaDesign SystemsAI

La evolución de una empresa también se diseña

Cómo la evolución de Urbs Data nos llevó a replantear nuestra identidad, nuestra arquitectura y la forma en la que construimos productos.

Por Damián Ricobelli, Lead Frontend Engineer de Urbs Data04 de julio de 20269 min

Hay una idea bastante instalada en la industria: cuando una empresa quiere renovarse, cambia el logo, rediseña su sitio web y publica un nuevo manifiesto.

Sin embargo, ninguna de esas cosas transforma realmente una empresa. Lo que la hace evolucionar es cambiar la forma en la que piensa, trabaja y resuelve problemas. El branding, la identidad visual o el sitio web deberían ser simplemente la consecuencia de esa evolución, nunca su punto de partida.

Eso fue exactamente lo que vivimos en Urbs Data.

Lo que comenzó como un proyecto para renovar nuestra presencia digital terminó convirtiéndose en un ejercicio mucho más profundo: revisar cómo comunicábamos lo que hacíamos, ordenar nuestra propuesta de valor y construir una base técnica y visual que acompañara el crecimiento de la empresa durante los próximos años.

El sitio dejó de representar a la empresa

Durante mucho tiempo nuestro sitio cumplió perfectamente su función. Explicaba quiénes éramos, qué hacíamos y cómo podían contactarnos. Pero mientras el sitio permanecía prácticamente igual, la empresa seguía evolucionando.

Con cada proyecto profundizábamos nuestra experiencia en ingeniería de datos, automatización, business intelligence, inteligencia artificial y desarrollo de aplicaciones. Poco a poco dejamos de ver estas disciplinas como servicios independientes para empezar a entenderlas como partes de un mismo sistema, donde los datos alimentan procesos, los procesos impulsan automatizaciones y la inteligencia artificial opera sobre información confiable para ayudar a las organizaciones a tomar mejores decisiones.

El problema era que nuestro sitio seguía contando la historia de la empresa que habíamos sido, no de la empresa en la que nos habíamos convertido. Y cuando eso ocurre, el desafío deja de ser visual. Se convierte en un problema de comunicación.

Antes del diseño, necesitábamos una estrategia

Antes de abrir Figma o escribir una sola línea de código, había una pregunta mucho más importante por responder.

¿Qué queremos que una empresa entienda después de dedicar tres minutos a conocer Urbs Data?

La respuesta terminó definiendo prácticamente todo el proyecto.

No queríamos vender dashboards, inteligencia artificial o desarrollo de software como capacidades aisladas. Queríamos transmitir una idea mucho más simple: las empresas funcionan mejor cuando dejan de tratar la tecnología como herramientas separadas y comienzan a construir una infraestructura donde los datos, las aplicaciones, la automatización y la inteligencia artificial trabajan como un único sistema.

A partir de esa premisa, toda la narrativa empezó a ordenarse. Cada sección del sitio pasó a cumplir una función específica: presentar el problema, explicar nuestra forma de trabajar, mostrar cómo conectamos las distintas piezas y, finalmente, transmitir el impacto que esa forma de construir tiene sobre el negocio de nuestros clientes.

Cuando el mensaje está claro, el diseño deja de esforzarse por captar atención y empieza a cumplir su verdadero propósito: reforzar la historia que queremos contar.

Diseñar un sistema antes que una interfaz

En ingeniería hablamos constantemente de arquitectura de software, pero pocas veces pensamos que una identidad visual también necesita una arquitectura.

Una interfaz donde cada componente toma decisiones distintas sobre colores, tipografías, espaciados o comportamientos termina generando exactamente los mismos problemas que una base de código inconsistente: es difícil de mantener, costosa de evolucionar y cada cambio introduce nuevas excepciones.

Por eso decidimos construir primero un sistema y después las pantallas.

Toda la identidad comenzó a apoyarse sobre componentes reutilizables, tokens semánticos, escalas tipográficas consistentes y una paleta basada en espacios de color modernos como OKLCH. Herramientas como Shadcn y Radix Colors aceleraron esa implementación, pero el verdadero trabajo estuvo en definir las reglas que conectaban todas esas piezas para que funcionaran como un único lenguaje.

El objetivo nunca fue que todo se viera igual. El objetivo era que todo respondiera a los mismos principios. Esa diferencia hace que incorporar nuevas páginas, nuevas funcionalidades o incluso nuevos productos deje de ser un ejercicio de improvisación para convertirse en una evolución natural del sistema.

La tecnología fue una consecuencia

Recién cuando el mensaje y el sistema estuvieron claros comenzamos a hablar de tecnología.

Elegimos TanStack Start porque necesitábamos una arquitectura preparada para crecer mucho más allá de un sitio institucional. El proyecto ya no era solamente una landing: también debía convivir con un blog, contenido técnico, presentaciones y futuras herramientas que todavía no existían. La tecnología debía acompañar esa evolución, no condicionarla.

Cada decisión buscó responder una pregunta muy simple: ¿seguirá teniendo sentido cuando el proyecto sea mucho más grande que hoy?

Los frameworks cambian. Las librerías evolucionan. Incluso la forma en la que desarrollamos aplicaciones seguirá transformándose durante los próximos años. Lo que permanece es una arquitectura bien pensada, capaz de adaptarse sin obligarnos a empezar de nuevo cada vez que aparece una nueva herramienta.

La inteligencia artificial como compañera de trabajo

La inteligencia artificial también formó parte del proceso, aunque no de la manera en que muchas personas imaginan. No diseñó el sitio, no escribió el contenido y tampoco tomó decisiones por nosotros. Su mayor aporte fue ayudarnos a cuestionar las nuestras.

La utilizamos para explorar distintas formas de explicar conceptos complejos, revisar la narrativa, detectar inconsistencias entre el mensaje y la interfaz, validar decisiones de accesibilidad y analizar alternativas antes de implementarlas. Muchas de esas ideas nunca llegaron al producto final y, justamente por eso, fueron valiosas. Más que una herramienta para producir contenido, terminó convirtiéndose en una herramienta para pensar con mayor claridad.

Las restricciones aceleran el diseño

Existe una tendencia a creer que la creatividad necesita libertad absoluta. Nuestra experiencia fue exactamente la contraria.

Desde el comienzo definimos un conjunto de principios que guiaron prácticamente todas las decisiones del proyecto.

  • Cada componente debía pertenecer al sistema de diseño.
  • Cada sección debía comunicar una única idea.
  • Cada animación debía mejorar la comprensión, nunca distraer.
  • Cada elemento visual debía tener un propósito.
  • Cada decisión técnica debía facilitar la evolución futura del proyecto.

Lejos de limitar el proceso, esas restricciones eliminaron una enorme cantidad de discusiones innecesarias. Cuando aparece una nueva idea ya no hace falta debatirla desde cero; simplemente nos preguntamos si respeta el sistema que estamos construyendo. Si la respuesta es sí, avanza. Si no, probablemente todavía necesite madurar.

Evolucionar también significa conservar

Uno de los errores más comunes durante un proceso de rebranding es asumir que todo debe cambiar.

Nosotros intentamos hacer exactamente lo contrario. Conservamos aquello que seguía representando correctamente a Urbs Data y replanteamos únicamente aquello que había dejado de hacerlo. Evolucionar no significa romper con el pasado, sino reconocer qué decisiones siguen teniendo valor y construir sobre ellas.

Es un principio que aplica al software, a los sistemas de diseño y también a las marcas.

Construyendo la próxima versión de Urbs Data

El nuevo sitio no representa el final de un proyecto, sino el comienzo de una nueva etapa. Seguramente dentro de algunos años volveremos a rediseñarlo. Cambiarán las tecnologías, aparecerán nuevas herramientas y la inteligencia artificial ocupará un lugar diferente al que ocupa hoy. Eso no nos preocupa, porque el verdadero objetivo nunca fue construir una landing más moderna.

Lo que realmente buscábamos era construir una base capaz de evolucionar junto con la empresa. Una arquitectura donde cada nueva decisión encontrara naturalmente su lugar, sin necesidad de replantear todo desde cero; un sistema de diseño que pudiera crecer sin perder coherencia; y una identidad que siguiera representándonos incluso cuando la organización volviera a cambiar.

Mirando hacia atrás, probablemente esa haya sido la decisión más importante de todo el proyecto. No diseñar un sitio para la empresa que éramos, sino construir una plataforma preparada para la empresa que seguimos construyendo cada día. Porque, al final, una buena arquitectura —ya sea de software, de diseño o de una marca— no se mide por cómo luce el día que se lanza, sino por la facilidad con la que puede seguir evolucionando cuando el negocio vuelve a cambiar.