LPA · De maquetar interfaces a crecer como Product Designer

Me incorporé a la oficina de Barcelona de Lucht Probst Associates (LPA) mientras cursaba el segundo posgrado de mi máster en Elisava. El equipo necesitaba un perfil de Product Design capaz de maquetar: diseño se encontraba principalmente en Alemania y desarrollo necesitaba apoyo cercano en Barcelona.

Comencé recibiendo diseños y trasladándolos a HTML, CSS y Sass. Durante los primeros meses pasé a trabajar también en diseño, primero en HedgePilot y después en WebDD, hoy conocido como Capmatix. Con el tiempo asumí user stories completas, desde la definición y el diseño hasta la maquetación y el handoff, además de investigación con usuarios, sistemas de diseño y acompañamiento de implementación.

De recibir diseños a comprender cómo se construyen

Mi punto de entrada fue la implementación visual. Recibía diseños creados por el equipo de Alemania y los trasladaba a HTML, CSS y Sass dentro del entorno del producto. El objetivo no era todavía definir la experiencia, sino asegurar que las propuestas pudieran convertirse en interfaces reales.

Este trabajo me permitió conocer desde el inicio:

• La estructura técnica de los productos.
• Las posibilidades y limitaciones de Angular.
• La relación entre componentes visuales y lógica de negocio.
• Las dudas que aparecen cuando un diseño llega a desarrollo.
• El impacto de navegadores, frameworks y tiempos de entrega.

La cercanía con desarrollo creó una base que después influiría en todas mis decisiones de diseño.

De implementar decisiones a asumir user stories completas

HedgePilot fue el primer producto en el que mi responsabilidad empezó a expandirse. Era una aplicación nueva para la gestión de estrategias de cobertura financiera. El equipo de Alemania había definido una dirección visual, lineamientos y un sistema de diseño; mi trabajo comenzó dando continuidad a ese lenguaje.

Después de aproximadamente un mes empecé a recibir encargos de diseño. Con el tiempo trabajé tanto con propuestas procedentes de Alemania como con nuevos requerimientos. Llegué a responsabilizarme de user stories completas: analizar la necesidad, diseñar la solución, discutirla con el equipo, construir su capa visual con HTML y Sass y realizar el handoff para completar la lógica del producto.

Ampliar el alcance gracias al frontend

Mis conocimientos técnicos también me permitieron resolver piezas que iban más allá de las pantallas principales. Diseñé y maqueté correos HTML de notificación para que las alertas y recomendaciones mantuvieran el lenguaje de HedgePilot fuera de la aplicación.

Aprender a diseñar con datos

El producto reunía dashboards, ratios, monedas, fechas, exposiciones, transacciones, estados y validaciones. Diseñar estas pantallas exigía aprender a:

• Priorizar información dentro de interfaces densas.
• Representar datos sin perder precisión.
• Diferenciar estados, advertencias y acciones.
• Mantener coherencia entre temas claro y oscuro.
• Diseñar flujos y componentes reutilizables.

Adaptar el producto a nuevos contextos de uso

HedgePilot se había planteado inicialmente para resoluciones mayores. Cuando surgió la necesidad de utilizarlo en pantallas de 1024 px, tuve que reconsiderar la jerarquía, la densidad y el comportamiento de sus componentes para construir una versión más reducida y adaptable sin perder información crítica.

De resolver funcionalidades a estructurar un producto complejo

WebDD presentaba un problema diferente. El software ya existía como aplicación desktop, tenía usuarios y concentraba múltiples interacciones propias de una herramienta financiera especializada. Llevarlo a la web implicaba conservar su capacidad sin trasladar literalmente toda su complejidad.

Mi responsabilidad incluyó:

• Participar en la definición del producto desde sus primeras etapas web.
• Diseñar navegación y funcionalidades para trasladar la experiencia desktop a la web.
• Crear el sistema visual inicial desde cero.
• Prototipar comportamientos para usuarios y desarrollo.
• Realizar tree tests y probar propuestas de navegación con Optimal Workshop.
• Diseñar árboles, tablas, estados, historial y acciones contextuales.

Encontrar el equilibrio entre una experiencia conocida y una mejor solución web

Las personas usuarias conocían la aplicación desktop y esperaban encontrar comportamientos y lógicas similares en la nueva versión. Sin embargo, la web tenía limitaciones diferentes y también ofrecía oportunidades para mejorar sustancialmente la experiencia.

El reto fue identificar qué modelos mentales y capacidades debían conservarse, qué interacciones no podían trasladarse literalmente y dónde la nueva plataforma permitía simplificar el trabajo. La solución debía ser reconocible para usuarios experimentados y, al mismo tiempo, demostrar que la versión web podía ayudarles a trabajar de una manera más clara y eficiente.

Adaptar el diseño a una nueva base técnica

En un punto del desarrollo, la aplicación necesitó adoptar AG Grid como base técnica para árboles y tablas. El diseño tuvo que adaptarse a las reglas y posibilidades del framework. Para hacerlo, revisé su documentación, entendí su funcionamiento y traduje los patrones existentes a una experiencia coherente con el producto.

De entregar diseños a diseñar también en código

A medida que ganaba autonomía, el código dejó de ser solo la fase posterior al diseño y se convirtió en una herramienta para explorar y decidir. Participaba en reuniones, sprints y conversaciones técnicas; creaba prototipos en Figma cuando era necesario; preparaba HTML y Sass; y permanecía disponible durante la implementación para resolver dudas y ajustar comportamientos.

En algunos trabajos llegué a diseñar directamente en HTML y CSS. Cuando la funcionalidad no necesitaba una exploración previa en Figma, utilizaba el navegador y el código como espacio de diseño, acortando la distancia entre propuesta e implementación.

La responsabilidad estaba claramente compartida:

• Mi contribución: diseño de producto, UX/UI, prototipos, HTML/CSS/Sass/Less y, ocasionalmente, TypeScript para interacciones básicas de frontend.
• Desarrollo: arquitectura, lógica de negocio e integración técnica más compleja.
• Producto y equipo: priorización, requisitos y decisiones colectivas.

Esta forma de trabajar se trasladó a IBOR y otros productos de la empresa. En IBOR trabajé en el restyling de una aplicación antigua construida con Less que debía adaptarse a temas diferentes según el cliente.

La combinación de diseño, colaboración e implementación también fue reconocida por las personas con las que trabajé directamente desde ingeniería, liderazgo técnico y dirección.

Tres perspectivas complementarias: ingeniería, liderazgo técnico de Capmatix y dirección.

Recomendaciones completas disponibles bajo solicitud.

La evolución del puesto puede verse en el alcance creciente de mis responsabilidades. Durante mi etapa en LPA:

• Pasé de maquetar diseños existentes a responsabilizarme de user stories completas.
• Trabajé en productos nuevos y en la transformación web de software desktop.
• Aprendí a diseñar visualizaciones, tablas y jerarquías de alta densidad.
• Creé el sistema visual inicial de WebDD y trabajé dentro del sistema existente de HedgePilot.
• Incorporé investigación con usuarios mediante pruebas de navegación.
• Diseñé directamente en código cuando era la vía más eficiente.
• Consolidé una práctica profesional situada entre producto, diseño y frontend.

Mi paso por LPA convirtió una afinidad previa por el código en una parte central de mi manera de diseñar: comprender el producto desde la experiencia, el negocio y la implementación.

LPA (se abre en una pestaña nueva) · HedgePilot (se abre en una pestaña nueva) · Capmatix (se abre en una pestaña nueva)